HTML First
html-first.com
html-first.com
> Where possible, default to defining style and behaviour with inline HTML attributes
but their example wouldn't work.
<div class="bg-green" onlick="this.classList.add('green')">
<div onclick="this.classList.add('bg-green')">
<button></button>
button:active { background: green; }
--
> Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax
I totally agree! But why is your example of a library not built around javascript or a custom syntax feature:
<input type="text" _="on input put me into #output">
<div id="output"></div>
--
> Prefer "naked" HTML to obfuscation layers that compile down to HTML
Their example is to not use Rails ERB tag helpers, in your templates. I don't think this is that big of an issue, these helpers can actually handle a lot of things that will look messy if you use the minimal amount of templating to write them. The example leaves off unique dom ids, turbo tags (very HTML/no JS focused!) and iteration.
This was my critiquing point as well. Style configurations should be separate from actions, with only references linking the two. It's the only way that makes sense for anything meaningful.
Yes, I could technically write a python app where all SQL database connections have hardcoded SQL as one one long file, but that is poor practice. This suggested principle seems the same to me.
> Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax
And then they demo using _hyperscript [0] as encouraged. However, that's a library built around a custom syntax. It's only using an HTML attribute to encode a script that's in a new language you need to learn. Is this serious?
I would rather there was just an explicit `onclick` (or some other event) in there with a vanilla JavaScript statement so I know what is happening.
source: I'm the creator of hyperscript.
Six principles and one of them is presented with an example that blatantly violates that same principle. I could see a mistake like this slipping through if there were many more principles and examples, but this is a relatively short piece for such an error to slip in.
Its example is also pretty weak. Vanilla solutions (Tip 1) works just as well:
<div> <input type="text" oninput="this.nextElementSibling.innerText = this.value"/> <div id="output"></div> </div>
https://html.spec.whatwg.org/dev/embedded-content.html#the-i...
Also using a slash to self close a tag is not part of the html spec and it never has been part of the spec. The browser doesn’t know what that means on any tag. If you write <div /> the browser ignores the slash and thinks you still haven’t closed your Div.
self-closing tags are necessary for void elements in XML and XHTML, both technologies that are still supported on the Web. Since XHTML processes HTML as XML, it forces it to be well-formed. Unlike HTML, which has all sorts of tag-soup and quirks modes and other things, because it's lax in its syntax.
Void elements lacking the need for a closing tag or closing slash is one of the weird edge cases in HTML. While it's not in the HTML spec, it may still be seen in the wild in XML and XHTML documents and is not universally bad or unsupported.
And if you're writing HTML, the browser considers <br/> to just be a weird way to write <br>. The slash is non-significant. So confusingly <script /> is not equivalent to <script></script>.
The problem I have with self-closing tags is that I've met so many web developers throughout my career who think that browsers understand self closing tags. I used to be one of them! And that will almost always, but not always work out fine:
- React / JSX supports self closing tags. So do a lot of other web frameworks.
- Void elements ignore the /. (And you don't need to close void tags anyway). So you can write input, img, br, etc tags however you want.
- HTML5 will auto-insert missing closing tags when it needs them. Eg, <div><span /></div> will render as you expect because the browser will automatically close the span when you close the div. (!)
But it'll confuse you in weird ways. Like <script src="..." /> - which the browser dangerously interprets as an open script tag. Subsequent text is interpreted as javascript!
I think its good practice to be clear in all source files whether you're writing XHTML (eg in .jsx) or writing real, god fearing HTML. And then never use self closing tags in HTML. Sooner or later, someone will think they matter and you'll get bugs.
There was no real 'war', XHTML 5 is still a thing. Browsers are HTML engines because people who write HTML don't want to be forced into well-formed markup. They want the browser to guess what they meant and run with it.
There's also the whole "we need to be compatible with almost every HTML file dating back to the early 90s" conundrum that makes clean breaks in behavior, like XHTML, hard to pull off without pissing people off.
It should be clear which one is writing based on the DOCTYPE element. IIRC XHTML still requires a DTD to ensure its schema can be validated, while HTML 5 did away with it altogether and now just uses <!DOCTYPE html>
There was definitely a debate over how web browsers should interpret web pages - as XHTML or "quirks mode". HTML5 (with infinite backwards compatibility) was the outcome. Every major web browser implements HTML5 - complete with its super quirky and complex, but fully specified and consistent parsing rules.
> XHTML 5 is still a thing.
Is it though? On the web? I just tried, with this html:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html><body>
<div>
<div style="background-color: hotpink;" />
yo
</div>
</body></html>
If this was an XHTML page, tags should be able to self-close. And in that case it should be black on white. But try it. Its not. The browser ignores the self-closing part of the tag, so "yo" is inside the inner div and it shows up in hot-pink. The outer div is then not closed correctly. (2 divs open, 1 div closes). If the page were processed as strict XHTML we'd also expect a warning or error, but the browser doesn't care. Neither firefox nor chrome emitted anything in the console about any of this.
As far as I can tell, the XHTML doctype has no effect here. The page is interpreted - as all webpages are - by the browser using HTML5's parsing rules. Not XHTML's.
There are contexts in which XHTML still exists. Like JSX. But the browser is not an XHTML renderer. Rail against HTML5 if you want, but people need to stop pretending that the browser supports self closing tags. They are not part of HTML5. Pretending they are causes bugs.
Also you need namespace declaration otherwise it will be rendered as unstyled xml.
This is all part of HTML5 spec: https://html.spec.whatwg.org/#the-xhtml-syntax
https://zlg.space/misc/example.xhtml
Let me know how your browser sees it.
span is a bad example. indeed it will close - but then it will reopen (!) when the next text node occurs. <p> is a better example, and it will also auto close when you try opening a new <p>, which can be rather convenient when trying to write concise html.
It's explicitly in the HTML5 spec as allowed, but not required.
However, the slash carries no meaning. It does nothing. And browsers are instructed to ignore it. If anything, it can only cause problems: https://github.com/validator/validator/wiki/Markup-%C2%BB-Vo...
1. Can't be easily done with vanilla JS and so can justify using a library.
2. Don't need a library with a DSL in direct opposition to the claimed principle (avoid DSLs).
My go-to questions with anything like this are: how do things look if I want a dropdown? Multiselect? Datepicker? If we use <input type="date" /> do we get a datepicker across browsers? (Looks like yes.) Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.)
Multiselects are similar - shift/control-clicking to get multiple things is a flat no-go from a UX perspective - but at my last check, this is still how the default elements work, and it can't be changed. Similarly, the look/feel of multiselects (and even selects!) is terrible and largely cannot be changed.
There's a reason third-party components for this kind of thing get built for any new framework. The built-in stuff just doesn't get it done. It's the same reason 90% of my projects still have lodash as a dependency, even though the list of built-in stuff on MDN's Array page grows year by year. It's better than it was 10 years ago for sure - but its still not there.
> Is the look/feel/controls consistent across browsers? (No.) Can we style them to get there? (Also no.)
Assuming you design this website for users. Each users may use a different browser, but they probably use this same browser for all websites they visit. Hence IMO its more important that date pickers are consistent across all websites on 1 browser, then across 1 website on all browsers. (Its of course a different story if you need custom functionality.)
YYYY-MM-DD or GTFO.
YMYY-YD-DMScreen readers and voice input: https://a11ysupport.io/tech/html/input(type-date)_element
Of the classic form controls, choosing a date is probably the one that has the most application-specific needs, and therefore the one that I would most expect to vary between applications.
For many use cases you described, the primary UX flow should probably not have a date picker at all, but rather the date would be selected implicitly through other user actions: i.e. to add an appointment, you might start with a full-page calendar view and click on the appropriate day; for prices you'll probably have "next day"/"previous day" buttons built into the page.
But those UX flows are orthogonal to the flows that actually do use a date picker, IMO.
There are hundreds of ways to support this using JavaScript because the community has cleverly come up with many different flavors of view handling to suit different mental models and preferences. What could be better?
* For adding an appointment, I probably want something closest to the conventional date picker, but even then, if I'm making an appointment for a group, I might still want additional information about when people are available displayed directly in the calendar view as I'm choosing a date.
* If I want to browse for the cheapest date, then I want a way of seeing all the dates available and the prices of those dates at the same time, meaning a relatively rich date picker control. If all I have is "next day"/"previous day", then I need to manually click around a lot to get good deals.
* If I want to select a range of dates, then I want a single control that allows me to select that range immediately, not having to open a "start" field and an "end" field separately. I also probably want multiple months visible, depending on how long my range is, so I can see the whole range at a glance without having to click back and forth between months.
* This is more subtle, but a hotel visit requires a range of dates, but a flight to and from the hotel requires two discrete dates, which might potentially be indicated with yet another date picker variant.
These are all flows that require me to pick a date, most of them from a calendar, and all of them could arguably be considered important enough for a native element (in the sense that I use all of these elements in my day-to-day web browsing). But they're all very different, require different interactions and content, and have subtly different purposes.
Maybe we are lacking vocabulary for these different types of date widgets. I've never heard anyone take about an historical date picker as a separate concept.
- Select 5 non-adjacent items
- Select 5 adjacent items.
Report back with success rates.
Anyways, my favorite multiselect paradigm is the old windows one with two list boxes side by side and buttons in between.
Now we tend to have a part of the record appearing to have texture (stripes or bumps) as a clue that grabbing it will afford pushing it up or down.
There’s many little common standards like that which have never appeared in “out of the box” controls provided by the platforms.
I actually like native web multi-select widget because I know how it works and it works well. But most people don't know how it works, no one is going to teach them, and they aren't going to look it up (they probably don't even know what to search for to learn!). So you need one that works just with clicks and no modifier keys or most people won't actually be able to use it. In other words, it's not accessible.
Checkboxes are a good choice for a small number of options: https://m3.material.io/components/chips/overview . I'd say past a dozen options though this starts to become unwieldy.
Tag-style multiselects are fairly common (see https://react-select.com/home for an example). These are good where the number of values a user is expected to have selected is small (less than five imo) but the number of options is large enough to make checkboxes impractical. If you're expecting a higher number of things to be selected, you could have the option list stay open after an option is clicked, so they user doesn't have to reopen it each time they want to add an option (and, in fact, the "Animation" example does precisely that).
Two column designs ( https://crlcu.github.io/multiselect/examples/search.html ) have mostly fallen out of favor, though I feel they still have their uses for larger lists with large numbers of selected values.
My boomer parents do. Most users I've seen in the wild do.
And to think that having a native look-and-feel used to be considered a must for any desktop application!
I would be much happier if all websites's UI components (not the actual website design of course) had the look-and-feel native to my browser (and if browsers actually cared to make them look good, TBH) rather than inventing their own dumb styles for everything.
Regarding the CSS size, my experience was the opposite, Tailwind output was usually a lot smaller than hand-written CSS.
I have nothing against plain CSS either though; but it's at least as easy to make a mess.
Maybe if you use a CDN, so hopefully the user might have a local cache of it from somewhere else, that can be avoided?
Still though, tailwind is pitched WITH it's build step normally, making the author's point about avoiding a build step a bit odd.
Tailwind requires a build step and shipping the 1.x development build was explicitly not meant for production.
Trying to use tw 1 like this without a build step, you can't even define a custom color scheme.
If this is what you want, I'd use a library that actually supports this. Maybe tachyons? But tbh, without the build step I'd consider using Tailwind at all a massive mistake. Then I'd prefer handwritten CSS.
Custom properties should make sth like this a lot more viable though. I'm sure there are libraries that better fit this use case, if you want to use a CSS library.
Browsers partition caches by origin now for privacy reasons, so this is no longer possible. If the user doesn’t have it cached from your website, they don’t have it cached.
Tailwind output is massively bigger than the one with semantic CSS. Here's a comparison:
I use tailwind on my personal site, which is otherwise entirely just vanilla HTML, and it doesn't feel very intrusive to run the CLI in watch mode when I'm writing styles.
I think what the article is about when it says to steer clear of builds, is complex builds, where transpilations and similar changes in format have to happen, in order for the page to work.
This isn't true, though—Tailwind's build step isn't just stripping out white space, it removes unused selectirs, too, which can't be done in advance.
I haven't looked at your css, but maybe changing the box model could help?
For example, tailwind without a build step is just the entire library. This means one can go a long way and even have a functioning web application without introducing a build step.
I would say stripping unused CSS is in the same context as optimizing images, fonts etc perhaps generally a "cleanup & prepare assets for production" step.
There's a kind of development version where that build step runs in the browser on page load, but it's still a build step in the sense of generating all that CSS dynamically, and it will produce a poor experience for a user if you try and use it in production.
But IIRC it doesn't offer quite everything full Tailwind does. In general I was frustrated with Fresh for not being up-front about the fact that it is largely built on Preact and Twind, and you must buy into those libraries first.
* Self host tailwind v3 CDN.
* https://github.com/gnat/css-scope-inline
Both are surprisingly fast- parse 10,000+ <style> or class="..." in under a second.
There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives.
I’m all for using the web platform to the max, and I’m absolutely for reducing complexity as much as possible, but I’m highly skeptical these principles will achieve that and I would not be surprised if it increases complexity by having multiple ways to do something.
With peace and love but I can’t see from this list if you actually put these principles to the test or you just assumed it will do what you hope it will.
I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my screen is not as tasty, or "onlick" is not an handler of div.
Nothing is more convincing than real world success stories.
Complete back button support beyond what the router offers, saving search/sort/filter in query string so users can copy/paste/bookmark/back/forward, handling connection and other errors gracefully, loading, accessibility, having to wrap Vanilla JS components into their own framework-compatible components, having to update things in different parts of the screen. And the last often requires a total paradigm change in terms of how data is handled in the app thanks to the introduction of state managers (React-sans-Redux looks totally different from regular React). All those require extra work on every project I worked, and no, libraries often don't solve them completely or as easily as it is with previous backend tech.
These frameworks are also steering a lot of software into some very problematic product decisions. Like using fancy third party components where stylized native would suffice (and be more useable/accessible), using date pickers for absolutely everything that looks like a date (it sucks to type your birthday in those unless you were born this month), saving things in the browser instead of in the backend (so the site looks different in different computers), or just having some specific UI-framework forced on you so you have to use a certain framework.
There are obvious advantages to frontend frameworks, and I'm a big fan of React/Vue/Svelte. I really like those things, been using those for years and I was doing what used to be called "DHTML" since the late 90s. But it takes so much more complexity than the average web app to reap those advantages... IMO they are definitely overused.
I do agree with you, it's why I'm skeptical about the results of following this advice. I vividly remember how much things sucked, and obv the web has come a long way, but the tools have gotten even further. If I see how much mileage I get out of the tools I use on the daily, I would not be nearly as productive without them, and produce a lot more buggy, inaccessible, and shitty apps.
whereas you can addEventListener anywhere you want
Honestly, and sarcasm aside, I think this is an incredibly important thing for any new web developer to do.
Trying to learn web development in 2023 (or even in 2014, when I started my career) is so hard, because you're constantly standing on top of the shoulders of giants without even knowing how far you are from the ground.
I started a refresh of my personal site a few months back and resolved to write all the html and css "by hand", vanilla style, as a way of forcing myself to relearn the basics, and it was really refreshing to strip away all the layers of extra stuff and build it with simple tools. And I actually learned a ton of stuff that was useful on a daily basis while I worked on a React project during my day job, stuff that I just had never had to do or learn or use because some framework was always helping me out.
Recently I've been working on a little toy app in Phoenix, and I had the "revelation" that Eex / Phoenix components were slowing me down instead of speeding me up, because I didn't understand the underlying concepts as well as I needed to. As soon as I said "fuck it, I'm writing vanilla html and only using Eex where it's absolutely necessary" I was able to get through a whole host of issues that were giving me friction and actually build what I wanted.
I had a similar experience a few years ago when learning Phoenix. I just didn't get Ecto at all, and the reason was simple - I didn't know SQL and database design. Once I resolved to just figure out how to do the thing I was doing with raw SQL, Ecto immediately made way more sense.
We obviously can't peel back layers of the onion forever, or we'd never get anything done. At some point you have to get comfortable with abstracting away the details. But what I've found in web dev is that the big frameworks are written by people who've done the "vanilla" way so much that they've identified places where things hurt and built solutions that abstract that pain away. That's all well and good when you understand why the abstraction exists and the problem it solves, but it can really be confusing before you've put in the work to gain some of that context.
Well, what are the objectives? If they are complex, so should the code be complex. That's the nature of our job. By adding an advanced framework you up the complexity by default. Instead of adding more code, you add more build dependencies. This is especially wasteful on websites.
In my opinion, people today are afraid of writing code. Everyone wants some framework to write code for them. That is not how we push our industry forward.
But this article is not showing me how to do that and the things listed are not going to have an impact on the complexity of my projects as these basic things are solved quite well.
> By adding an advanced framework you up the complexity by default
If you know your project will remain simple then by all means. That's often not how it works though and then you end up writing a framework yourself once the scope gets increased and features are added.
Adding to that that using a framework gives you so many things for free. There are so many aspects to a good website and leaning on a group of people specialising in all those things is often a smart move with better outcomes.
I think the initial complexity might be a little bit higher, but there often is a big return on investment later on, and also immediately in terms of productivity.
I'm not going to stop you from not using a framework, I think it's great to experience it, have been there many times before, got burned (badly), and now make different decisions.
Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.
And speaking from experience maintaining React apps is quite nice. React has great backwards compatibility, and where it doesn't there are usually codemods available. Dependencies can be tricky, but that's not exclusive to React.
Also don't forget React evolves, backed by multiple #huge companies, and still innovating.
Edit: it depends on what you mean by "bites the dust". If you mean "isn't cool anymore" then I'd say that's kind of irrelevant. If you mean "isn't supported anymore", I don't see that happening any time within the next decade at least. Rails isn't cool anymore but it's still supported and lots of people are still (more or less) happily using it at their day jobs. React is so widely used it'll be kept on life support long after it has been supplanted by something better, if and when that happens.
React might be 10 years old, but it changed like 5 times during that time. Something built in first or second version of React is pretty much an entirely different framework at this point. (Would it even build with using the newset toolchains?). It's almost disingenuous to ignore that fact.
So while it's unlikely that there won't be a thing called "React" in the future, it's not that crazy of an idea.
Today, it's moving heavily towards server-side rendering because the client-side / SPA format is already quite mature. Their approach with server components is an optimization path that uses concepts/patterns from already popular server-side languages and frameworks + templating, and blends them seamlessly with client-side development, giving engineers the best of many worlds.
This was a natural evolution from NextJS which popularized this way of using React, and it's giving engineers more choices in how they build + optimize their apps.
It’s just going back full cycle, with a few extra steps. And the only clear purpose is SEO.
But here's the thing, hot-shot devs, and hot-shot dev wannabes look down on maintenance; and humans are social creatures, me included. So I'm not going to do a job for you that you look down on, unless you carry me in (and out) on a sedan chair.
Same for writing doc, I'm good at it and enoy it, but there's no pleasure in doing something that other people don't really value.
Popular backend templating systems face the same problem with possible sunsetting and decay of collective knowledge over time.
React is a great investment, and is here to stay for a long time because its team (and community) are massive, and are keeping pace with newer libraries/frameworks that are in a lot of ways doing things better. React's market share has hardly been touched by Vue, Svelte, Solid, etc. and less so by HTMX and other new attempts at un-frameworking the web.
I’m genuinely asking. I never understood this argument that people bring.
In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.
I would also add that a lot of us do work on the bigger projects, which makes sense as bigger projects require more people. So at least in my life, and I expect many others, it is quite relevant.
I also don't believe the article qualifies that these tips are only for small to medium projects, I'd read it very differently if it did, but I would still like to see some real world examples though.
Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.
I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. That might be different for you depending on the work you do.
I think otherwise. I.e.: blog shouldn't be web app just because it's content management is.
If you use a CMS you have already a templating situation and dynamic content, using a framework, or jamstack like situation is not that different, depending on the specifics it might produce faster results.
I can say with confidence that unless I royally screw something up in my component lifecycles or render loops, everything is just as snappy as ever. No latency. No lag. Just a zippy fast web app with URL/route changes that fly, fetched data populating quickly, and interactions feeling wonderful -- and that's because said apps I'm developing _aren't_ using any heavy tracking libraries.
People are too quick to blame slow performance on modern view libraries, and even likelier: they've never used them before.
Have you checked this is the reason? not slow network? and not ads/analytics and blocking assets? That's not exclusive to frameworks btw, and probably less likely as most optimize these things for you.
The website that is linked originally has a bunch of blocking assets.. lighthouse score is not amazing either.
Just like the original article, you might want to test your assumptions a bit more.
The big projects are of course important. But even chrome needs a simple little website with a download link.
Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those.
A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough.
The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.
But are they that wrong? We compute to, well, do things with our lives. To find out how to go places, to pay bills, to talk with friends, to meet with people, to learn about things. A view that computation should come with technical (e.g. tech bloat) limitations in mind feels important only to technical people and not to actual computing.
If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).
Our online lives would be a lot better if the product folks listened to the tech folks a bit more.
I like to draw a parallel to music; if the producer doesn't understand music at all, then maybe they should listen to the musicians a bit when it comes to creating a musical product.
What if people don't use it because of the degraded customer experience? Then does it really help if people who would originally benefit from the computation never compute?
> Our online lives would be a lot better if the product folks listened to the tech folks a bit more.
I mean, according to which metrics? Again this is really popular on HN and other nerd forums but from what I can tell it's just a nerd forum indicator. I think you can make a decent case for involving tech and product together, and I can think of many, but it's a case-by-case basis and has nothing to do with degrading customer experience. This view is popular on HN because we don't actually care here much about actual customers and care more about things like "site payload" and "how much JS is running in my browser". If the argument is that people with older devices won't be able to run the JS like this, I'd argue that your networks have more latency than any bloat you get from JS. Which is why a holistic experience matters more than what your personal tech-experience gets hung up on.
My target user is someone running 3G on their phone on the commute home in a crowded train. The designer's sexy animations and carefully coordinated state changes are not worth the extra 100Kb of 3rd-party dependency JS required to get them to work, because the user is not going to see them; they're going to switch away from the app after 10s of staring at a blank page waiting for the JS to download.
Seen too many "perfect" designs on a laptop monitor right next to the router in the dev studio fail completely in the wild. Every Kb matters.
For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals, because the business owner is trying different things out.
Using Angular with reactive forms makes this easier to develop, maintain and hand off to other Angular devs.
While it makes writing the static parts of the website more complicated, it makes developing the booking process easier. And overly complicated business processes are what is mentally challenging for me. This is where I want all the help I can get. Writing static pages is something I can do in any framework even when I am tired. Making this part easier or reducing boilerplate is nice but doesn't make me much happier. Being able to build ridiculously complicated forms without my head exploding does :) Of course if you work on projects with relatively straight forward requirements there is 0 advantage in using Angular or React for you. It always depends on the type of work you do.
The more complex the business logic, and the more options there are, and the more it is expected to change, the more it benefits the development team to write that code in their language of choice on the backend, close to the data store(s), using native classes/objects -- rather than being forced to write it in JS/TS, serialize everything to/from JSON, reliant on magic under the hood to lay it out in the DOM, with more and more "state" necessary to be managed client-side.
Why?
TS is maintainable and very pleasant to code in. Most people’s computers are way faster than making round trips to a server. You talk about serializing everything to/from JSON, but my phone can do that in milliseconds (if not faster). Compare that to 100-200ms of latency between a faraway server, and all of a sudden doing things client side makes sense.
Engineering is all about tradeoffs. I’m tired of people trying to make blanket statements like “React is always better”, or “SSR is always better”. It’s not, and we know it’s not. There are several successful, performant, maintainable apps written using React. There are plenty written using a backend framework and SSR too. Heck, there’s successes that use both!
The common denominators in the success stories? Competent engineers. And I expect a competent engineer can analyze requirements and determine what would be the best outcome for their target users. A booking site absolutely benefits from a front end framework that handles client side logic. It probably also benefits from a clever backend for processing the data after the user is finished with it. Let’s not pretend there’s a one sized solution that fits everything, because there isn’t.
A complex booking engine like an airline or Stubhub needs constant, almost real-time connectivity with a database, otherwise you risk selling product at a stale price, double-selling, selling to an unauthenticated person, getting taxes and fees wrong, missing custom post-sale add-on opportunities, and lots of other potential problems. The client has to make a lot of network calls, so you're going to deal with latency, there's no client-side solution that avoids it without risking the issues above.
The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.
You make a great point why we use client side solutions.
That's exactly why HTMX has gained immediate traction so quickly, it solves many of these exact problems elegantly and easily, much of the time without a single line of JS.
If only they actually worked like this. I’ve experienced, as I’m sure many other people have, problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails because I was too slow. It’s also much faster to only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page.
All that to say, there are tradeoffs. Finding the solution with the best latency and the best experience requires a careful analysis of all these details and figuring out which approach (or combination of approaches) solves that problem the most efficiently. Of course it’s not easy, but nothing you’ve said here indicates one solution would always outperform another solution.
Because they are typically written using popular heavy frameworks! Big, expert teams of developers can't get it all bug-free and fast and smooth when working with them. Thank you for making my point better than I could.
> only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page
You have revealed by this statement that you have no idea how HTMX works. You are making an argument against something you've clearly never looked at.
My whole argument can be succinctly summed up by this comment from a different Hacker News user from when React was first announced:
> One of the biggest problems with the web platform is that we've spent the last 20 years trying to shim applications into a document framework. HTML was designed to help academics share research papers, not to replace native thick-client applications, yet that's the direction it's been evolving towards.
> I'm really happy to see Web Components (inc. Polymer, Angular, x-tags, and React) landing into HTML. If we accept that web apps != web pages at a spec level, hopefully we can build an awesome platform on which to create tools that leverage all the great parts of the web (linkable, available, auto-updating, device-agnostic) without the mess that we've made trying to make the web do something it wasn't designed for.[0]
This sentiment, after 10 years, is still spot on. The web isn’t academics sharing research papers anymore. Interactive web apps, whether you like it or not, require a ton of client side state management. React was developed to address concerns with managing that state and improving performance where HTML5 fell short. It still succeeds at that.
Of course, if you have a static site, don’t use React! But let’s not pretend there’s no use case for it either. There’s tradeoffs. And I’ll repeat that til the end of time. No matter what you choose, there’s tradeoffs.
Maybe because HTMX fits all the principles listed by the author? Or because it's specifically referenced in the article (3 times)?
A tangential answer (focusing on backend not language) is because I'm (we're) going to have to reproduce much of the fronted complexity of the business logic on the backend to validate what the frontend sends.
I'm mostly agreeing with you. I've built multiple web-platformed insurance systems and booking systems in the last decade and moved from fully server rendered pages to client rendered forms. The complexity increased with that change but as you highlight once it's done the ability to test different frontend flows is great.
But I'd like a way to share more of the business logic rather than writing it twice.
The small projects are where the people I care about are struggling.
e.g. WhatsApp back before the acquisition
Making it easier for people to build big, complex apps doesn't favour large organisations with lots of resources. The opposite in fact.
However I'm taking about even lower down the food chain than this.
Then if that's not enough, you've got things like HTMX if you're keen on doing everything in terms of html templating, you've got tools like Svelte if you want an isolated chunk of dynamic UI in a mostly static page, you've got bundlers like Vite that just work without any configuration if you get to the point where you need a build step, and you've got a multitude of lightweight frameworks for the next step.
And on top of that, pretty much all the old ways still work. The browser is an incredibly stable environment! Outside of a handful of security-related removals, if it got into a mainstream browser, without a feature flag or an explicit "experimental" warning, it's pretty much there for life. So if you want to go back to the old ways, there's not much stopping you - but a whole bunch of quality-of-life development improvements along the way to make things even easier than they were back then.
And, while only a minority of projects are that complex, those projects are the ones most developers are working on. Most other projects are probably better served with a wordpress install and a bit of theme customisation. Which means it's going to be a minority of developers who work with the very minimal things that are sufficient in these sorts of cases.
I've used SPA frameworks, but try to avoid it if I can, because most of the logic is in the backend. I don't want to create and sync API interfaces, have 1-2 additional contexts (JS + frontend framework) and debug an extra layer.
With htmx I can now have interactivity via the backend. I use Alpine.js for some interactivity.
It's almost impossible. The first reaction is always `npm init`
You can still find developers who are using the basics, but mostly they're designing WordPress themes or working for boutique web design agencies, because those are the sorts of problems that are solved with just simple HTML, JS, and CSS.
It's like asking a Java developer when the last time they developed something without maven or gradle is, or Python developer why their first reaction is to use pip. If the majority of problems developers had to solve were simple enough that they didn't need these tools, then there'd be far fewer developers and most of them would still end up working on the 20% of projects where they're necessary. Because, well, that's where the complexity lies.
> It's almost impossible. The first reaction is always `npm init`
Consider a simple case — a static website containing several pages (it's simpler than anything requiring a dynamic server, right?). If you are a professional front-end developer, you are almost certain to prefer some kind of a static-site generator over copy-pasting the html template with repeated elements (header, footer, navigation) multiple times, because you know that copy-pasting will bite you when you need to change something. You could use a static-site generator written in Ruby (but then you would gem install), or in Python (but then you would pip install); or you could use a Hugo binary (I'd love to see anyone call its templating language simple); or, if you are a front-end developer, you might npm init && npm install eleventy. Is this too complex a step?
I dunno, I'm a Go dev, so it makes sense to me ;)
> Is this too complex a step?
If it just stopped there, sure, that would be fine. But it never does. My experience of front-end devs is that they will do anything to avoid writing any actual code. So there's a tendency to pull in dependencies and bloat the thing until it suffocates in its own complexity. I've seen node_modules with thousands of subdirs, and a build process that takes minutes, for really very simple sites.
something like this: https://www.hotelpalacebarcelona.com/
they don't care it's not "html first"
> I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks.
I wonder whether they ever pay off. First, I don't believe the frameworks you mention really, as you suggest, enable the last 5% of functionality that would otherwise be impossible. No, those frameworks are written in the same language they work in, which means that strictly speaking they do not enable any new functionality.
Second, whatever ease / speed of development you use must be weighed against the additional cost borne by the project's users. The time you save (that you might otherwise spend learning to achieve the same result without the framework) could be less than the time spent collectively by users waiting for the framework to load.
And what's good for one small project is likely to be good for many small projects.
For text at hand I understand that author expects this way should be “the best” for everyone.
Then author gives examples that even in medium project at first requirement change or first additional non-trivial rule are going to have 2-way bindings plus bunch of other plumbing implemented where “html first” doesn’t have it and someone will have to write some JS monster to handle state etc.
In what terms? Sites in existence? I suppose. But sites by usage? Virtually all huge.
I'm not sure that view is correct. For one thing, I'm not sure how you even define this.
As technology has advanced, many of the "small/medium" projects that used to require lots of dev time have turned into fully-built alternatives. The days when you need a dev to setup a blog are gone, as are the days you need one to setup a store, or a simple marketing website.
Are these part of the 95%? In some sense, yes, but in the sense of giving advice on a framework to choose, not at all, because no dev will even be making that choice - it's irrelevant.
As for medium-sized projects, there are tens of thousands of small, internal company tools that aren't even on the open internet. They probably fit your definition of being medium sized, let's say have a few devs working on them for many years, certainly medium sized compared to FB etc - but I'm not sure that whether this approach is right or wrong for them. (Genuinely not sure!)
I'm just saying, you need to much better define what you mean by small and medium sized, because some people might be thinking of my definition, while for some people medium-sized is, idk, AirBNB, which is tiny compared to FB but gigantic compared to most projects out there.
Their second principle, to use inline styling, makes it harder to create a consistent look across the entire website. Defining that in one place and referencing it everywhere is better and easier.
Big companies are in the minority and what they do would not classify as "normal" or "standard practice".
It really bugs when people say "it's standard industry practice" when actually what they mean is "thats how the big businesses do it".
When you make a product that looks like it works but doesn’t, they don’t understand. They put you on a path to overpromise and underdeliver.
One of the lesser known features of unit tests are that they give the code that management can’t see more QA prior to being wired up. They narrow that awkward window from first paint to shipping.
I've created my first website in 1999 with plain HTML, CSS, vanilla JS, hosted on Geocities.
Since then I've been using PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to create both sites and apps.
With React / TSX components / CSS-in-TS / Effects / Context I'm home. Finally a fully fledged programming language for the web / front-end. A language made explicitly for the front-end, built om modern principles like functional, reactive programming.
Now I can do software development. Before that, with HTML, CSS, plain JS, PHP it was ... just hacking, nothing else. (Rails was good for full-stack, was not shining on the front-end)
I'll skip frameworks when the web stack will be ready for the apps, too. Now it's (perhaps) good enough for sites, I should admit.
Like it or not, the web is an excellent platform for delivering software applications to users, especially one-off or infrequently used applications.
Let’s use software development tools, rather than web publishing tools, to develop that software.
As an example, shipping a macOS or iOS app, via official means, requires a lengthy review & approval process, upfront costs, buy-in into native languages with little to no use outside of these platforms, a limited selection of tools, and hard decisions about which version of the OS to support based on the features you need vs. the market share of older versions.
People (and teams) choose web development for the lower barrier to entry, and as a platform, browsers get products most of the way to their goals, and fast.
Is it your preference to install a new local first desktop application any time you wish to do any of these things?
I’m not against Web Apps, but many take my browser as free real estate.
At that point, I'm just going to start the project with React / Vue / Svelte every time because almost 100% of the time, I realize I need to support the features they offer that raw HTML/CSS cannot, or if they do, are very poorly implemented by browsers, hitting limitations with them that become frustrating and prevent you from achieving the scope you're aiming for.
Using any of those three libraries/frameworks is painless, and I can get a project going rapidly and with high confidence that I can support any functionality, interaction, animation, content, routing, and other common web problems, with great ease.
"But we need this and that custom dynamic logic..." well now we're in the realm of software development.
We will be doing something different in a couple of years and saying that the stuff we do now is out of date and the new stuff is home. It's always been this way. We are tech nomads finding ourselves new homes as and when we move on.
With the introduction of Angular 1.x and eventually React, Vue, and Svelte -- creating web apps finally felt productive, easy to debug, and easy to ship. Wiring up interactions finally felt intuitive. No more jQuery code colliding with itself as you struggle to organize your project and cobble together a bunch of poorly maintained "component" libraries and pray they work together without obvious user-facing bugs on your site or app.
Or worse: on a team of engineers.
I won't lie, learning how early build systems worked was a pain, but the curve was completely worth it, and I wouldn't change a thing. Today, using tools like Vite with their default project templates is almost too easy, and you can hit the ground running in no time.
Publishing to Vercel, Netlify, and other modern hosting stacks is a breeze, and they all support direct tie-ins with every popular package & build system.
I don't necessarily disagree that more components in browsers is a bad thing (I've been very happy to use the new modal element, for example), but I think the browser is working better right now as a lower-level (albeit still fairly high-level) platform that allows people to build a variety of documents and applications on top.
And to be fairer, it's generally a pretty good philosophy for greenfield apps at that particular point in time, but if I started an app on rails 4 or 5 there's no way I'm updating my front end every time they change their minds about how front end should work
They believe this now, in 4-5 years it'll be XYZ next thing
Basecamp (formerly 37signals) has a track record of challenging the status quo, whether in business or engineering practices and to actually be fair, they're not changing their front-end philosophy on a whim or to simply follow a fad. They're trying to solve real problems. In the past, their flagship product served as proof that exposed many established counter-advices as merely baseless beliefs. Over the years, they've demonstrated how many "bad ideas" could actually work better for you, once you allow yourself to become a bit more pragmatic.
They might not be BIG, but they're also not small. Imo, what they say and do engineering-wise tends to matter much more to average developers than what Facebook or Google might recommend.
I think the question stands, is Basecamp a good enough example?
To me it seems more like they’ve evolved it.
From Rails UJS using jQuery, to vanilla Js, then TurboLinks and onto today’s tools like Turbo and Stimulus.
The evolution isn’t a bad thing, and the older approaches still work in modern rails.
They’ve changed and updates the build tools, but then you have to keep up.
They went from Sprockets, to Webpacker, and then module loading to replace Webpacker.
So they’ve haven’t changed philosophy as such, it’s just considered and measure evolution and refinement.
Feels that way in practice to me anyway! :-)
It's been a long time since I used Basecamp but that was decent enough
Not everything has be a Large Enterprise Application.
This is why I reach for a view library like React, Vue, or Svelte, even if I'm creating something simple. This is because I'm familiar with using these and they provide me with the ability to implement nearly any kind of dynamic functionality or interactions I could want, fine control over component lifecycle, and tight integration with my CSS library of choice to speed up development.
End-users are none the wiser, that is of course unless I do a terrible job using these tools.
Then of course you're left to reimplement basic browser functionality that you now lost (or more likely, you just grab another package that solves that and throw it in your payload).
One semi-objective thing we lost was accessibility. Much of the site is impossible to navigate via keyboard due to naively re-implemented behavior like links being divs with click event listeners. It's actually somewhat worrying - when regulations hit us, we'll have to scramble hard to get back what we threw out.
But all in all I kind of agree with you that it's very hard to find high profile examples of sites that are "HTML first". I believe in it, but haven't actually seen it pan out. But I suspect the reasons for it not panning out might be purely in education. By the time HTML became powerful, frontend dev education was already deeply framework-focused.
Because the tools to create it are relatively new, and the sites you're speaking of had already been written. What high-profile site didn't already have a massive legacy React/Angular/Vue codebase, and a team of framework-trained developers, as of 2021?
TBH that's not a framework vs HTML issue, that's just sloppy or inexperienced devs
If the rendering framework doesn't support accessibility as a first class citizen (or better yet, automatically creates/makes accessibility part of what is rendered), then the framework is not suitable for production use.
> entirely on you
of course - choosing a framework or hand rolling one makes no difference. It's still not production ready, if it doesn't have accessibility built in.
Choosing, for example, whether to use a div with a click handler, or a proper button, is a decision you need to make regardless of whether or not you're using a framework.
So it seems incorrect to say that you lost accessibility in this case due to the framework. You lost accessibility due to developers who didn't understand the web platform well enough to design proper accessible controls. If they hadn't used a framework, they'd probably still not have made the site accessible.
And i actually think that it is _better_ for a developer not to have to do their own accessibility controls, but delegate this problem to the component framework. They have to know about the problem, but not have to spend cognitive budget thinking about it while they compose their UI from framework components - this should _automatically_ be taken care of by the design of the framework.
Frameworks also have linters that will help a lot, it’s on you to use them
Admittedly I had the same reaction you did as I was reading the article. All I could think was how poorly these approaches would scale when the need arose for even modest ly complex state management.
While the body of the article doesn't address this, IMO the title does. I think it's generally good advice to suggest only reaching for the tools intended for complex environments when they become necessary, not before.
The times where I could use the Python backend servers to also serve the frontend seem to be over for me.
You (and indeed everyone else) has no real need for heavy JS front end bloatware. Just say no. Serve light pages from the backend (or cache) and do all the fancy work in CSS (if you must).
Say hello to fast render times and global accessibility.
So many sites these days are so bloated and slow as to be unusable. Those of us devs who chose the other approach have to work harder no doubt but our users are much happier. Isn't that the goal, after all?
My current users value speed of feature release over almost anything else, because the system needs to adapt to their rapidly changing business rules.
In my previous job, correctness was the most highly valued attribute, followed by adherence to consistent design across the org (which was large, and produced many sites that a user would navigate between all-but unknowingly).
In either case, if I'd gone on a HTML purity rampage, I would not have been helping my users in any meaningful way.
This should be like three files max (one, ideally) on the BE and similar on the FE. Things I used to 15 years ago in a few minutes takes _hours_ even when you know what you are doing.
Vanilla JavaScript just didn't manage to solve what it kind of promised to solve via web components, the lack of templating is really a bad shortcoming.
I really do need things like Quasar and the stuff that Vue (and react) offer because it really helps a lot in usability. I've just been doing Vue with Quasar "by hand" via local CDN without compiling and it was such a win, but the more these frameworks evolve the less it's possible to ignore the fact that these are "modern frameworks" and the pain just grows too much.
Thought TBH the article's examples are whack to me. Why would I write pure <form> tags instead of using the Phoenix form helpers that print out errors and other nice shit for me automatically. I get the spirit though.
I used to be really big on this, though (and it makes me sad that these days most sites are 1 big unreadable line of HTML). In fact, I find a beauty and elegance in shipping the whole thing as a single HTML file with no dependencies (1 network request!), though I did eventually make a "build system" (my build system is cat) so I could have a sane editing experience. Boom, self-contained portable software in 1 human-readable file!
Along the same lines, I think the coolest thing about web development is that you can make your first (interactive!) programs with Notepad and whatever browser ships with your machine. (Just drag the HTML file onto the browser!) It's magic!
Edit: Just found an unexpected benefit of self-contained HTML: makes your software immune to bit rot. I tried loading an old project of mine on Web Archive but it hadn't archived the external JS file! Sad! Meanwhile, this one loads fine because all the JS is in the HTML! Winning!
https://web.archive.org/web/20210508133239id_/https://andai....
This is my homage to the old SodaPlay Constructor. (Never made an editor, sorry!) Feel free to view-source!
The "frictionlessness" of lowering the "activation energy", is not just nice for beginners... heck, it's nice for me! I can just download this file from Wayback Machine and continue hacking on it!
It does, of course, limit you to very small codebases, but that's what I like! Many small projects. The spring physics creature linked above is about 300 LOC total. The ASCII bonsai tree is ~100: https://web.archive.org/web/20220823113003id_/https://andai....
*In terms of tooling/setup, at least! Learning to code is another matter... (Neither of these projects are very readable for a beginner though, so that aspect needs some work.)
This is even easier now we have 'data:' URLs. It's also useful for avoiding problems on file:// URLs, which don't even need a HTTP server.
Customization isn’t required as long as defaults work. As such the efficiency gains from CSS etc take a back seat to simplicity.
With Tailwind you're trusting a 3rd party library to abstract the CSS spec for you, and for that abstracted quasi-spec to be followed by your build configuration.
Then say one component on one page now needs to be styled differently.
You have 3 options: 1. Create a whole new class which duplicates much of the previous class 2. Create a smaller class which is intended to override some rules from the first class 3. Factor out the common styles into smaller classes.
All have some maintainability concerns, but taking the 3rd option to the extreme makes the problem non existent in the first place.
That’s the real strength of tailwind. Preventing a critical mass of one off styles from making your whole css setup unmanageable
But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your overrides will take precedence.
Why not expose the component's styles via component-level tokens referenced through css variables? Then your new variant is a single css class on the component root that sets any new component token values that are then loaded by the component's existing css.
Most of tailwind’s classes use css variables under the hood, so setting some of those variables in a class and apply thing that class to the top level element of a component will do the trick.
But you could have an “extraClasses” prop with tailwind. Classes that appear later in a class attribute take precedence over one’s that appear earlier.
I also thing it’s possible to mark tailwind classes as important, though I don’t like doing that.
>Classes that appear later in a class attribute take precedence over one’s that appear earlier.
This would be news to me, and it doesn't look like that's the case in TW, based on some experimenting at play.tailwindcss.com. If there are 2 classes on an element with rules that resolve to the same priority and define the same css styles, the last CSS rule to be parsed wins. Presumably you don't have control over that in TW.
There is no harm in a plain CSS file, and applying classes at the element level in the HTML.
If you put in-line CSS in the HTML is not only leads to severe duplication, but is also a maintenance nightmare if you want to change anything. It works fine if all you are changing is a colour or whatever, but often there are margins, paddings, letter spacings, font sizes etc etc which lead to quite a lot of extra crap in each element on your page. Repeating those all over each if your HTML files is a real burden. Just use a single CSS file with sensibly named classes - it doesn't need to be sass or anything, just plain CSS is fine.
IMO you no longer need an intelligent naming philosophy for CSS classes due to how far CSS has come.
The reasoning is that maybe today it is just "green" but then what if one day the color in the CSS is changed, and it is not actually green anymore? You now either need to change the CSS class name everywhere, or leave it as "green" and confuse everyone because it is actually blue on-screen? This only scratches the surface - there are all manner of other considerations to think about (different display/print medias, dark/light preferences, HCM etc)
Frequently the change needed requires changing the html as well as the css (or maybe awkward advanced css). So you may as use a library/framework that lets you write an Approved component. At that point it's better to have the css and html for the Approved component in its own file as when you're updating the style you'll need to change some mixture of the html and css.
Without components tailwind is probably a bad choice.
Back in the late 90s and early 2000s, the dominant ideology is to use semantic class names, e.g. ".sidebar" instead of ".blue_bar" or similar. Essentially, don't describe how something looks with its name.
Even when building JS apps, I use CSS classes semantically with ".selected" ".menubar", etc.
I am interested in reading your philosophy on CSS classes.
Traditionally you put your template HTML or just HTML in one place, CSS in another, and JS in yet another, then tie them together via <style> and <script>. Are you saying there are frameworks that tie HTML and CSS together into the same unit? That is rather strange to me.
In such an environment, do people decide on no structure for their class names? I'd still want reusable CSS in such a situation.
It definitely adds extra complexity in the build step, and the resultant randomly generated class names aren’t very nice aesthetically.
However, this approach allows you to read and modify the CSS, HTML and JS that affect a component all in the same place, instead bouncing around between different files. It also avoids the problem of naming (and remembering) globally scoped CSS selectors, and generally results in less CSS over the wire.
If we look at HTML as a document / presentation language, we cannot deny styling. CSS is not only styling, but also adds animation.
In any case, CSS can be seen as aspect oriented programming.
The real problem described here is the lack of great tooling across languages / frameworks.
If "making the red-bouncy-plonk button instead become the blue-wobble-thunk button" requires chasing through a maze of 3-to-7 interfaces and classes to find which classes need new implementations and which can be reused... Suddenly what sounded like a 10 minute change becomes half a day of swearing under your breath at either the compiler or the previous engineer.
Sure, abstract things, but make sure there's also a way to bundle behavior together in one common spot, so I don't have to touch 6 files to update one component.
https://htmx.org/essays/locality-of-behaviour/#conflict-with...
And "separation of concerns" isn't?
What should be separated? Along what lines? How do we determine these lines? When does it make sense to pull some concerns out into another class/framework/markup/whatever? When does it make more sense to leave things stuck together?
The answer is: "It depends".
Not separating anything leads to spaghetti. Separating as much as possible, all the time, everywhere, leads to overly abstracted code that is easily as hard to maintain as spaghetti.
JS, CSS, and HTML aren't concerns, they are technologies that have cross-cutting concerns.
Some of these make sense and are obvious, like using only what you need (which is preached for half of the article). But the rest of it confusing, if not outright ridiculous. Why are we even assuming that being able to copy an entire HTML page is a good thing? Frankly I don't care, and it's not like there are literally millions of resources to use to learn HTML even if you can't view a few pages' HTML.
Idk man, kind of a head scratcher
This is how we started building websites until things started to break with side effects, conflicting class names, bad introspection etc. and React came to the rescue.
The pattern you want is progressive enhancement and your output to be clean, compact html that’s augmented by JS. Which means build step. Everything opposite to this article’s advice.
In my current company we started with HTML and embedded JavaScript at the bottom and Styles at the top. Everything in one file, very easy to find and understand.
It was "a little bit" slower. Pagespeed Insights didn't like it.
Now we are "modern" with CSS and JS in a build process. And nobody knows which file to look at...
My new Projects will start with HTML first, again.
My credibility: 45 years, commercial web programming >25 years, 3 successful web companies founded as CTO
People here say "show me this on a big project" well how about they showed us how the thing they are doing on a big project has turned out.
The cleanliness of HTML and CSS is astonishing. That's a quality mark in my view. If you to move away from that you miss out on certain aspects imo.
Every approach has its pros and cons.
Django for most (if not all) of the server-side code, Django templates generating HTML, htmx handling most interactivity with html attributes and, when necessary, hyperscript (for use cases that can’t be covered easily by htmx). I would probably stick with downloading minified Bootstrap for styling (Tailwind requires a build step, and I don’t think I have done well in the past when I waded into “class soup”).
Has anyone here tried something along these lines for a non-trivial app? How is it going?
I am working on https://github.com/claceio/clace which takes this no build approach and makes it easy to build portable applications, using Starlark running in go to configure the backend.
I’ve really enjoyed this stack. The structure just seems to click in my head better.
My experience has been that proponents of HTMX and the like skew heavily backend and never feel comfortable with CSS.
Why listen to UX thoughts from a population who are scared of UX?
Folks can disagree about how to keep the system simple when looking at it from different points of view. All those opinions are worthy of consideration.
What I am decidedly NOT happy with, is the frontend using as much, or even more, internal logic, magic, and build steps as the actual business logic.
To put this another way: I will happily listen to an interior designer on his thoughts about the color of the drapes. But if he tells me that this color means he has to bring his own crew of stonemasons, carpenters, and electricians, because somehow that color requires massive changes to the architecture and power lines of the house, I am going to grab a piece of cloth that vaguely has the color I want, and make the drapes myself.
But in the end, because of nature of things, slugish frontend has bigger affect on user's experience then slugish backend.
Overly complicated, architecture-astronaut code, that leans on frameworks for no good reason, is bad, no matter what part of the stack. And yes, this is true for the backend as well. There are people who will happily import 3 different frameworks to make a POST request in Go.
In other words, I’m not scared of UX in general, just not confident in my current abilities in UI (which is just one aspect of UX).
For every one of you who isn’t scared of CSS there are like 40 people into HTMX that make bad UXs even by the standards of internal company tooling.
Interfaces are as unique as humans are. There's a reason we have emacs, vim, and Notepad.
I don't often have a positive reaction to something like this, will definitely revisit it when I have the spare cash.
Show me a powerful program with a "good" UI by modern standards and I'll show you a mess. VS Code is a prime example.
Another powerful tool that is built on modern UX principles would be Fusion 360. In my experience, it makes me as a user much more powerful and actually provides more functionality in a more productive manner than its competitors and predecessor. Would be interested in you explaining how that UI is a mess as well.
I'm really just more at home in Vim and a terminal window off to the side. Microsoft's way of doing things has never really clicked.
I can't speak for Fusion360 because I don't know what it is nor have I used it. There's just an issue in UIs these days where they're either toy-themed (Twitch, Discord, Etcher, other "friendly" software) or so overwhelming that you don't know where to start.
Where is the QuickStart guide for VS Code, for developers? With MS in particular, they do a poor job of reaching out to developers and actually understanding how they work or what they like. Maybe they only serve a particular type of developer; an audience that I'm simply not part of.
"Recommends skipping build step then mentions Tailwind": We use static-tailwind, a version with no build step, in development.
"Recommends hyperscript, a new non-js syntax" - Agree this isn't perfect & would prefer something which uses js. Was going to use Alpine but also have found that to be quite brittle in production. Nor do I love any of the libraries on unsuckjs.com, which has a good collection. We're working on something here which we'll launch at some point.
"OP should look at the recent Rails updates" - Been using Rails for 10+ years - everything we build is on top of Rails - I'll write a post on HTML First Rails at some point. I think they'll get there but currently all the named libraries (Turbo, Hotwire, Strada, Stimulus etc) are 1. Rails specific, and 2. Have a high learning curve. One of the points of HTML First is to avoid framework lock-in.
"This is a blog spam post written by an author that has no credibility in the space": Brutal
The entire world: interesting in eng being more productive and interested in more maintainable software. So the first 2 sections are interesting.
You then chase them with a list of assertions with zero discussion as to how they make eng more productive, or lead to more maintainable software. Also without even a hint of why people eg prefer not defining styles inline (protip: fun at first. Now try changing one of them... have fun reviewing 3000 inline bits of css.) Like the industry settled on certain things for a reason, and you don't even attempt to engage with that reason.
You also cite dhh when you like his reasoning and ignore him when you don't. about which, well...
Though I do think some of your ideals are worth challenging either because I think you're making an incorrect assumption or holding too close to some particular dogma, it's always good to hear people pushing for simplicity in the space. Keep pushing :)
Is that even possible at this point?
Thanks.
So you do use a build step for production? Or are you shipping a bunch of unused styles?
https://html-first.com/stylesheets/tailwind-full.css 68kb of blocking unused css.
In total ~100kb of blocking scripts and styles. Most frameworks would optimize this for you out of the box..
https://github.com/tonyennis145/dumb-tailwind/
Is it this? (A 3.9 MB CSS file?)
My personal gripe with build steps is not the build step itself, rather the unreliability of the JavaScript ecosystem and the often head-scratchingly opaque error messages.
Build steps such as a hypothetical `css-compile` don't address limitations of browsers, but limitations of network connections that may struggle to download (and frankly, at 3.9 MB, devices that struggle to parse) large amounts of CSS and JavaScript.
Even if browsers can download multiple files at once, they can't download files they don't know about, which is why ES modules in the browser haven't taken off as a way to eliminate the build step.
The last two decades of web UI framework development has shown, over and over, what people need out of HTML that they're not getting. Componentization is one big area, and fortunately, it's already far along the path of integration into the native web platform. But there's another, bigger, area, which has not seen a single ounce of integration into native HTML: reactivity.
So what if we could just solve that? What is preventing us from adding native reactivity to HTML, a language that already contains numerous interactive elements and hard-coded ties to JavaScript? Seriously, why is this not already implemented when we have things like Shadow DOM out there already?
We could get a huge amount of impact with just minor changes. In my view, HTML could meet 90% of peoples' reactivity needs with just two simple tags:
1. `<sync value='variableName' />`: Renders as a text node that shows the current (live-updated) value of the referenced JS variable. If the value is undefined, renders nothing (special case).
2. `<test if='variableName'></test>`: Renders as its children if the referenced JS variable is truthy, and as nothing if the variable is falsy.
That's it. Just these two almost-trivial tags would solve an incredible amount of use cases. And with sufficiently expanded componentization (say, React-style props for `<template>`), the web platform would be well positioned to cover all others in time as well.
Some of these points I'm a bit confused on... is the point behind "Where possible, maintain the right-click-view-source affordance" supposed to be to make the learning barrier lower? While I understand the sentiment behind this, tools like React or Angular have significantly lowered the barrier to entry in their own ways.
I am yet to find a reason for using frameworks like React instead of HTMX.
>You have to return the html object from API which has its own set of problems.
If you mean that HTMX can't consume JSON. Can't you just create a separate end point for JSON responses?
This is patently false. It is being used in multiple significant production systems:
and many more. There are times where htmx isn't the right choice, but the idea that its not useful for anything more than a hobby project is simply false.
HTMX tries to reduce the complexity.
By the time you create the correct abstractions, customer needs and the market will have changed and thus your abstractions are now incorrect
Sure, if you have project like facebook then you problably won't get away from complexity, and you NEED a tool to help you manage that.
But at the same time, if you assume you need such tool from the beginning, chances are you will over-complicate your solution and it will become a self fulfilling prophecy of trying to tackle complexity by adding more complexity
React will require you to hire a React dev to handle all the complexity.
htmx will be mastered by your "back-end" devs (who actually are web devs) in less than a week.
Throw in the usual pile of libraries used with any larger react app and it can easily take months to really get moving.
This thing (and others like Vue, let me be clear) adds many layers of complexity over the web platform (client-side routing, data fetching, state management, rendering, etc.) and many third-party JS libs that you have to constantly update. You just can't say that it's standard/base web development.
- No complex build set-up (just link the script & use it)
- Less congitive load when reading the code. Especially if it's not yours.
- Very decent learning curve.
so "just shifts it somewhere else" might be underselling it a little
Note: I totally agree that we should strive to go HTML first. However, this specific example is a bit unfair.
As a demo, I was able to build a chat app with it: https://saasufy.github.io/chat-app/ You can log in via GitHub OAuth (also implemented with HTML tags).
Less than 120 lines of HTML markup in total for the entire functionality.
The source is here: https://github.com/Saasufy/chat-app
There is no custom backend logic, all the logic is in that repo as HTML + CSS.
> Proceeds to insert JavaScript and CSS into HTML attribute.
> "HTML is easy to understand"
> Proceeds to import external JavaScript library which uses an ultra-obscure, totally unclear HTML attribute `_=`
My personal preference is server side templating using as much default HTML as possible with JS as progressive enhancement (using HTMX or something similar).
This removes all the preset browser css styles. An accessible,styled <button> is much easier to achieve than an accessible, styled <div>
I suspect the answer is that screenreaders don't look for all clickable elements and are naively focusing only on buttons.
Logically it should be the reverse. Screenreaders can learn how to detect all clickable elements instead of shoehorning a form control element into places.
I find this “dishonest” to the overarching ideals of this manifest: If you want to follow standards, and allow view source, you can absolutely write vanilla JS, and end up with more idiomatic and approachable source than
_="on input put me into #output"
Of other points, I especially like the “no built step”. A native support for JSX would really smooth out the path from vinalla to React.
But these arguments seem a little tired now. Does a customer actually care what technology you use - absolutely not. If react is easier for you, go for it. If that’s HTMX - fine.
What matters is speed of delivery of new features. And react has huge amounts of support (and a large developer base) that makes development quick and cheap.
I’ve never understood these html purist arguments. As if React/Vue/Angular are desecrating this pure text language.
There are other issues of far greater importance - accessibility, multi-language, browser consistency, sane defaults and easy tooling.
Of course, neither of these things are guaranteed in a React app. But they're definitely way easier to back into by accident.
<div class="bg-green" onlick="this.classList.add('green')">Click me</div>
I'm not sure what that looks like, because if it gets complex enough it's a sign I need to refactor, imo.
It worked, it was a lot of fun to write because it went really fast, even with some bells and whistles. Whole thing was my escape hatch when datalist attribute didn't work. It also worked well.
Alpine JS feels like a simpler version of Vue 2 without a build step and without any of the complex or confusing stuff (and of course with a focus on HTML not rendered by JS).
But when I saw what this turned into as a BE colleague copied it to the next form, making some adjustments... oh my, I prefer external and reusable JS (or a JS-first approach to templating, like React) any day.
Still, Alpine is really awesome for minimal interactions and simple JS.
When working outside React, it's hard not to miss it for the simplicity of doing everyday stuff inline in the HTML.
It definitely does have a maximum size of project it's suitable for. In particular, it's thoroughly individual-component-based; changing anything outside the component requires tacking on non-native hacks, and doing a full interactive app with it would be a painful exercise. But for adding simple interactivity to a primarily server-rendered web page, I've found it to be quite useful.
Copying still happened, take that as you will - in this case that was the problem :) Might be my implementation was not generic enough, but tbh the colleague was not especially proficient at JS. We had a productive conversation about this, but this particular project ultimately was lost by my former employer. The reason was not this autocomplete component though :)
I'm not
To build it I used my own library called HTMF[^2]. I started out using mpa-enhancer[^3] but found that that pattern is a little to janky sometimes. I think reloading a page every time on every interaction uses too many resources for a browser especially when you use a phone that doesn't have as much power as a laptop.
But overall I find the pattern very easy to use and keeps the complexity down.
I think some of the issues with traditional SPAs is that they have a lot of state and state is nonlinear in complexity. But using templating systems makes the complexity more linear in nature.
Also, I find libraries like React to be overly complex for what it does, see above. The way React works is just odd and counter intuitive. All for problems that are easy to solve. I do think there are places for a React-like library is needed but those are for websites that are inherently highly state-based. But most websites aren't state-based even ones that appear to be state-based at first.
The websites I work on are usually just forms and forms are pretty powerful and can get you a long ways before you need to go outside of that paradigm.
[^1]: https://github.com/jon49/Soccer
Sliding open guides the user that something has changed, improves the UX.
I've found that using the `open` attribute in CSS behaves differently across browsers as well. Sometimes it doesn't even work consistently in a single browser implementation.
Don't use React for web pages, don't use plain HTML for application interfaces. But don't pretend that web pages and application interfaces are the same thing just because they both use the browser, or because "the application runs on the web".
> The main goal of HTML First is to substantiall widen the pool of people who can work on web software codebases.
Fair goal.
> A second goal of HTML First is to make it more enjoyable and seamless to build web software.
Also a fair goal.
> The way we achieve these goals is by acknowledging that HTML is very easy to understand, and thus using HTML as the bedrock of our product - not only to define content and structure, but also to set styling and behaviours.
It's not. It's a large, heterogeneous collection of behaviors based on the arrangement of various tags with coupling between the tags defined by hundreds upon hundreds of pages of individual tag descriptions. And that's before we even consider that there's a matrix of browser compatibility layered atop that.
If I code up some complex behavior in React (such as the details-summary example here), the result is obvious, shows up in the deubgging tools, and works on every browser that supports React. Most importantly, the knowledge is composable: that approach to showing and hiding content works regardless of the content being a "details" and "summary" or a shopping cart contents pane or a modal dialog. With vanilla HTML, every aspect of the default behavior is dictated by the browser, and very few pieces compose with each other sanely (what happens when I nest <details> tags? I have to try it to find out; if it's a React component, I can read the JavaScript and know).
I'm not saying one shouldn't use vanilla HTML or should only use <div> with style for the whole layout or anything like that; there are semantic concerns that make using HTML where possible a good idea. But I'm not going to trip over myself to memorize every behavior and interaction of the declarative HTML model if it's easier to build things like collapsible details tags in React.
Why can’t we be honest with ourselves and admit that our pet projects are just pet projects? Not everything has to save the world or even take any sort of moral stance at all!
HTML attributes are no silver bullet. You can still have a bloated framework that puts some ill-fitting, homegrown data model over your code and drowns the codebase in "magic", even if all the interaction with that magic is through HTML elements and attributes.
Generally, I think there is lots of good advice here, but I don't really understand the "messianic" attitude of the HTMX crowd. Why all the effort to actively discourage any other approach?
Encouraged? Huh? We spent YEARS splitting logic from presentation and not describing presentation with visual characteristics.
This is a terrible idea.
I've been told by quite a few Tailwind users that they much prefer it because it bring styling and markup into the same place. In their view markup and styling are so linked that splitting the code up is painful to follow and maintain. This onclick example follows the exact same argument, that the click handler is so tied to the markup that it should be inline.
https://benkoworks.com/your-templating-engine-sucks-and-ever...
It fits nicely with this goal. My colleagues and I created a tool that allows HTML developers to work in HTML by compiling HTML using a Chrome extension, and then allowing developers to compile the same in their code platform of choice and operate on the DOM:
https://github.com/iaindooley/Fragmentify
https://github.com/iaindooley/fragmentify-js
Even if you're doing a SPA you can use this same method, by sending updates over the wire and doing the processing on the server. We created a standalone package that facilitated that by loading the initial page from the server then transparently allowing the server to send just the changes to the page and having them applied on the client side:
https://github.com/dgrinton/remote-standalone
The combination of "remote" and "fragmentify" and Template Animation/DOM Templating, in my opinion, would be a tremendous "retreat to move forward" in web development technologies.
Personally, I don't care for web "apps", seeing the unique value of HTML rather as authoring format for web "docs". For mere apps where JavaScript is obligatory anyway, I think I'd actually prefer CSS-in-JS.
All the templating, but without the language or libraries to support its interactivity, navigation, data calls, calculations, you name it.
It's rather quite silly.
Rather than using Tailwind, applying BEM syntax to styles in an inverted-triangle style has been good for existing websites where using Tailwind isn't an option. Especially if the code has very clearly defined components.
Instead of inlining the JS, I'll still keep that all pretty separate from the HTML. That's probably the thing I disagree with the most here. Maybe very simple things could be used this way-Might be a case-by-case decision there. It's also nice to write a few JSDoc comments to help bring some TypeScript-ness to the table.
I like the push for being more View-Source friendly. My work pushes for squeezing out as much performance as possible on a site, but even we have found that build steps for things like minifying/concatenating has diminishing returns compared to the overall workflow overhead when there is probably an image on the page that could be trimmed down.
Like what a lot of people have said here, I think much of it comes down to what you are building, too.
<button onclick="this.classList.add('bg-green')">
Click Me
</button>
There is a reason why semantics are more important than the concrete style and why they are separated. HTML and CSS first is a great idea but show more care for your users.
HTML is a presentation layer, as such it's 99% the output of some other layer. HTML first therefore is the wrong mindset.
You can't have an HTML first CMS for example, that's a recipe for spaghetti disaster. You need to define clear, constrained models that then you can adapt for given media.
I feel almost weird arguing with this site, because in general I also prefer simple HTML where possible, and I can't stand overdesigned JS-generated framework monsters.
But going from one extreme to another is not smart. No simple rule is a substitute for "intelligence first", and intelligence has lots of subtle rules and relies on rich context to make the right decisions for that context.
Nice domain name though.
For example, <summary> only supports a weird set of child tags. Personally I like <details>, but due to this constraint it is not always appropriate. Certain aspects of its native style cannot be controlled.
Many event handlers are awkward encode into onclick if not impossible.
"Naked" HTML requires a lot of boiler plate. The form helpers that are discouraged relate to validation, error reporting, form authorization, and localization. It's not an obfuscation layer.
The encouraged styles are easier on the eyes for now, but it's easy to imagine them developing into issues which would be the subject of some ticket, or else disappearing due to general improvement to the code base (DRY principles, SoC, UI touch ups, etc).
In big projects, the generality of codebase and faster option to do one off tasks matter more rather than best design for the current task. And it is lot harder to have making codebase small or without libraries as a requirement.
> Can html be styled well enough and simply enough so that anyone can write for the web, using just a text editor, and share that work with anyone else, regardless of the platform they are using, the speed of their connection and any disabilities they may have?
https://s3.amazonaws.com/simpleuseful/index.html
From the old-school Introduction to Web Design:
https://web.archive.org/web/20210414030104/https://www.cours...
My main criticism is that you cannot really advocate for "View-Source Friendly" HTML with the view of widening the pool of people who can work on it, and then simultaneously recommend that people use libraries like HTMX or Hyperscript that have their own unique syntaxes that aim to be compact and concise, but actually are just confusing and unfathomable unless you are already familiar with them. This flies totally in the face of the main goal of this site because you're advocating for people to use niche and sparsely-used custom DSLs for coding part (...yes only part!) of your site's business logic.
I also don't really see the value in trying to aim for view-source compatibility on a page-by-page basis - a better approach might just be a link to your source repo in Github (or elsewhere) that contains your entire project along with e.g. README.mds etc. And if you expect people to "view source" to learn, how can you expect people to do that when you have inscrutable non-HTML/non-JS nonsense like `_="on input put me into #output"` in there? I get it - I learnt HTML originally back in the day by looking at the yahoo pages source code, but we are not in the early 90s now: people can learn HTML from other places these days that offer a better experience than looking at a sites source in a vacuum (e.g. Github but also so many more ways now than those early days - there are millions of decent online courses, youtube videos, bootcamps that teach the syntax (i.e. all you get viewing source) as well as the rationale and the reasoning for decisions made and approaches used)
I would modify this guide and offer some different/additional advice:
- Use vanilla JS + vanilla Web APIs (Element, Fetch, Promises/async-await etc) for all business logic, and split code into modules (e.g. https://byexample.xyz/javascript/ECMAScript2015/modules/ ) so that your code is simple, has fewer dependencies, and is understood by 100% of web developers (unlike HTMX, Hyperscript et al that no one understands without having to go specifically learn it specially)
- Use HTML-based Forms validation rather than custom-logic wherever possible.
- Structure your DOM logically and use the correct semantic HTML elements for their intended purpose (e.g. use <button>, don't use <div onclick="...">) so that your page is accessible and easily navigated by keyboard users ("power users" and otherwise)
- Either add CSS classes directly via inline handlers, or do it via javascript, but whatever you do make sure you are consistent within the same project.
The most crucial (half made) point here is that if you want your website to be useable beyond the output, document it ... include comments, make your reasoning explicit and not implied. And yeah, a repo is probably a great place for this. It doesn't even need to be linked on the visible part of your site (I mean, who's the primary audience here), just do the old "we're hiring " trick and print a link to the site's GH in the console. The docs will probably solve a few problems for you too when you need to change things down the line (I constantly read and improve my own comments during refactors, and usually kick myself when I haven't made them).
In my case, I decided to keep using jQuery as opposed to React or other newer frameworks when I started building an app I was getting ready to update around 5-6 years ago. Not because I found anything negative about React.js and other, newer, JavaScript libraries, but because jQuery still does what I needed and I was familiar with it.
I have no doubt that React is a great choice for teams but end users don't care at all about what's under the hood, they care about usability and stability. What I cared about was my personal productivity.
If I were managing a team I likely would've used React.
Yes, I could have replaced jQuery with Vanilla, but the syntax for jQuery is still so much simpler, and I care about my limited time and productivity. For me to switch over to something like React would be complete overkill.
Again, as part of a bigger team, like you, I'd most likely consider a different approach.
Imagine if an iOS developer posted a blog about the specifics of files backing UIViews and how the XML configuration language was underutilized.
Wouldn’t that be kind of a weird blog post? The declarative syntax of various UI frameworks is an implementation detail. The hard part is in CSS on the web, or style properties in native frameworks. Business logic as well. Presumably encapsulated in a component, which React does well and web technologies are catching up to.
Why should I care about this, any more than I should care about XML config files on Android? It’s a markup language that is an artifact of the runtime we’re using. I don’t care about that in other contexts, and it’s the least interesting thing in a web development setting too.
Whether to use an HTML first approach or something heavier like React depends on the product being built.
I originally learned to code with HTML, CSS, and JS, and I think it's still the easiest way to experience the magic of shipping a working application to others. We should keep encouraging more patterns and tooling that lower the barriers of entry to those just starting out.
Best practices are generally called that for a reason.
It doesn't make sense that you would want to PUT a form apparently.
In my opinion, it's consideration as unsafe isn't intended literally. It has more to do with:
- The human error aspect of understanding and tightly implementing CSP,
- Separating style and JS into their own files provides some security as is (and allows ignorance of CSP to continue even though it has it's use case here as well).
Now, if your company takes this pretty seriously, they likely require that CSP should be part of your security process already. If that's the case, any use of unsafe inline in your markup will be blocked by default until concrete steps are taken to have nonce or hash in place.
Edit: I did not intend to sound harsh - just wanted to chip in about the nuances about the possibilites we are provided :)
---
[1]: https://web.dev/articles/csp#inline_code_is_considered_harmf...
[2]: https://www.w3.org/TR/CSP/
[3]: https://content-security-policy.com/nonce/
If someone writes the bonkers code in the article’s bad examples, I guarantee their “HTML-first” code will be just as bad.
We lost that war once, I don't see why we would win now. I'm saying "we" because I am particularly for this approach, too.
Don't get me wrong: I absolutely hate React, and am very cinical about the whole "server side rendering" fad (well, we've been doing server side rendering for 30 years, right?). Still, I think the overall web community simply does not care enough, so I've kind of given up.
If people are looking for a way to build native web-components using HTML-First principles, I've been working on a library to do just that!
I think Dreamweaver MX introduced something like template files, and it would make a "build" step that would copy the files from template to actual html files. Then it started to get complex, with data sources and generating pages in the backend. (php, asp, cold fusion?)
I used XSLT and XML to build a video game collection tracker. Just a page that could display things. It was a nightmare. I later spent a weekend building it in Python, added "export to JSON" and then made a tiny SPA with vanilla JS to do the job.
It's very powerful and can do some neat things, but it's taught poorly and not easy to teach yourself.
It's out of fashion these days, sure, but you could easily make e.g. a forum or a news site or a blog or a facebook type of thing. Anything where you want, well, templated html. So almost all of the web.
I know once upon a time the WoW armory was built with xml/xslt. It's convenient because then you've already also automatically got a data API; just ignore the stylesheet.
There's still an appreciation in me for XML (specifically SVG), so maybe I'll try something else with the tech. Care to share a link or example to more of what you're talking about?
> substantially widen the pool of people who can work on web software codebases
This isn't a problem. There's already more people who can work on web software than there ever was.
> A second goal of HTML First is to make it more enjoyable and seamless to build web software
Subjective. If people enjoy it like this that is fine but these shouldn't be touted as principles everyone should follow.
- https://developer.mozilla.org/en-US/docs/Web/API/Document/qu...
- https://developer.mozilla.org/en-US/docs/Web/API/Document/qu...
- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- https://developer.mozilla.org/en-US/docs/Web/API/Element/ins...
- https://developer.mozilla.org/en-US/docs/Web/API/EventTarget...
- https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
Edit: Forgot two things:
- You can disable the `fieldset` attribute to disable all inputs within. So properly nest your forms and you‘ll have a simpler way of controlling forms.
- Buttons can have a `value` attribute which works great to differentiate between various action paths for e.g. list items (delete, edit,…)
I have been disabling javascript for a lot of websites during the last year, the experience is not damage at all, it's the oposite, you get a snappier navigation, no ads tracking and if you have bandwidth issues you now can browse those sites without problem.
The drawbacks, some interactivity is lost, but nothing major.
The popular pattern of constructing React components with Organism, Atoms, Molecules and so on, makes following an unfamiliar codebase a nightmare!
JSX is hard to use in my eyes.
At first I thought it must be me, but I’m glad there is a movement to reject all this front end React based madness.
Building API layers with GraphQL and React on the front end just for a few business forms is madness!
I also really like writing software that builds HTML to be served as a static page. E.g. https://gist.github.com/HalCanary/61276afbab042e204e54268f6a... Then that complexity is hidden from the client.
But some of the things being spouted on this site are junk:
<button onclick="this.classList.add('bg-green')">
Click Me
</button>
This is an unmaintainable mess.
I started messing with early web dev stuff in the late 90's. It took over a decade to finally get enough momentum to move people away from this kind of crap.
I'm going to lovingly refer back to https://www.csszengarden.com/. Separation of concerns is a good thing and should be used as much as possible.
I'm not aware that an inline style, and particularly the inline JS in their example can be nonced to prevent script and style injection.
So no. I will not be following that part of the guideline. Not until the security aligns with reality.
Of course, I am not talking about the abomination of "semantic web" we had a decade ago.
<button onclick="this.classList.add('bg-green')"> Click Me </button>
This is going to be problematic when it comes to debugging. I still think scripts should be in a file and loaded in the header.
I have to admit that managing asynchronous js callbacks is really a pain to deal with.
JS is really an awful, awful language.
What does SPC stand for?
Programming, like life, is a flat circle.
React was designed to address complexities. It is an abstraction.
Now we want to go backwards. Getting rid of the abstraction to get rid of complexities. But getting rid of complexities was the whole point of react.
The purpose of react was to simplify the complexities of front end web development. Just like the purpose of the DOM was to do the same thing.
Now this article is pointing to going back to the DOM for a similar purpose. The cycle on the great circle of life occurs because we are repeatedly attempting and failing to fulfill the singular purpose of building a clean API for ui construction.
The dom was a failure, react was a failure. What do you think going back to the DOM will do?
It'll give me that extra 50% effort back. Although I've used React for years, I have never been on the bandwagon. Having built many React SPAs with different teams at this point I'm confident it has always been a step backwards.
By stepping back we are just going back to the same problem.
The next abstraction will attempt to solve the same problem again. Very likely in a similar way react failed, the next abstraction will introduce new issues and there will be another trend to go backwards again.
I'm saying we had problems with vanilla js initially and we've never moved forward. The fact that we are going back to vanilla js is reopening all the old issues are a sign that we are in stagnation.
Nothing has changed. It's a circle of attempting to improve and failing.
The front end UI isn't a collection of evolving standards. It's the same standard with more and more cruft added on top.
HTML wasn't designed for what we are doing with it now. Each additional layer... css, JavaScript, the dom, typescript, react, is a new layer over an old thing. It's like never buying a new car just modifying your old one from the 50s to stay up to date. That's why the entire front end API feels so bad. It feels disorganized with complexity that exceeds necessity.
The complexity of the spec even took years for browsers to get right. This is not a sign of good design. It's a sign of endless designs layered on top of each other all in vain effort to modernize everything and keep it backwards compatible.
You're right the dom will remain in the picture for a long time. Doesn't change the fact that it's horribly designed.
Facebook (rightly) said the VDOM was needed at because of rough edges around the performance of DOM implementations in assorted browsers. The DOM has improved over the past 15 years or so to the point where things like HTMX and AlpineJs are viable for more use cases. React and the DOM have not failed, they are tools that have their uses and limitations. Looking for one solution to rule them all is ultimately an exercise in futility and disappointment. Instead we should be looking at ways to integrate React and hypermedia so they interoperate more smoothly (e.g., web components or similar solutions).
>Looking for one solution to rule them all is ultimately an exercise in futility and disappointment
React and the dom were also exercises in futility and disappointment. They didn't seem that way at the time but as time went on it became clear what their problems were. The same thing can be said of htmx and alpine and whatever big framework that comes next.
Additionally who says their can't be one solution to rule them all? You think if your quotation eludes to some fictional story of lotr suddenly it makes sense? There is nothing in reality or logic that says we can create a design that can do better than all the apis that currently exist.
This idea that you can only male tools that do one thing well is fundamentally illogical. There are tons and tons of tools that do multiple things well. Take your car. It doesn't just get you from point a to point b. It air conditions you, it plays music... It provides safety, it gives you directions.
I don't think of it as "going backwards", so much as reassessing and questioning the tools we are using and using the best one at hand. I don't know of anyone who suggests using hypermedia for all applications, just use it where appropriate and use React when simpler technology falls short.
Because the source was too complex.
Now we want to expose the source and get rid of the abstraction... Why?
Because the abstraction is too complex.
Recurse and repeat.
TypeScript ecosystem is the Enterprise Java of this decade, except it's built on shakier foundations, i.e. you can run some ancient JVM, but good luck relying on an ancient browser version & node dependencies. There will probably still be tons of job-security in the next couple decades, but it's not forward-looking technologically.
Ironically you mention the jvm which further proves the existence of the flat circle.
We've done it before... We will do it again.
At some point wysiwyg editors fell out of favor as they generated both unmaintainable styles and markup.
Style sheets took hold and the insanity that was inline styles were dropped in favor of external style sheets.
Today we have tailwinds.css and inline styles are coming back in vogue.
Wysiwyg editors are coming back in the form of code generators that convert designs into react components.
This author is even a proponent of inline event handlers which were the standard way of doing things before JavaScript really became a powerful language and added "addEventlistener".
Flat circle repeated over and over again.
Part of me wonders if these authors are just too young to remember those days. Otherwise why wouldn't they mention the historical context when writing these kind of articles?
It's funny when younger people espouse these new ideas as new and revolutionary when really they are a return to older patterns that fell out of style for whatever reason and are now being resold with different packaging.
Thus, History is doomed to repeat itself as software technology moves horizontally forever, with practitioners never knowing if the current abstraction was better than the previous one.
Top quote in the article
> I don't think computing is a real field. It acts like a pop culture, it deals in fads, and it doesn't even know its own roots. And worse than that it does not know about the really good things that were done in the past. — Alan Kay
Once upon a time these first principles were the bedrock of web development.
I don't see why this is beneficial
"<button onclick="this.classList.add('bg-green')"> Click Me </button>"
I don't like this at all
I say build software in the way that you like. Or the way the boss says.
Or check out DHH's most recent thoughts on minification etc.
Even more, the author uses every possible library under the sun, from Tailwind to Framer, only to evangelise about raw HTML and topics he provides no credibility on.
To add to that, even the links to learn more about their agency all lead to Twitter, rather than LinkedIn, Clutch and Sortlist.
I think it's showed up on every app I've worked on for the past 5 years.
I think it's fair to say a practice is niche if you don't see it anywhere and appear to be one of the few talking about it.
Let's see your website.
Probably some "entrepreneur" chud.
It’s neither “enjoyable” nor “seamless” to manually synchronise the backend, the frontend logic and the DOM of your app without frameworks.
And maybe the trite talking point of helping young developers by sending unoptimized unminimized comment-rich source code directly to end-users held at least some weight in the 00s; nowadays we have an abundance of tutorials, courses, conference talks and open source projects that can help autodidacts to learn anything related to web development.
For “apps” vanilla js isn’t enough.
But for a blog with some animations or simple validation, things like next or gatsby is WAY too much
The web has moved far beyond a document sharing platform. It’s the largest, easiest (for users,) and most compatible software development and publishing platform ever. By far.
It’s not good for everything all the time, but it is good for most UI focused software most of the time.
When you build an app on Electron, you're forcing the client to run another browser, alongside whatever other browsers they're running. Due to the complexity of the Web, running a browser now takes hundreds of megabytes of RAM, sometimes a gig or two. Now imagine you have 8 different Electron apps you use. You have the system resource use of 8 separate browsers now. Congrats.
Secondly, there's no integration between Web apps and the OS. Only recently did things like light and dark mode get OS-level support, so there's that much, but long story short, Web apps don't integrate well with the system. They tend to be shipped in containers, too, so while it may be "good security" it results in a worse runtime environment and uses more resources.
The Web is a document platform, first and foremost. The building of V8 and Node.js, the myriad frameworks, etc, are the result of companies trying to turn an existing protocol into a moneymaker. Tim Berners Lee never intended the Web to be an application platform or a vector for DRM. For-profit interests created all of that extra complexity, and took over standards committees to push their ideas through.
Web apps work best when they take advantage of some of the Web's strengths. If your program needs to talk on the network a lot and it's already working with HTML, then yes maybe it should be a webapp.
The problem is everyone's ignoring the complexity, resource use, and tangled knot of abstraction on the client's end. It's "not a big deal", until it is, then we'll go back to rediscovering how easy native development is with a smart enough Makefile. All the major UI toolkits are cross-platform, there's little excuse.
That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing.
...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those. Anyway, View Source is a good way to learn how to do something you see for the first time. It's a necessary feature to double-check what's being sent to the browser when you're developing, too, and keeps website operators honest by giving you a way to inspect how they build their site.
Personally I think webapps are the wrong solution for a ton of problems, but the industry won't accept that until the bottom line is affected. I'm waiting for native apps that communicate over the same commercialized protocol. QUIC but its own piece of software instead of co-opting the Web.
But they are a thing now.
> ...Conference talks? lmao your class is showing, the average self-taught hacker can't afford to go to those.
An average self-taught hacker can afford YouTube. That’s why I explicitly mentioned talks and not conferences per se.
> Anyway, View Source is a good way to learn how to do something you see for the first time. It's a necessary feature to double-check what's being sent to the browser when you're developing, too, and keeps website operators honest by giving you a way to inspect how they build their site.
Opening up source code is a choice. And if a creator wants to open-source their app, I would rather look at it in GitLab rather than in production.
The web has evolved and taken the place of desktop apps by and large. That is what SaaS has done. These websites are built to be fully functioning pieces of complex software. Using some tiny tools to markup html is never going to work for these types of applications.
I find this hand wringing over the complexity of the web so strange. Can we all just move on? The web has changed. I have been programming for over 15 years professionally. Yeah its changed. yeah frontend frameworks are a pain in the ass a lot of the time. So lets make it better, not fall backwards to a “simpler” time.
We now have Framer, Webflow and all the others, you don't have to write any code to make amazing websites.
Even if you have a fully static website you generally have a navigation bar and footer that needs to be on multiple pages.
Things don't need to get very complex to benefit from frameworks and tooling.
I've used all the things mentioned, and I quite like the ergonomics of frameworks for static websites. Added benefit is that I can make static sites dynamic if necessary.
And to be clear, these static exports are incredibly fast and performant.
> you could roll your own SSG in a weekend
Sure, I could do that, or I could build my app/website in that weekend..
Sure, you can make plugins for Pelican to make it generate things the way you want, but it's still just a generator/builder using Jinja templates and Markdown or some other text transformation tool.
Also, there's no real indicator that I used Pelican to build my site. There's no cruft I'm including in my <head> element or anything else. It outputs regular-ass HTML.
I'm sure it's nice to be able to swap into dynamic web app mode if you decide a project's going differently than expected, but I don't run into that much with the things I design. I usually know from the beginning which tech I'll need to achieve the goal.
Frameworks force the dev into specific ways of doing things, so if a program fits into that architecture, go nuts. I'm curious what you guys need on your sites that require so much JS.
> Frameworks force the dev into specific ways of doing things
Not really. Take Next.js, you can also use markdown (or more dynamic flavors of markdown like MDX/markdoc), you can use a headless cms, it doesn't really matter..
If you don't like Next.js you can pick a different solution, there are many! If Pelican is your jam, by all means, it's a great tool.
> I'm curious what you guys need on your sites that require so much JS.
In my day to day I work more on web apps, but lets stick to "simple" websites. Example: Using Next.js again, out of the box it does instant navigation by preloading new content on hover, and not doing full refreshes when they aren't needed. Great for the user, less bandwidth used, much faster sites. That's just one example.
I don't understand what you mean here. What content is being preloaded, what is being hovered on, why do you need only partial page loads? Is this for a doomscrolling UI where units of content are presented one or a few at a time, on an infinite scroll?
When I do navigation I just build a <ul> and put <li>s in it, programmatically if need be. Click to go where you want. Takes a full page load, but that's just how the Web works because you're going to another page. Links take you to other pages.
Is this for like an image gallery?
But, I'm not trying to convince you. If you are happy with Pelican and it works for you, great.
All I'm pointing out is that we use these things because they do actually solve problems, often make things faster not slower, and allow me to make better websites and apps for my users. From simple websites, to complex applications.
There is a project I have in mind to build for a portfolio. An atlas of sorts. Is that something Next.js could make easier?
Idk if you know js/ts and React, so there might be some learning involved. (You could also check other fe frameworks if React is not your jam, some folks swear by Vue or Svelte.)
About knowing what’s going, I get that. For me I’ve wasted so much time setting up projects with webpack and all the the other stuff that I have a pretty good idea, but also I’m just thankful that I can just focus on my project haha.
You make it better by separating concerns or finding better ways to do the same thing.
By this point, QUIC and HTTP should fork instead of QUIC insisting on taking over HTTP.
We can make this space better by pushing out complex "web" applications to their own protocol they can fuck up on their own instead of pushing the system requirements of a browser up every year.
Wow, have we just come full circle after 25 years?
>class="bg-green"
But that trend to put everything back into HTML were possible is also wrong...
Yeah this may work for static websites with some forms but I don't see Discord being build like that or any other bigger app.
Its like people want back the HTML version of Gmail. Its a nice experience when a big part of your screen flashes /s
What about i18n? or a10y? The examples of the form don't support any of that.
Have fun writing the right input every time without a well abstracted text input that does the hard and annoying stuff for you.
We switched to components for a reason but it seams like people forgot.
And yes not every blog or form needs to be writen in nuxt or some other big framework.
(of course the html version is not as good as a non webmail would be. Such is life I guess.)
We can go back and replace Javascript with whatever we want, or expand the <script> element to be able to handle more than one language type.
Not really sympathetic of big web apps having to adjust to such an environment. I already don't consider them truly part of the web. They're something you can make with the Web but don't actually represent the values or accessibility that the basic Web already provides.
I only use JS when absolutely required.