Why? Why does it need to be good for big projects in order to be good practice?
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.
Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects.
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.
Do you have any data to support that 95% claim? As big as FAANG and other huge development teams are, it seems to me it's still only the tip of the pyramid, with the overwhelming majority of people in the industry working full time on small or midsized projects. It'd be interesting to see some concrete info on it.
The point where frameworks like Angular and React pay off and what I think of as complex projects are those where there is a some nontrivial feature. This coukd be a project with 1 developer working on it for 6 months.
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.
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
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.
the more it benefits the development team to write that code in their language of choice on the backend
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 abouttradeoffs. 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.
Compare that to 100-200ms of latency between a faraway server
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.
How are you going to do the updates without FE logic? Refresh the page constantly?
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.
How are you going to do the updates without FE logic? Refresh the page constantly? The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.
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.
Why?
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.
I suspect even at Google a lot more than 5% of effort goes into small to midsized projects. Bazel, ninja, protobuf, grpc, the API documentation website for Gmail, VP9, the Google transcode api, takeout, various corp network tools & services and so on.
The big projects are of course important. But even chrome needs a simple little website with a download link.
That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.
I always see this as a communication/management failure.
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.
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.
Yeah, I think so.
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.
The "big" projects can do what the hell they want. They can afford to throw a ton of money at a problem.
The small projects are where the people I care about are struggling.
Are people really struggling at that level, though? It has never been easier to write a complex page with minimal Javascript - there are more and more HTML elements that do what you expect (expandos and modals as some recent examples), Javascript is cleaner and more consistent across browsers (you really don't need jQuery anymore), and CSS is more powerful but also so much simpler (flex+grid solve so many problems).
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.
Find a professional front-end developer who is willing to use simple HTML, JS & CSS and I'd agree with you.
It's almost impossible. The first reaction is always `npm init`
Find a professional front-end developer who is willing to use simple HTML, JS & CSS and I'd agree with you.
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?
or you could use a Hugo binary (I'd love to see anyone call its templating language simple)
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.
Most professional frontend developers are working on projects that require something more complicated than just the basics, because, well, that's where the complexity lies, and so that's where the work is.
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.
Sounds like we're agreeing with each other and disagreeing with the big SPA framework guy?
I mean, I am a big SPA framework guy. That's pretty much the main thing I use, day-in, day-out, because most of the projects I'm working on are complex enough that simply hand-coding the entire UI will not work.
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.
Big project =/= Big company
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.
nb I'm not agreeing with your original hypothesis.
However I'm taking about even lower down the food chain than this.
Smallest projects just throw up a bootstrap template and call it a day
something like this:https://www.hotelpalacebarcelona.com/
they don't care it's not "html first"
This. Even for basic websites you benefit from some form of templating/components for example to get the nav & footer on each page.
You don't need a frontend framework for that. Fuck people who do. They're the reason most websites are slow as molasses on my three year old phone, despite them being very basic sites. Just stuffed to the brim with unnecessary bullshit.
While I agree that there is probably an overuse of frontend rendering when templating in the backend would be fine, I suspect most of the problems you see have nothing to do with that. In my experience, the number one issue with slow sites is an overuse of trackers and advertising that drags everything down.
Precisely. Using libraries / frameworks like React, Vue, Svelte, etc. adds nearly no overhead to the core functionality of whatever it is you're creating, _especially Svelte,_ since it compiles down to the bare minimum necessary to power any dynamic functionality (it doesn't ship with a complete runtime), and supports static templates and markdown out of the box.
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.
If you statically export you won't even notice, and when navigating it will actually be a lot faster when only the content is replaced..
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.
Even basic websites? It is developer vs user then.
I think otherwise. I.e.: blog shouldn't be web app just because it's content management is.
Not at all. There are a lot of frameworks that support static exports and/or pre-rendering. Often those produce incredibly fast results, in many cases faster than hand rolled solutions.
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.
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.
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.
I would say that explaining where guidelines are applicable is on author side.
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 my view, the web is 95% small to medium projects.
In what terms? Sites in existence? I suppose. But sites by usage? Virtually all huge.
If your project is small, doesn't matter what you use, it won't be complex anyway.
This.
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".
This is not only about big projects.
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.
In my view, the web is 95% small to medium projects.
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.
Anyway, a well organised big project is a collection of related small projects :)
And what's good for one small project is likely to be good for many small projects.
I'd be more than happy to see small or medium projects and how these tips improved them. Any real world examples would be great.
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.
Agree.
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.
Perhaps web publishing shouldn't be presupposed to be 'software development'?
But very often it is software development. And there isn’t always some bright line between them.
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.
It's worth mentioning that the friction to deploy a web app is nearly zero these days, depending on how complex it is.
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.
My preference is local first desktop applications. Sometimes it’s because I prefer files, sometimes it’s because native apps are more fluid and more egonomic.
What about for getting quotes on insurance? Or booking a restaurant? Or a flight or hotel? Submitting your taxes? Getting printable directions to a trailhead? Proving feedback on someone’s Figma document? Previewing a 3D model before getting it printed…
Is it your preference to install a new local first desktop application any time you wish to do any of these things?
That depends where the data and the logic all. If they only store the data, but I’m doing all the computation, it may as well be a local app (figma, the 3d viewer..) or at least have an API so I can build my own interface.
I’m not against Web Apps, but many take my browser as free real estate.
Shipping a macOS app doesn't require view of any kind, beyond notarization, which is just an automated malware scan and takes only a few seconds.
Hopefully WASM will fill that area, and browsers can go back to being browsers.
Not as long as the only way that wasm interfaces to the DOM is through the JavaScript layer.
Then use Wordpress. Or Substack. Or even Wix.
"But we need this and that custom dynamic logic..." well now we're in the realm of software development.
The line is very blurry, and the moment you'd like dynamic, interactive content embedded within that static content is when it's time to reach for a view library like React.
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 supportanyfunctionality, interaction, animation, content, routing, and other common web problems, with great ease.
All of the technologies you used previously were considered "finally fully fledged" until they weren't!
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.
Using PHP and other tools/frameworks that tightly coupled the frontend to the backend codebase made life miserable. While I was excited to get into web development back when these technologies were popular, they were anything but pleasant to use.
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 really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives."
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.
No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions. Frameworks abstract complexity, which in practical terms decreases the complexity I personally have to deal with, and shifts the complexity to the minds of a team of open-source developers who support the framework or library in parallel. Abstraction is exactly how we push the industry forward, not by building less, more basic, and shittier applications in a some faux-noble quest to use inline event handlers.
"No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions."
Then, enjoy maintaining React apps once React inevitably bites the dust and ends up in the JS framework graveyard.
The chances of this happening before your project is obsolete are pretty slim.
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 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 notthatcrazy of an idea.
React's first flavor (class-based components) are fully backwards compatible with today's React versions. It doesn't seem odd to me that a popular library identifies its pain points and improves its APIs & patterns over time. That's the beauty of open source software with large communities guiding their growth.
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.
This was a natural evolution from NextJS
It’s just going back full cycle, with a few extra steps. And the only clear purpose is SEO.
Another good example is jQuery, the last release was 2 months ago, and there is plenty of activity on GH.
I love maintaining and cleaning up code (I will insist on cleaning up according to my taste even if it already works fine in production, just like when I carve the turkey I eat some crispy and fatty pieces hot from the oven) It takes a great weight off my short term memory and ADD that I know that the code already worked, so if it stops working, I did it, recently.
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.
Better than maintaining vanilla JS applications that reinvented React for no d*mn reason. At least there's a massive pool of engineers who could jump into an old project and work on it right away, rather than wading through some clever engineer's buggy attempt at a view state management system.
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.
When there are so many projects that run on React, and so many companies rely on React, it's inevitable that it will be supported for a long time to come, even if it would go out of fashion.
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.
In some sense I agree, I am very mindful of the dependencies I add and I am not afraid to write something custom if that better fits the situation.
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.
I tried to push for an "HTML first" style frontend at my job, but we hired some run-of-the-mill frontend devs and they basically didn't get it and just wanted everything to be divs with VueJS controllingallof the logic and content.
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'sveryhard 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.
One semi-objective thing we lost was accessibility.
TBH that's not a framework vs HTML issue, that's just sloppy or inexperienced devs
I argue that it is a framework issue.
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.
React simply diffs the DOM and updates it in an efficient way. If you are putting weird divs instead of anchors and buttons (or instead of special components provided by a React-based framework), that's entirely on you.
if you're using react and then hand roll custom components and don't do accessibility, then it's just as bad as choosing a component framework which doesn't do accessibility. I am not talking about react (or any framework directly) specifically.
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.
I think the point they're making is that you'd have the same problems with developers working HTML-first. Accessibility does not simply come for free in either situation, you need to make sure it's present.
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.
developers who didn't understand the web platform well enough to design proper accessible controls.
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.
But you're using the same component framework regardless of whether you use React or not: it's the same underlying elements that you decide between, and the same process of configuring then correctly to be accessible.
What could the frameworks do to make it more natural for inexperienced developers to do the right thing?
it's very hard to find high profile examples of sites that are "HTML first"
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?
This article had as a “good” example a div with an onclick, I think he fixed it, but it shows a lot..
Frameworks also have linters that will help a lot, it’s on you to use them
For a frontend developer who is younger than jQuery, starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps, and remember how much development sucked before HMR.
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.
Your suspicion is incorrect. Currently running 10 or so codebases with 8 devs using this approach. Thanks for catching the typo
Do you find that your team often has to reinvent the wheel in terms of what libraries like React/Vue/Svelte have to offer? Doesn't that increase time and scope tremendously?
I actually find that I often have to reinvent a lot of the browser's wheel when using React and friends, so it's often a wash.
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.
Vue.js has led the way on HTML first in a lot of ways. You can pull it in with no build step, you can add dynamic content to pages without making it a SPA, and it mostly works through overloading HTML attributes for basic use cases.
Thats great. Show us!! What projects, is it 8 devs per project or total, what was the impact, any downsides?
Nothing is more convincing than real world success stories.
Coming soon
and this is why that example doesn't work - you find out onclick doesn't work where you thought it would work
whereas you can addEventListener anywhere you want
starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps
Honestly, and sarcasm aside, I think this is anincredibly importantthing 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 atonof 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 wereslowing me downinstead 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.
Good old times, I used to have a file watcher that would refresh the page on change using a browser extension, not anywhere near the convenience of HMR though haha.
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.
Too many people today are being pointed toward React to do very simple things, like a single-page site that is nothing more than a little text, some images, and a few links out to various other places. These sites could easily be HTML/CSS. There is a lot of complexity for the sake of complexity on the web right now.
One of the worst feelings is building a site without a view library like React, getting 80% there, and then realizing you absolutely need dynamic functionality and/or state management because the project's scope changed or started calling for it, only to realize you now need to refactor much (or all) of the site to make it easier to maintain across the board.
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.
For personal projects I usually use Astro[1] solely because 90% of the stuff I am making doesn't require anything more than basic HTML/CSS and maybe a couple static components, but I also have the flexibility to add SSR rendering or even more dynamic components like Svelte without making an entirely new project.
Astro is an excellent choice! I've never used it, but always wanted an excuse to. I think it blends the best of both worlds, and the fact that you mix various view libraries is powerful!
Libraries like Vue allow you to easily add some interactivity to a site without converting it entirely. Why not do that?
Cant you just use vanilla JavaScript at that point?
I have a suspicion the reason most people reach for a framework is primarily about two different things: modern tooling (modules/bundling, typescript, etc) and templating. They don't really "need" a virtual dom diffing rendering pipeline, but the fact that you get all these other things out of the box with little setup is what makes it the go-to solution.
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).
The worldwide jobs program that is modern-day Javascript would have you believe that elaborate front-ends are necessary to give end users the experiences they expect, which is an utter pile of lies. What users want is something simple that works.
37 Signals has adopted some of these ideas. Would their apps qualify as "big" for you?
To be fair, 37 Signals (Basecamp) which is behind ruby on rails, changes their front end philosophy with every new major version of rails
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
People buy into ideas and once they've paid the price, they dislike when that investment is challenged with new information. The resistance that I see in these thread to the idea that going back to HTML might be enough, to me looks very much like that.
Basecamp (formerly 37signals) has a track record of challenging the status quo, whether in business or engineering practices and toactuallybe 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?
I think this is a rational strategy. They aren't changing concepts just randomly for that alone. As we learn problems with the last approach we try something new to address it. If you're starting a new app green field this is an ideal time to try to shed some baggage.
I wouldn’t say they’ve exactly changed their philosophy.
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 while since I used it but I did a limited trial of Hey and it was genuinely miserable to use. Not only did everything take a few ms extra, the entire interface was so incredibly janky and had no accessibility concerns at all. They were shipping their website to their mobile apps and it was horrid. I would not put Hey as a shining example anywhere for this philosophy
It's been a long time since I used Basecamp but that was decent enough
This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference.
Not everything has be a Large Enterprise Application.
Perhaps, but can you name evenonesuccessful, big, bloated institutional project that operates primarily on the principles of HTML First?
Even if this isn’t always practical for larger projects today, I would argue that this should “ultimately” be the goal—-at some point the “standard” browser runtime should be expressive enough to not require lots of tooling to make most apps.
I'm not sure that's always the case — we don't expect assembly to be a high-level language after all! The more specific and batteries-included the browser becomes, the harder it is to go off the beaten track. My standard example here is date pickers — theoretically it's just a simple component, and yet there is no one-size-fits-all option. What works for booking an appointment won't work as well for putting in a date of birth. What works for a date of birth won't work if you're trying to book a set of nights in a hotel. You might want to include prices for individual days directly in the date picker. You might want to show which days are valid and which aren't. You might want to show several months, you might want to show just a week.
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.
Most anything built with php or traditional SSR pages follows these concepts to some extent.
Aem edge delivery service, Hey.com
We have forgotten the old lessons. Backend first was a defense mechanism against people who believe their eyes and not the experts.
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.
The entire WWW is the example
Counterpoint: The article is titled "HTMLFirst" not "HTMLOnly"
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.
I get the idea - using the build-in capabilities of html is nice, clean, and simple. But that wasn't viable ten years ago, and it isn't today - and I don't particularly feel that htmx etc. is a better solution than something heavier like react.
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.
Quick thought regarding date pickers, specifically:
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.)
The default date picker is laughable. For example there is no way to control the format in which the date is displayed.
Unless I'm mistaken, it's shown in a format localised to the user, so... i'd much rather you keep your hands off that, and I'll enjoy my DD.MM.YYYY
ISO-style timestamps are the only only one that makes any sense.
YYYY-MM-DD or GTFO.
no need to fight over it, compromise is both elegant and simple:
YMYY-YD-DMNon-jokingly, Kazakhstan has YYYY-DD-MM
I find I'm in the opposite position - I would rather the date picker is not consistent, because different date pickers have different purposes. The date picker I want to use to put in my date of birth is different to the one I want to use to add an appointment to my calendar, and that's different to the one I want to use to browse prices for different days, and that's different to the one I want to use to be able to select a range of dates, and even that's often different to the one I want to use to select the two dates of a return journey.
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.
What would be the specific difference between all of those?
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 actuallydouse a date picker, IMO.
* For DOB, what you typically need looks more like three text boxes. That said, the text boxes need to be able to work together in terms of validation - the 31st of February 2015 is not a valid date! This is why it's better to think of this as a single form control with multiple input fields. Alternatively, I want something where I can pick the year first, but this typically leads to lots of scrolling.
* 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.
Thank you for this perspective. I despise when a website makes me pick by birthday in a typical date picker.
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.
At that point, you're creating and writing a different flavor of date picker -- and in static HTML land, there is no clean way to update page content dynamically based on user input, without some kind of JavaScript library interacting with those elements (talking to the UI) and coordinating input data, displaying new derived data/info based on those selections with snappy, accurate feedback.
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?
Yes but companies don’t think that way. Companies have a style that they want to apply to their product regardless of which browser renders it.
Well fuck them.
Thanks.
And that's precisely the problem.
This applies beyond date pickers too. To me, usability trumps consistency when your users access the website across a variety of platforms: mobile vs. desktop, touch vs. mouse,etc.
Usability depends on the knowledge of your users how to correctly use the widget though - and that knowledge is greatly helped by consistency.
etc.
Screen readers and voice input:https://a11ysupport.io/tech/html/input(type-date)_element
The optimal date picker depends heavily on the platform too. Don't want your crusty custom date picker over my platform specific date picker that I know well.
The default datepickers in browsers are not feature-rich at all though. They're fine for extremely basic "pick a date" type of usecases, but as soon as you want to do anything slightly complex like picking a range, a date & specific time in one or having it be interactive in some other way like Google Flights showing you a range of prices alongside the date etc., youhaveto create your own datepicker component (or use an already built one).
"shift/control-clicking to get multiple things is a flat no-go from a UX perspective" - Do you mean that this is NOT how you should do multiselects? If that is what you mean, then how _do_ you do them? If I have a list of items and I want to select 10 or 15 of them in a row, I currently don't know of a better UI to do that with than shift+click.
Yeah, shift/control-click is a longstanding workflow for multiselect and macOS, Linux and windows all support it with various platform-specific subtleties. The worst part of the web is losing all these sorts of features because some web designer thinks they’re a “bad UX”
Present a form with a 25 item native multiselect to 10 of your non-prgrammer family members. Ask them to perform two tasks:
- Select 5 non-adjacent items
- Select 5 adjacent items.
Report back with success rates.
The nice thing about native behaviors is you only have to teach them once. Custom behaviors per application make it harder for people to develop a model of how their computer works because you have to learn a new interaction model per application. I’m pretty anti the notion that UX is intuitive in any sense: all human-computer interaction is learned at some point and we should focus more on educating people how to do tasks like this than pursuing some lowest-common denominator concept of “intuitiveness” or “discoverability”.
Anyways, my favorite multiselect paradigm is the old windows one with two list boxes side by side and buttons in between.
That two-window approach was particular useful where you needed to be able to rearrange the order of the items.
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.
Why not do both? Gmail's a great example of this. Hold shift while clicking two checkboxes in a range of emails, and watch as the entire range is selected for you to manage. :)
Most normal users (aka if you read Hacker News, you're not one of those) don't and won't know about shift and control clicking. A more UX-friendly alternative is to have checkboxes; you can still have shift/control-clicking on top of that (for selecting many things quickly), but it shouldn't be the only option.
This is pretty much correct, though I feel there's some finer points depending on the number of options (5? 10? 50?) and the expected number of values chosen (2? 4? 10?).
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 (seehttps://react-select.com/homefor 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.
HTML has had checkboxes since at least version 2 (1995), so just use those if you want to do multi-select using checkboxes. I don't think you can do shift-clicking to select ranges though (without resorting to js) but control-click is of course redundant as that is just the default behavior for a list of checkboxes.
Most normal users (aka if you read Hacker News, you're not one of those) don't and won't know about shift and control clicking.
My boomer parents do. Most users I've seen in the wild do.
Drag and drop? At least that’s only using a pointer device without modifier key…
Is the look/feel/controls consistent across browsers? (No.)
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.
<Aside> from the rest of the discussion, `input` element is infamously shitty for having vastly different ways of interacting with it, whereas most other HTML elements have one signature.
“Locality of behaviour” is such a poorly defined rule. It’s just an invented name for going against separation of concerns. Calling CSS “spooky action at a distance” is a massive stretch too. Good principles here but the arguments are quite weak and could be much simpler.
Tailwind is a build step with just as much 'spooky action at a distance'. If it wasn't, we'd just use inline CSS.
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.
Inline CSS is a total anti-pattern apart from the absolute most basic pages IMO.
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.
Just use a single CSS file with sensibly named classes
IMO you no longer need an intelligent naming philosophy for CSS classes due to how far CSS has come.
Could you expand on this? Class names in CSS are just as important, if not moreso, than naming variables in typical programming.
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 somethinglookswith 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.
The exception is when using a framework which isolates CSS at the component level, in which case your class names don’t matter anywhere near as much because you’ll only ever see them alongside the corresponding HTML.
Can't say I'm familiar with this type of webdev. How is the CSS isolated at a 'component' level? Is that not what selectors already do? I'm having trouble picturing how this is built or how it works.
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’s quite a common pattern in modern frontend frameworks. Each component includes just the CSS required for that component (plus any global styles). At built time, the bundler will generate unique class names for each of the HTML elements in the component and output an optimized CSS bundle matching those unique class names.
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.
Well the point I was trying to make was tonotdo what the article says and name your class e.g. "green", but instead to name it something more sensible like "approved" or "updated" or something about thesemanticnature of the style, rather than what the style actually is.
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)
The core argument for tailwind is that it won't just be "make the approved text white on blue instead of white on green". Maybe you'll get "make the approved text a bubble with a checkmark on the left and make the title two lines where the second line is ..."
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.
Exactly. Classes, even for the simplest styling tasks, have been replaced by components.
I think there are some other benefits of tailwind. Say you have a set of css classes for different components.
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
Generally this makes sense to me, and if you are just dropping markup onto the page, and don't need to worry about repeating yourself when using that component, I think that works well. Definitely better than your alternatives.
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.
I’m not entirely sure what you mean by component-level tokens, but it sounds like tailwind’s themes do what you’re saying.
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.
A component level token would be if your `myCard` component populated all of it's styles with component-specific css-variables, e.g. "myCard-bg", "myCard-padding". It's basically defining the styling api for your component. If you have a new variant that needs to style another property, then you should probably extend your component's style api accordingly (by defining a new component token and providing the default). As I say, I haven't yet used this approach, but it does make some sense to me. It's also useful if you're designing components across tech, targeting other style languages besides CSS.
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.
The Salesforce Lightning Design System makes extensive use of this technique; they call them "styling hooks".https://www.lightningdesignsystem.com/platforms/lightning/st...
Is Lightning primarily web components? That would make sense, since css vars penetrate the shadow dom, so with this approach there's no need to mess with loading your css into the component's shadow dom.
It’s hard for me not to see Tailwind as using the class attribute to reproduce the style attribute - burying your html tags under a pile of css classes doesn’t feel that much different than defining those styles inline.
The styles are already coupled to the component anyway, so what's your problem with putting them in the markup? The alternative is making up arbitrary class names and putting the styles in a separate file: now you've added an extra layer of mapping that the developer after you has to grok.
People don’t seem to mind the 7 layers of mapping between their markup and HTML, why are styles different? I find that much more of a problem when it comes to understanding what’s happening for the average dev.
Only people who haven't used tailwind say this. A lot of tailwind classes aren't singular styles but a composite of style attributes and mostly define behaviours rather than just expose a single CSS attribute. And a lot of that behaviour is applying styles on hover, on media queries, on grouped elements and other extremely common user actions, none of which are possible with inline styles
“Locality of behaviour” is such a poorly defined rule.
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.
Yep. I've said this often but whatever:
JS, CSS, and HTML aren't concerns, they are technologies that have cross-cutting concerns.
Problems are multidimensional.
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.
The primary stated goal is “substantially widen the pool of people who can work on web software codebases.” That’s very different from typical advice for programmers.
Customization isn’t required as long as defaults work. As such the efficiency gains from CSS etc take a back seat to simplicity.
(coming from a C# shop with too many interfaces) I think it's a natural counter-reaction to overly abstracted systems.
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...
In theory these principles are really good concepts from an education standpoint. Where I teach, we teach students vanilla javascript and HTML as much as possible before moving on to frameworks that make things easier.
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.
Have you used HTMX?
I am yet to find a reason for using frameworks like React instead of HTMX.
What's the reason to use a framework like HTMX instead of React?
Cost.
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.
What kind of web dev can't handle React? Meanwhile, htmx uses clunky, non-standard attributes that rely on logic and templates that are split up in a million different places. Plus it requires a context switch to do anything client side.
Don't underestimate the learning commitment it takes to learn react. Learning the basics of react and its component architecture is one thing, learning all the tricks and gotchas related to hooks, accidental re-renders, accidental no-renders, etc takes time.
Throw in the usual pile of libraries used with any larger react app and it can easily take months to really get moving.
I know so-called "senior frontend engineers" whose speciality is React, and who can't handle React. So all others...
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.
React is so simple to use that you definitely don't need to hire a "react dev" to "handle all the complexity". Like >95% of the effort is just understanding the basics of standard front end technologies (HTML, JS, and CSS), something that "back-end" devs (especially ones that label themselves as such) are by no means guaranteed to understand, which is an issue, since you'll have to understand these things even when working with htmx.
My feeling as an old-time "web developer" who has been bullied into becoming a "back-end dev" is: thank you, I think I know quite well the basics of standard front-end technologies, but suddenly some people started yelling at me "you're a grandpa, now you can't send HTML from the server anymore, it's lame, you have to send to the browser a JS app that will manipulate the DOM live instead". This new (in 2015) approach has flooded our brains with a deluge of libs, frameworks, tools, concepts, problems, etc. which are a lot more than 5% of the effort of bootstrapping a React app, let alone optimizing it and maintaining it. I know people who's main job is creating React apps and who are overwhelmed with the complexity of the stack. If you don't hire someone dedicated, the rest of your product (domain rules, database optimization, infrastructure, devops, etc.) will suffer.
It reduces development complexity.
- 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.
But all it is is fancier fetch()s. It can't remotely approach the functionality of React, so it just shifts any complexity to different places.
Yes, it shifts complexity to the backend. Which will already have it anyway (because it has to), has better tools to manage it, you can use literally anything you want instead of being forced to use javascript, has (relatively) instant access to the authoritative source of truth, and isn't resource constrained (at least not the same way that the client is).
so "just shifts it somewhere else" might be underselling it a little
And waiting much longer than an instant for a million server requests every time a template changes on a page is not a good use of those resources.
I have used HTMX with Flask and Jinja. It makes the process much simpler to do the frontend development as a backend developer. But I can see its limitations. It's not suitable for anything bigger than a hobby project. Also, it doesn't help with keeping the frontend and the api totally separate. You have to return the html object from API which has its own set of problems.
> It's not suitable for anything bigger than a hobby project.
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.
The middle 2 links are by solo developers - I wouldn't call those significant production systems. Generally tools like React are helpful for managing complexity across large systems where nobody understands the whole app and layers of of features, bug fixes and optimizations have been baked in over the years and nobody understands the whole app anymore
The reason "nobody understands the app anymore" is due to the complexity of React and not the application.
HTMX tries to reduce the complexity.
No, nobody understands the app because it is simply impossible to hold in your head 5-10 years worth of development by 100+ people across a complex product with complicated use cases and customer need (unless you were there the whole time and you are a very hard worker)
By the time you create the correct abstractions, customer needs and the market will have changed and thus your abstractions are now incorrect
It's both.
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
contexte is a (small & now full stack, after using react) team:
To be accurate in the past year we went from 3 to 7 in that team, and I think everyone has been using htmx at least once, and 4 of us are using it on a regular basis.
I would like to know more about these limitations. I haven't used HTMX on more than a hobby project myself.
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?
Of course that is possible, but wouldn't that make the project more complex again?
React makes it fairly easy to implement your app in a way that makes it easily portable to different platforms. With things like HTMX, you'll more or less have to rewrite everything if you ever end up in a situation where you'd like to release the application on mobile, or as a desktop app, especially if you want it to work when you can't rely on the user having a stable internet connection.
When it comes to teaching web dev fundamentals, the sequence HTML -> CSS -> JS makes the most sense to me. They're 3 legs of a stool. CSS is an underappreciated but absolutely essential facet of accessible, standards-based web development.https://every-layout.devandhttps://www.joshwcomeau.com/tutorials/css/are great resources.
This one confuses 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 suspect this is a 'List of tips' written explicitly to promote hyperscript.
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>
note that the <input> tag does not use and does not need a closing slash and never has in any HTML specification.
https://html.spec.whatwg.org/dev/embedded-content.html#the-i...
Yep. It’s one of a handful ofvoid elementsalong with <img> and <br>.
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.
I'm adding context to this because you're only telling part of the story:
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 notuniversallybad or unsupported.
You can view HTML as a weird, quirky version of XHTML if you want. But XHTML lost the war. Browsers are HTML5 engines, not XHTML engines.
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 /> isnotequivalent to <script></script>.
The problem I have with self-closing tags is that I've metso manyweb developers throughout my career who think that browsers understand self closing tags. I used to be one of them! And that willalmostalways, 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.
I can't disagree with making sure you're using them when they matter and avoiding them when they don't.
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 no real 'war'
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 isnotan 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.
I'm going to let this link to a simple XHTML document speak for itself. I've configured it to work on lighttpd via the `mime-types.conf` file, and even have a commented-out meta tag you can use to fake it in cases where you can't manipulate a server.
https://zlg.space/misc/example.xhtml
Let me know how your browser sees it.
You need to serve it with the right mime time (application/xhtml+xml) or in case of local files use .xhtml extension. Then it's processed as XHTML and rendered as expected.
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
XHTML may not be mainstream with people authoring web pages, but it is a thing within publishing pipelines that generate XHTML from other XML-based sources like JATS or DocBook. It's also a thing at least in ePub 1 and 2 content (I can't recall if they relaxed it to HTML for ePub 3 or later).
Offtopic but not:https://daringfireball.net/projects/markdown/syntax#p
Eg, <div><span /></div> will render as you expect because the browser will automatically close the span when you close the div. (!)
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.
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's explicitly in the HTML5 spec as allowed, but not required.
They are allowed due to the big push for XHTML in the past and making them invalid might cause problems for a ton of sites built that way.
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...
Which makes the example even more egregious. There are certainly better ones that:
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).
yeah, kinda.
source: I'm the creator of hyperscript.
Perfect. This place is overdue for an exhaustive debate about HATEOAS/REST/etc, and you have an incomparable talent for starting such a debate.
not to brag, but that is kinda my superpower...
I'm not saying hyperscript isn't serious (I have no opinion on it at all actually). I'm saying the claim "avoid DSLs" followed by an example using a DSL is a sign of unseriousness on the part of the author ofHTML First.
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.
Yeah I stopped reading as soon as I saw this one.
I would agree - the example of an an attribute of `_` and then some obscure DSL statement as a value looks super weird and confusing.
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.
Alpine.js would have been a better recommendation according to the authors advice as it is straight forward JS plus HTML attributes.
I think hyperscript has some people trying to hype it up bc it’s related to HTMX, but imo is more of a fun novelty.
Maybe the author swapped the encouraged and discouraged.
React was designed to solve all these problems. Now these problems are used to solve react.
Programming, like life, is a flat circle.
No, it was designed to address problems that were not solvable by the then-current state of simple technologies.
All the things React does is doable with plain javascript. There aren't any extra features added.
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.
Agree to disagree. Building a React frontend is extremely complicated compared to server rendering HTML with progressive enhancement. It introduces state management to the frontend for even the most basic tasks, which is not something most web applications benefit from. When I built my CI/CD platform (Beaker Studio), the React portion probably added a solid 50% extra time to the project and really did nothing for it functionally.
No you agree. You're just not understanding.
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?
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.
Yeah but react was designed to address a problem. I don't know if you recall but people were complaining a lot back then. There were tons of frameworks attempting to solve the issue. Only react came out in top.
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 don't have fond memories of early React; It was extremely verbose not having hooks until relatively recently, build tools were necessary but a horrible mess, and it was falsely advertised as being faster than vanilla JS. Hype around Facebook carried React. It has improved massively since then, but so has vanilla JS. I don't see a transition away from React as a step back at all. React made rendering new elements client-side and attaching events cleaner, but that was never a hard problem per se and we have web components now.
I never said a transition back from react is not an improvement. Again you're not getting it.
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.
I dunno man, I don't consider browser APIs to be a failure. In fact, it's probably the most popular UI toolkit in existence by a wide margin. It being a collection of evolving standards doesn't count against it in my book.
Many bad things are popular. Java, C++, JavaScript. Popularity doesn't preclude something from being shit.
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.
There's a difference between being popular, and being the most popular thing in a category ever and keeping that title for decades with no serious challengers. The browser as we know it with the DOM is the latter. Maybe that will change with new APIs that hook into the canvas, but we're still a ways off from that and I suspect the DOM will remain in the picture even then.
C++ also has had that category for decades. Longer than browsers. Rust is challenging that hold right now but it's far from winning.
You're right the dom will remain in the picture for a long time. Doesn't change the fact that it's horribly designed.
The dom was a failure, react was a failure. What do you think going back to the DOM will do?
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).
No. The entire front end ecosystem is simply cruft added onto something that was fundamentally designed for something else. The "improvements" are attempts at fixing a flawed design while maintaining the old core design Similar to the cruft on top of C++.
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 think this is because HTML, CSS, vanilla JS, browser DOM implementations, and networks have all gotten better. Whereas the complexity/churn around JS tooling (and to a lesser extent React) has grown. Additionally, the overuse and abuse of React, to the point people are making largely static sites with React, which is largely a total waste of time. This has caused people to take a second look at their options, which should be viewed as totally natural.
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.
How was React designed to "avoid the build step" or "make View Source useful"?
React was designed as an abstraction layer on top of the source. Why?
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.
There won't be a repeat. WASM is a clearly better compilation target than JS, and browsers have greatly improved the "vanilla" DX.
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.
Building a language and a framework on top of wasm is just another abstraction.
Ironically you mention the jvm which further proves the existence of the flat circle.
We've done it before... We will do it again.
Yes, I remember when Microsoft FrontPage was the go to wysiwyg editor for web development along with Dreamweaver most styles were added inline.
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.
There's no theory behind program design and organization. We have no formal definition about whether one design is better than the other.
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.
How poignant - another post on the front page -https://news.ycombinator.com/item?id=38236607
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
Really good quote. Pretty much sums up computing. Here's the thing, everyone doesn't realize it's just a bunch of fads. People think of it as some sort of science where we're just continuously improving and getting better.
While I agree with most of the arguments here, this article feels a little contradictory - it recommends Tailwind but also tells us to 'stay clear of build steps'. Shipping massive CSS/JS resources goes against the whole inclusivity principle - many people don't have super fast internet connections or powerful enough computers..
I don't use Tailwind anymore at the moment, but in my experience, it does not lead to shipping massive CSS/JS resources. In fact I don't know about any client-side JS at all that is emitted by Tailwind (my last experience was 2.x, not sure if anything has changed).
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.
I think GP is talking about how, without the tailwind build step, you ship all of tailwind, which is unquestionably a lot of CSS that you aren't using.
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.
This was only the case in Tailwind 1 and heavily discouraged by the documentation, except for development.
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.
Maybe if you use a CDN, so hopefully the user might have a local cache of it from somewhere else, that can be avoided?
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.
I think what the OP meant is: Tailwind requires a build step to extract use classes. Otherwise you need to ship all of it.
Tailwind output was usually a lot smaller than hand-written CSS:
Tailwind output ismassivelybigger than the one with semantic CSS. Here's a comparison:
Did your experience involve the (recommended) build step? It uses, at least last I checked, a purgeCSS step to remove unused rules and decrease the css size.
I made an atomic CSS library that doesn't need a build step, if anyone wants one (spoiler, nobody does):https://casscss.github.io/cass/
Imho, bullet points on the border box seems weird to me (https://ibb.co/d0sDsQ2).
Thanks for the note! The left padding and margin situation on the ul is the bane of my existence.
Copy what other more popular frameworks are doing :P
I haven't looked at your css, but maybe changing the box model could help?
The only thing a build step changes about CSS/JS resources of this kind, is a minimization of the libs...which is entirely achievable without building, by simply including the already-minimized version.
I think what the article is about when it says to steer clear of builds, is complex builds, where transpilations and similar changes in formathaveto happen, in order for the page to work.
The only thing a build step changes about CSS/JS resources of this kind, is a minimization of the libs...which is entirely achievable without building, by simply including the already-minimized version.
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 wasn't aware of that, thanks :-)
The OP was making a point that the build step should not be required to run/display a web app.
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.
I read it the same way, yes. Good point with the cleanup: - it’s one thing to need to run build for it to work; - it’s another thing to run build to make it smaller;
Tailwind doesn't exist without a build step (at least since v2) — the whole point of Tailwind is that itisa build tool, an alternative syntax for writing CSS.
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.
You don't ship Tailwind...
Deno Fresh uses Twind, which avoids the build step:https://twind.dev/
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.
Good options for zero build:
* 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.
Tailwind has a standalone CLI which can be used for the build step. I do sort of agree that it's a bit of an odd recommendation in the context of this article, but the build step can be extremely minimalistic, and another nice thing is that the results are still inspectable CSS.
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 want to agree with this based on the title, but why would you do something like this:
<div class="bg-green" onlick="this.classList.add('green')">Click me</div>
I don't think you'd mix in React with this approach.
Isn't it much easier to know you're going to use React (or Svelte or Vue or anything else) and just start there? Starting a build in HTML-first only to bolt on a JS framework after the fact seems like a lot of wasted effort.
The whole point of this essay is to encourage developers to avoid heavy frameworks like React, Vue, etc and use "lightweight" tools, including vanilla JS and native HTML features, instead.
Sure, I'm just talking about that middle ground where you're trying to go with this approach and find that you now need a bunch of JS framework features.
are you trolling? 10 people in this thread have already explained that the point is to avoid using a heavy framework, yet you keep insisting that one is necessary.
I think the GP is referring to when people misunderstand the scope of their project, start without a framework, and the complexity reaches a point where the framework would actually help.
I'm not sure what that looks like, because if it gets complex enough it's a sign I need to refactor, imo.
I once built a project-tailored combobox using Alpine.js - this is about where it breaks down.
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.
Alpine is primarily designed to be reused via server templating. You use a single template per component to do the in-HTML side, using the server template's facilities to handle variations as necessary. Then you can factor out complex common behaviors into Javascript using Alpine.data.
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.
Should have mentioned that I made a generic Blade component from it (it was a Laravel project)
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 :)
It might be easier to staff for. But developing a React frontend takes way more time than just server rendering HTML and layering in JS for the vast majority of use cases.
that's just speculation. I can say also anecdotally from my experience, developing a react frontend takes way less time.
I'm speaking from experience on a pretty wide variety of commercial web projects. Been building websites for twenty years. Frankly, it's not even a close competition. What I've found is that a lot of teams don't even track their time, so it's likely many developers don't realize how large the React penalty is. I would encourage devs to spike on both approaches and do a thorough accounting of their time.
Also with "onlick" you have to lick it to trigger the event.
I see you are also a fan of lickable.js
What are HNs policies around tongue-in-cheek comments?
Tongue-in-cheek is OK after a lick.
I can't tell if this is an actual pseudo-complaint about a joking comment, or an honestly pretty amazing pun on licking/tongue.
But you're already using it for the rest of your site
I'm not
I thought the point of the article was more to avoid react if all you want to do is change background color. Thus more: don't use react in the first place, rather than: here is how to use less react.
Can the people that want this HTML-first world style it to look the ways they want themselves?
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?
Here to bust your assumptions. I skew backend but love CSS, and am one of the better UX engineers I know of. I also dislike javascript a lot, and find that the htmx approach cuts a significant amount of complexity out of your app (e.g. your views can talk directly to your daos.)
I’ve met enough people that aren’t like you that your lived experience, real as it may be, doesn’t really change my opinion much.
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.
What literature exists on UI and UX that isn't condescending or clueless in tone?
Interfaces are as unique as humans are. There's a reason we have emacs, vim,andNotepad.
Refactoring UI fits those constraints. While it's by the creators of tailwind, it doesn't make assumptions about the css you use to achieve your desired UI.
Thanks for giving me something interesting to consider! This looks like an earnest product that could help me at least understand where others are coming from on design, and could probably add flavor to my own UI focus (gamedev).
I don't often have a positive reaction to something like this, will definitely revisit it when I have the spare cash.
Similarly for every React/$oftheday dev who creates a snappy, race condition free, spinner free, app that feels almost as snappy as the web prior to React/$oftheday, there are 40 who create sluggish, unmaintainable tyre fires.
To be fair, most UX "experts" are too busy chasing interfaces that are "inclusive", i.e. built for toddlers.
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.
Interesting example. Why would you say VSCode is a mess? I feel like it's not in line with the current UX Zeitgeist I assume you're referring to (touch-first, wasteful whitespace, manipulative patterns, reduced functionality) at all. It provides multiple layers of access to functionality that allow the user to choose their trade-off between discoverability and speed. The UI is compact with very little padding and shows a lot of information at once. No affordances to touch input are made either.
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.
VS Code is a mess because there are few places I can click in the UI without triggering some weird part of the UI. Almost the entirety of the bottom bar is reactive. The sidebar has too many views to keep straight, it has an extension store or something? Using VS Code feels like handling a tool with no handle. I'm sure it has something useful but I feel overwhelmed and constrained when I use it. I can't depend on any of my prior UI exposure to effectively navigate VS Code without taking my head out of the code. It's simply too much on screen at once and relies on visual iconography which willNOTresult in the same ideas conveyed between different users. VS Code feels like it's meant primarily for the enterprise, on projects that are massive and have extensive SOPs. I tried to adapt some of my development to it, just to try it, and bounced off really hard.
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.
I find the silence that accompanies the negative score above to be rather damning of this community. I was asked why I felt the way I did, and I explained it. If you have a problem or disagree, show it in the comments.
I am very happily listening to UX thoughts from people who specialize in UX.
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.
That applies to backends equally, but you don’t get thinkpieces on how that makes it a great idea for frontend devs to avoid all those silly DTOs and design patterns that complicate the server code.
You do though. Hating onthe cloudis pretty popular as well.
But in the end, because of nature of things, slugish frontend has bigger affect on user's experience then slugish backend.
This strikes me as a cynical take. Having floated between backend and frontend a lot, frontends naturally tend to become very complex; even before the web. And with three different Turning complete stacks (HTML+JS+CSS) the web already feels pretty heavy before adding in another stateful framework and build tooling to support them.
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.
JS frameworks seem inevitable. Any time I've worked with native JS in a reasonable size projects, it becomes necessary to create libraries and common conventions, that starts to look like something approaching a small framework. A framework is just common patterns for solving problems. I think what a lot of developers object to is the stack of build tools required to transpile, bundle and link code together when using these frameworks, in addition to the complexity that comes with dependency management, rather than the use of the framework themselves.
Having worked with it for 20+ years I've just been left convinced that the biggest mistake frontend dev has made in that time is to pretend that CSS is a language that should be 'engineered' instead of a design flavour that should be build up / torn down lightly on demand. It's esoteric corners should have been fixed and simplified so designers could learn and explore design through markup as needed, rather than double-downed on to where we are now.
I’m not able to make a page look nice (or even decent) without a CSS framework. But I think I’m at least OK at understanding how to make the interactions and workflows follow the “Principle of Least Astonishment”.
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).
I’m sorry but what? This is terrible advice. I have never understood the desire to keep the web “inclusive”. Is the web not already inclusive? Can someone not already build a website with simple html/css?
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.
"fully functioning pieces of complex software" - in my experience a majority of software is simply not that complex. And the few places where it is are not on the view layer. To make sure we're not talking past each other, can you give examples of the kinds of software you're talking about? We do quite a lot of react work too, but it's ~20% of the projects we work on, when advanced frontend interactivity is needed.
"Not that complex"
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.
Are you really advocating for using frameworks as a glorified #include directive? Frameworks are necessary when the job you're doing is highly abstract and you're not totally picky about the result. They shine at those things, but they are overkill for a static website. Something like Pelican or Hugo would be better suited for that. Shit, you could roll your own SSG in a weekend.
So pelican and hugo are not frameworks? How is a static site generator any different from statically exporting next.js/nuxt.js or similar?
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..
I can't speak for Hugo but no, Pelican is not a framework. It's a static site generator. I cannot make general purpose, dynamic websites with Pelican. I can fake a few things, I can hook it up to cron to mimic it, but Pelican itself is concerned primarily with your data store, your theme, and generating static files to upload directly to your webspace.
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.
And it's totally fine if it works you, I'm not saying one is better, I'm saying both are valid choices and if you statically export from a framework, it's not that different from what you describe.
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.
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?
Could be, but also just page transitions, think a blog, documentation site, often you keep the navigation and just replace the content. If you are curious, it's quite easy to try. The results are really snappy, it's really nice.
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.
I'm not totally averse to trying things, I just often find myself unable to make much use of bespoke tools. It makes me feel uneasy to not have a strong grasp of what's going on under the hood of tools like that. Even Pelican bugs me with its extensible Generator and Renderer classes that still don't totally make sense to me.
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?
Could be! If it has a bunch of interactivity it will probably make your life a lot 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.
I'm sorry, but the majority of the change has been inflicted by for-profit outfits who EEE'd the W3C to get what they wanted. None of us asked for a Javascript-dominated Web where you download megabytes of code before you see the first page.
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.
This is a very good point. I would also look in different directions for inclusivity.
We now have Framer, Webflow and all the others, you don't have to write any code to make amazing websites.
OP Here. This got more engagement than expected, some of the bits I've picked up in discussion:
"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 toavoidframework lock-in.
"This is a blog spam post written by an author that has no credibility in the space": Brutal
Well, also, you make some claims that could be interesting then provide zero proof or even discussion at all.
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...
"list of assertions with zero discussion as to how they make eng more productive" - this is fair. Initial versions of the post had much more of this but I felt it added noise to the core principles. I will be following up with some more posts and real world examples though. "Like the industry settled on certain things for a reason" - In my experience An industry "settling" on something hasn't been a great indicator of its effectiveness. Industries tend to settle on practices that increase the value of its practitioners and increase barriers to non-practitioners. The legal industry, for example, is still remarkably expensive, laborious and bureaucratic, and while outsiders recognise this, there are few people within the industry who seek to change it. Thanks for the feedback
We use static-tailwind, a version with no build step, in development.
So you do use a build step for production? Or are you shipping a bunch of unused styles?
It looks like the latter, and loaded blocking as well.. I get it, convenient, but that's not really great for the argument.
https://html-first.com/stylesheets/tailwind-full.css68kb of blocking unused css.
In total ~100kb of blocking scripts and styles. Most frameworks would optimize this for you out of the box..
Do you believe someone in the future will actually create a complex web application using pure HTML+CSS+Javascript/Typescript?
Is that even possible at this point?
Thanks.
Personally, I am happy to see someone else thinking about cutting down stuff and simplifying. Similar posts have started popping up more frequently and as a fan of simplicity, reliability and maintainability I am very happy! Don't get discouraged.
Never read the comment section!
I like this. I share a philosophy similar to this: hew close to the grain of the material. It's heartening to see articles like this. I've created many expressions of my ideas on this in code over the years: Brutal.JS, VanillaView, Bang/Good.html and I recently created one that is even simpler and I'm very happy with. It's similar to a unification of these ideas with Custom Elements. You can check it out here:https://github.com/00000o1/-
We use static-tailwind, a version with no build step, in development.
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.
Congrats on the big post!
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 :)
I gave up this year, it's no longer possible to keep fighting these react, vue, angular monsters with their bundlers and transpilers and all the junk that comes with them, like node with npm which always throws at you the message that your brand new, seconds old project has 7 severe and 8 critical vulnerabilities in it, because it must download thousands of files, possibly including a wrapper for boolean values.
The times where I could use the Python backend servers to also serve the frontend seem to be over for me.
Rage! Rage against the machine!
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.
For smallish or personal sites I'm 100% on board. For a large enterprise-y app, which in a previous era would have been a rich client deployable, the benefits of these hulking UI frameworks outweighs the costs.
To the devs perhaps. To the users? Not so much.
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?
Surely that depends on your users.
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.
I'm unconvinced. In a ticket I just took over, we need to update the options in a drop down in a modal. Django and react. The PR I took over has already touched nearly a dozen files, and tests have not yet even been written to count towards that.
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.
Yeah but have you noticed how hard it has gotten to include simple libraries like day.js or three.js? It's still doable, but it's not easy anymore. Then there's some real value to be found in frameworks like Quasar which gets really painful to use via a cdn, which I've been doing for years now. Vue3 complicated things further so why not just move to react once and for all?
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.
Hit the eject button! A lot of the great things about the web are there in Phoenix Liveview. Sexy reactive websites without the need of lunatic React/Node shenanigans.
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.
It's possible! Just try htmx!
It issomuch easier and faster to build web apps using TypeScript, Vite and React (or any other similar stack) rather than vanilla JS. I find this “leveraging the extreme simplicity” effort wholly misguided.
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.
It depends, I think.
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
My rule of thumb is that if you're building something sophisticated enough that you want to reach for more "advanced" js frameworks then you shouldn't be building it as awebapp.
Why?
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.
Is there no appreciation for using the right tool for the job?
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 Webisa 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.
I think you are totally correct- we should we building them as electron apps instead :)
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.
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.
That method was horrible, as someone who struggled with poor knowledge sources until HTMLDog and MDN became a thing.
But theyarea 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 mentionedtalksand 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.
I agree in principle that HTML is the best option for a good user-experience, but it quickly breaks down in terms of developer-experience and maintainability. However, we don't need to compromise on either by using a solution like Qwik[1]. Where the page progressively becomes more interactive with JavaScript, and doing as much work as possible on the server beforehand.
Where possible, default to defining style and behaviour with inline HTML attributes
Wow, have we just come full circle after 25 years?
I literally--literally, not figuratively--facepalmed when I read this.
This comment or that part in the link?
The advice to put inline styles in your HTML.
And it isn't even done in the example.
class="bg-green"
Thankfully he got the `onlick` attribute right.
These tailwinders are everywhere these days.
This is a blog spam post written by an author that has no credibility in the space rather than creating an agency that touts itself as "A software agency that doesn't suck.". How bizarre.
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 like how he concludes "The practices and principles described on this site are still considered niche in the industry as a whole". Like he's the only one out there who knows about the details/summary tags, or who uses static HTML documents instead of React.
Are the practices that the author wrote about common? Judging from comments, frameworks are more common than plain JS, and half of those using frameworks don't fully understand what's possible without one.
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.
The details tag is a mainstay of the "You don't need JS" genre. Every time I see it mentioned in one of these, it's always presented like it's new, unknown, and maybe a bit secretive. "OoOOoOo, bet you would write a component for this right? Well aren't you feeling silly??"
I think it's showed up on every app I've worked on for the past 5 years.
Textbook ad-hominem mixed with a side order of appeal to authority.
Yeah, kinda gross. It takes zero effort to call someone's writings "blogspam". Would love to see comment OP's website so we can compare it to some random "agency".
Probably some "entrepreneur" chud.
The main thesis seems to be that the user should be able to press View Source and understand what's going on. I agree, at least for websites. For webapps, at least anything over 50 lines, you are probably going to want to use a typed language. (Well, you could technically use .js with TypeScript compiler and type annotations in special comments but I did not find that very pleasant.)
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!
I'm sceptical on this: by now there are lots of ways to "peek behind the curtain" in the developer panel: we have the DOM view, network tab, heap view, built-in javascript prettifyer. Sure, "view source" is still important, but I'd question if its importance is still as absolute as the HTMX people make it out to be.
I wanted to show people how easy it is to do cool things with a computer, how low the barrier to entry is.* One HTML file. Your OS's built in text editor and browser. You look at the code and you can see it there in front of you! It isn't obfuscated. It isn't even minified. Everything is right there, all together. You can just save the file and drag it onto your browser. No Git, no zipped project folders. No build system! No server! (No MIME type errors!).
The "frictionlessness" of lowering the "activation energy", is not just nice for beginners... heck, it's nice forme!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.)
I don’t believe the author is advocating for single file systems, but I don’t want to speak for them.
Sorry, I didn't mean to imply this! My original comment had "I even go so far as to..." but it got lost somewhere in editing.
In fact, I find a beauty and elegance in shipping the whole thing as a single HTML file with no dependencies (1 network request!)
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.
Maybe I’ve already drunk the koolaid, but if I end up building a new app from scratch, I would really like to experiment with something similar to what the author describes:
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?
This is what I’ve used for my last couple of projects, includinghttps://www.semiform.ai- not sure I’d call it “non-trivial”.
I’ve really enjoyed this stack. The structure just seems to click in my head better.
I have used this approach for internal tools and it has been great. It makes it much easier for one person to build the whole app, frontend and backend, and makes ongoing maintenance much easier.
I am working onhttps://github.com/claceio/clacewhich takes this no build approach and makes it easy to build portable applications, using Starlark running in go to configure the backend.
I think you might find that relevant. (But in short, the author expressed being verry happy with switching to 'stack' you described)https://youtu.be/3GObi93tjZI
I used this exact approach: Django backend, Django templates and htmx. It has been a delight.
I love this. Could you please consider changing the example from a clickable div – which is an accessibility nightmare – to a button?
Why is a clickable div an accessibility nightmare when the button element has a lot of browser-preset styles that are harder to override? Assuming you put all the relevant state styles into place like :hover and :active and whatnot, what's the problem? Button elements are best used in a form. If you aren't submitting a form, what's the button there for?
button { all: unset; }
This removes all the preset browser css styles. An accessible,styled <button> is much easier to achieve than an accessible, styled <div>
What makes it more accessible?
I suspect the answer is that screenreaders don't look for all clickable elements and are naively focusing only on buttons.
Good catch - fixed.
The main feature that introduces the need of a build step is having a template engine in order to reuse blocks of code, like footer, header, menu, etc..
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?)
Browsers have had built-in templating engines (xslt) for decades.
That's cute, now show me someone who's made something modern and usable with that tech.
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.
I'm not sure what you mean with it being a nightmare. It's my go-to for personal stuff. Most recently I used it to make a template for my photo albums. For personal stuff it works fantastically because it's easy to just use a simple text editor for everything with zero other tools required.
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.
In my case, I needed to put together table headings that were clickable that would sort the dataset. XSLT candothat, but midway through doing the task, I realized that I was working with stuff that belonged in a database, accessible from more places via SQLite. Since I needed a multitude of different ways to sort and filter the data set, I made use of VIEWs to abstract the filtering and turned it into a CLI tool.
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?
For the sake of being precise - the “form_with” is not equivalent to the presented HTML. The form_with helper injects an additional hidden input element that makes sure that the form cannot be submitted “illegally”.
I think this is a great example of all the small details we take for granted in the tools we use, and we would miss without realising when following these tips.
That hidden CSRF field can be added without form_with though, and Rails still protects against not including it. I left it out of the example as it didn't seem relevant
Yes, it can be added, but manually going over all form. Also, how would it protect against a CSRF without the token in place?
Note: I totally agree that we should strive to go HTML first. However, this specific example is a bit unfair.
`<button onclick="this.classList.add('bg-green')">`
Encouraged? Huh? We spent YEARS splitting logic from presentation and not describing presentation with visual characteristics.
This is a terrible idea.
Amen. Everything else in this article I can stomach. But onclick - just say no.
This is actually the most interesting one to me, not because I prefer it but because I want to see what others think.
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.
I just can't bring myself to like or be encouraged to use any form of approach that binds together logic and presentation. It looks and smells like terrible programming. Separation of concerns matters and, as you mentioned, more seasoned devs had decades of this being drilled into us.
I love the idea!
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
Assuming your site doesn't literally have only a single page, how do you handle reuse of styles and potentially behavior across pages if you put everything into one HTML? I've tried out the "everything in one file" approach in various contexts where it has worked out fine, but a website seems like the one place where it would quickly become an issue. I would at the very least assume two reusable kept separately from the .html(s): .js and .css.
You're absolutely right. We had additionally one common JS/CSS file each.
Every approach has its pros and cons.
Well. This was how we did web development before it turned into so many abstractions that most comments either is too young to know or simply not understanding that adding more abstraction is not ideal.
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.
A return to unsafe-inline? That feels like a bit step backwards when it comes to cross site scripting attack surface. Content-Security-Policy forces you to opt into unsafe for good reason.
I was about to comment that but luckily stopped to search if someone else already did. In our company this is taken pretty seriously and would trigger some raised eyebrows from the security department :)
While I agree that the article overlooks the security aspects of inline scripting[1], we do have content security policy[2] at our disposal using CSPnonce[3] andhash[4] keywords to allow inline script and CSS. On the other hand, the articles ease-of-use argument of inlining doesn't really hold up after factoring in CSP.
In my opinion, it's consideration asunsafeisn'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 havenonceorhashin 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/
Neither of those work for the inline event handlers proposed by this article. You need unsafe-inline or unsafe-hashes.
Does anyone have a good list of vanilla approaches? I'm a fan of details/summary, but I'm sure there are more I don't know.
These vanilla JavaScript features are pretty great IMO
-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...
Tbf they got better. Jquery basically existed because the js builtins were hairy
I like datalist quite a bit for „poor man‘s autocomplete“ - you can dynamically fill it via JS and will get the suggestions shown in the completion fields above the keyboard on mobile and… well, something (?) on desktop. Not as nice as an autocomplete, but with way less issues re accessibility etc.
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,…)
This whole post is an anti-pattern and bad advice. It read as from someone who didn’t go through the growing pains of building complex websites.
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.
Building websites with React also has its pitfalls and using React means introducing a lot of complexity. If you aren't already using NodeJS on the backend, it's probably best to avoid ReactJS unless it's actually necessary.
What does nodejs have to do with reactjs here?
doesn't the inline JS (onlick="this.classList.add('green')") harm/complicate CSP headers?
Yes, it all flies in the face of accepted strict Content-Security-Policy best practice.
I've not seen the reasoning for this in the thread.
Best practices are generally called that for a reason.
This seems like it came from a newbie/inexperienced dev.
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.
Not newbie or inexperienced, have built & managed multiple large teams & been thinking about this for a long time
There's a few reasons for the ratio mentioned in your tweet. Rapid industry growth in the past decade and the fact that junior devs are cheaper to have on a team. It's got nothing to do with writing a website in HTML vs React.
I wholeheartedly support this. But frameworks exist for one simple reason: HTML has never been powerful enough for the work people do.
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 justtwosimple 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.
whats keeping them from being provided by an import as in htmx?
You can already get very close to this style of writing html/js using Lit.dev
I'm not a big fan of JSX...
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.
Also not a fan of JSX. VUE’s component definitions are slightly better - at least it’s using actually HRML tags and <template>s. Personally, my favorite is Lit’s approach, writing HTML in tagged template literals. It’s still mixing your HTML with your JavaScript, but it feels much cleaner, closer to the vanilla experience of marking up content.
I have to use gmail for work, and I use the html version. It doesn't eat hundreds of MBs of ram or slow down my browser like, say, Google cloud's UI does. Ymmv.
(of course the html version is not as good as a non webmail would be. Such is life I guess.)
Been doing this with mkws and onhttps://mkws.shsince day one!
This would be considered a build step, though.
Agree, but only for the HTML files where it makes sense in order to keep duplication at a minimum.
This is perfect for Svelte
Why?
What's the opinion on re-introducing HTML attributes for style properties, eg. <div width=40pct color=red> (possibly with additional enumerated attributes usable in short value-only syntax as in <div disabled>) rather than <div style="width: 40%; color: red">? I mean, introducing a secondary syntax for item-values, like CSS did, quite never made sense to me personally even though it was nevertheless thoroughly defended ([1]). I guess it doesn't make sense to me coming from an SGML background which had style sheets capable of stateful/automaton-based assignment of attributes for ages. But now with tailwind so popular and little more than inline styling with sane defaults perhaps, and this manifesto expressing a strong preference for markup attributes, isn't it time to come to the realization that, whatever point CSS had when it was new, surely is driven ad absurdum by its obscene syntax proliferation and extreme redundancy (something even W3C CSS WG's chairman/staff contact already was warning against over ten years ago [2])?
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.
For me, it does not matter if it is inline CSS, style attributes or Tailwind. I do not like them.
Personally I prefer to take away from this the aspects that might work for me, as opposed to looking for anything I can come up with to rip the author a new ass.
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.
This was the end result I came to as well after the bigger frameworks started gaining popularity. I work primarily solo in a single organisation with server-generated (CMS driven) websites.
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.
I agree with everything but inline javascript
<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.
It is going to be problematic when it comes to refactoring. "Can you make the button's parent container green" request comes in. Now you are hunting through CSS selector going up and down the tree. "Can you put the button that goes green into this page". Now bam! The CSS selector you used breaks as there is another element to confuse the query.
I get the sentiment of this, but I struggle to recommend it (not least for the spelling mistakes, especially in the code examples)
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 wellas 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.
I was going to comment, but you've done it for me. Your additional advice is spot on. But I actually think, "do whatever you like, the web is designed to be flexible".
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).
Relying on simpler frameworks when you can make sense. But the notion of getting rid of build steps is a complete lark, just be more efficient with build steps, and if necessary, don't include them in production. Also why would you want to prioritize adding your attributes to HTML? Are you making a document and hosting it as a website? In what other world is that preferred? CSS isn't hard to navigate, if anything one should be encouraging better CSS practices. Yes, frontend scripts can obfuscate styling, but perhaps just don't rely on that if you don't need to, which is already a no-brainer, since it's harder to give an attribute via some JS rather than shoving it into a style document.
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
A lot of this stuff is a response to the worship of complexity by the webdev industry.
The author raises some interesting points.
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.
The customer probably cares if your app takes five seconds to load because of the resource size, or reliably pegs a CPU core whenever you're using it.
Of course, neither of these things are guaranteed in a React app. But they're definitely way easier to back into by accident.
HTML should have been improved by now. What is sad is that fundamental things like a put request through a form can't still be done by simply a method. Keeping html hobbled is literally a conspiracy.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16
It doesn't make sense that you would want to PUT a form apparently.
I love the ideas here, but honestly the examples are a bit weak here.
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.
> Where possible, default to defining style and behaviour with inline HTML attributes
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.
I get real confused by these.
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.
On web, an HTML first approach in many cases can mean a better user experience.
Whether to use an HTML first approach or something heavier like React depends on the product being built.
Yeah, I agree with others, not good. Recommending inline CSS is just wrong.
I assume that means no Tailwind as well
The Web was never meant to have an interactive scripting layer. It got there by accident. Microsoft's XmlHttpRequest paved the way for page loads without page loads, and it became an accidental standard due to how it worked.
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.
Another web development prophet with quick solutions for simple cases.
Specifically on the “use libraries that leverage html attributes” point:
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.
I'm missing a bit "if you have to use javascript, use vanilla javascript where possible" here.
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?
The style presented is far from the norm at the moment not just because of gate-keeping and over-engineering, but because web software is refactored andimprovedso many times over.
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).
If a developer who has familiarity with HTML but not with your backend framework looks through your view files, they should still be able to understand 90%+ of what they see
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
Writing your code in a way that makes sense to someone else is a skill.
If someone writes the bonkers code in the article’s bad examples, I guarantee their “HTML-first” code will be just as bad.
"Prefer vanilla approaches using HTML"
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 theory is that now that central banks money run out we're going back to sanity. The end of centralbanking-driven-development is coming
The person who created that website should have a look at the recent Rails updates :-)
Or check out DHH's most recent thoughts on minification etc.
I would add that for noscript/basic (x)html version of web sites, 2D "semantic" HTML documents are not harmful, and table navigation is ok for screen readers if not done too weirdly.
Of course, I am not talking about the abomination of "semantic web" we had a decade ago.
Thank you
The no-code (HTML markup only) SaaS platform I'm working on seems to fit well with this philosophy:https://www.saasufy.com/
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.
I stopped reading after "This is good from an individual perspective because it allows a greater number of people to become web programmers, to build great web software, and increase their income.".
I don't think I buy the premises under the goals here.
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.
I built something recently with the same ideas in mind:https://github.com/sethkimmel3/tailgate. It allows people to build generative-AI applications without any of the complication of setting up a backend, and in the simplest cases only requires adding HTML attributes.
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.
User/Customer needs SPA, not HTML, they just don't care the tech, lol.
Why on earth do so many projects like this have to hide behind this weird inclusive language?
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!
Doesn't Tailwind have a build step?
I agree completely, but hiccup rather than html.
Where possible, default to defining style and behaviour with inline HTML attributes
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.
I think of myself as a very "semantic, HTML-forward" guy when it comes to front-end work and I found myself disagreeing with the vast majority of this.
I strongly believe that no one would hate or love to hate the build step if we didn’t have to mess around with so many unmaintanable configs, dependencies and pipelines of translations like typescript -> js with commonjs or es modules and so on. Still, for me, which ever code I write I want it to be compiled/translated by a machine, that given a “browserlist” knows better than me how to output code that works for the most system around. And that’s especially true if you have a successful product with a lot of customers. I agree on rolling back most of the abstraction madness we built so far, but surely I can’t remember how to write es5 compatible code anymore, should be a no brainer for me. Lastly, I can’t disagree more on improving inclusion with “html first”, whatever approach you choose it’s still super hard to have a web app that has: perfect audit score, adpative ui for all screens, accessibility, print(! what id customers demand that each app page should be printable?) and more I can’t think of now. This job is hard, it’s not for everyone and going back to first principle won’t save us from hardwork anyways
thanks I'll use it on my auntie's cupcake website
It’s ok to use whatever stack, framework or tooling you are most comfortable with as long as the result loads in 1 second on mobile, half a second on desktop and scores 4 x 100 onhttps://pagespeed.web.dev/without using any divs, or, god forbid, statements like container class=“wrapper”, but that goes without saying really.
To me this reads like a polite version of motherfuckingwebsite.com. Don't get me wrong, I love the idea and forked the pug/jade templating language just to build my site in pure HTML but without endless closing tags noise.
The overall sentiment of this approach is valid, but there are some tweaks to it that I've found effective.
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.
What goes around comes around.
Once upon a time these first principles were the bedrock of web development.
There is a valid philosophy behind this, but the arguments are a bit flawed. For ezample CSS is not only styling (as in theming) it is important for GPU animations and is hard to sync with app state ans JS without some tooling.
I made some web app with the least amount of logic in the JS, and almost all of it in a flask server, with a few ajax calls.
I have to admit that managing asynchronous js callbacks is really a pain to deal with.
JS is really an awful, awful language.
I think the recommendation to use tailwind and avoid build steps and incompatible.
We are getting back on track!
I love that people are finally coming around to abandoning the build step.
The article says 'For styling this can be enabled with an SPC library like Tailwind or Tachyons.'
What does SPC stand for?
Not bad, and reminded me of Simple & Useful:
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...
I agree.
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.
Isn't this just Unobtrusive Javascript all over again?
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.
I'm on board with this conceptually. Most of the independent sites I build I still do this.
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 adecadeto finally get enough momentum to move people away from this kind of crap.
I'm going to lovingly refer back tohttps://www.csszengarden.com/. Separation of concerns is agoodthing and should be used as much as possible.
Does anyone find it strange that a syntax highlighting library needs to be loaded on a site singing the praises of HTML? Sometimes I don't think the web platform takes its own original purpose seriously (presenting documents).
Amen to that!
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 published this article on Template Animation (aka DOM Templating) 12 years ago:
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.
This trend makes total sense given the current web panorama.
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.
I love how many folks here seem to think JavaScript (and its popular libraries / frameworks) are somehow threatening to the web. This is like saying people should write native user interfaces for iOS and Android, "but no, not with Swift or Java" (respectively).
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.
I like the spirit of the article.
My personal preference is server side templating using as much default HTML as possible with JS as progressive enhancement (using HTMX or something similar).
Locality is underrated
The majority of web pages fall into one of two categories: long-form content where the primary interaction is reading, and applications (consoles, editors, tools). I do not think the latter benefits from an HTML-first approach as outlined in the featured article.
<details> and <summary> are great, but animating them toslideopen instead of "pop" is difficult to implement without JS when the contents are not a fixed height.
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.
Does anyone else find that blue tint on the top of the page makes it really hard to read? I guess I usually scroll the text I'm reading to the top...
In other words, return to web development practices from the early 2000s? Isn't this just the pendulum swinging the other way? Haven't there been genuine problems with that style of authoring websites that the last twenty years in web development have been trying to solve?
Article doesn't even have anchor tags
Meh.
I say build software in the way that you like. Or the way the boss says.
aka make your website look like shit because half the default elements can't be styled
If you're creating a web page, use HTML. If you're creating an application interface, use a UI framework like React.
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".
This is all nice and suckless, until you will have to scale your codebase and/or add some more features (possibly alter someone's code) and deal with exponential complexity of DOM manipulation. React came to solve all this
Raúl Gúrru Miau {Miáu} 8
A lot of these points are great, but the examples here don't help for building more complex components or pieces, that could contribute to a larger application...
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'm a big fan of that approach, but it's kind of funny (and sad) that such a simple page doesn't even look as intended with JavaScript disabled, as there are some placeholders of CloudFlare's Email Address Obfuscation visiable in some of the code listings.
It seems the author was trying to apply KISS to web sites here, but being unnecessarily dogmatic they added additional complexity over mundate aspects such as whether you call your CSS /dist/output.css or /styles.css. This is completely irrelevant.
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, becausein generalI 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.
This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference.
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.