This is the blog equivalent of fast-food. Sure, it's technically "food", and most people will agree with the content, but it's essentially empty and does nothing good for your health (nothing to change things).
I would love to see a list of projects that do less of the front-end garbage. Someone mentioned the levels.io guy. I also like HTMX. Personally, I've seen great success using 95% server-side rendered sites with 5% Alpine JS sprinkled on top.
I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone.
The vast majority of websites out there probably don’t even need JS.
For every front-facing website there's 10 internal facing tools and dashboards. You don't "need" JS would be the wrong framing here. It's more like you don't need JS aversion when you're developing internal tools and you don't need the complication of SSR either (ask yourself whether the native or mobile app world is jumping on the idea of ultra-thin clients).
We waited so long to improve semantic HTML that ML rushed ahead and will probably deliver semantic comprehension far in excess of whatever we can hope for with conventional means now.
Not that guy, but for highly dynamic and interactive sites, it’s actually easier to manage state if you‘re working on the client side only.
Introducing SSR and data handling on the server side to an app can be much less productive if you don’t need the performance improvements that SSR brings.
This is the crux of where I always landed on whether to render on the server or in the client.
Render where the state lives. If a piece of state is stored on the server, and the server will have to be notified when it changes, rendee HTML there. For any part of the UI that really is temporary state that only lives in the client, just render that piece (or changes to that piece) in the browser and leave the server out of it.
An all or nothing solution is rarely the right answer.
Many developers fail to notice how colored their perspectives are by a) nostalgia for the technical simplicity of web 1.0, b) the curse of expertise, and c) confirmation bias.
A website, just like any other application, exists to solve a problem. The right ratio of hassle/efficacy/reliability definitely isn't the same for every application, and often not even the same among different user groups. What developers consider to be a hassle or too complicated is dramatically different from most other groups. Doctors and children and mechanics and mechanical engineers and artists have more in common with the way they interact with software than any of those groups do with software developers. If you have a working mental model of what's happening behind each click, your perspective is totally different.
To a developer seeing a form submit and waiting for a return is a set of actions with a story behind it. We know what's happening. To a typical user, it's a period of flickering and flashing and waiting after they clicked on a button. There's no meaning to it-- they just compare the action of button A which changes screen state instantly, to button B which seemingly dicks around for a while until something happens. What about on slow connections or devices? It depends on what problem you're solving. If you serving up nearly static content, using an SPA is absurd. If you're doing something interactive, it's way worse to have constant reloads than use a -----properly designed----- SPA that loads once, uses local storage efficiently, and only makes small API calls to the server once its loaded. If an SPA has poor architecture or is a bad solution for the problem, the problem is the developer that made those decisions, not SPAs.
A 500% reduction in technical complexity is meaningless to most end users. If it comes at the expense of having to look at a page reload in between frequent operations, it's a big annoyance. Sure, I'd much rather put together a nice clean static site than do something dynamic, but what the hell is the point if it's not the best way for users to solve the problem they need it to solve?
Beyond that, I guarantee you there are many sites that 'just work' the way you'd expect a website to work and you'd have no idea they were SPAs. Making a proper SPA requires a lot more technical design and expertise than making a traditional site, and using a poorly made SPA is a WAY worse experience than using a poorly made static site. That makes it really easy to notice when one is bad, so it makes SPAs seem bad, generally, which is just not true.
For the same reason we can't leave all technical decisions up to designers, we can't leave all interaction decisions to developers. Obviously it will make development a lot easier and smoother if we do, but that's one of many factors, and quite often not the most important one.
I also prefer the client-side approach because the separation between server and client makes more sense to me: the backend serves data, the client renders it. It is also much easier to manage state. Unless the website is extremely simple, I always go for JS framworks.
I never had problems with performance. React is less than 150kb, and as the backend is not a bottleneck, the website feels very snappy.
SSR is not enough if you want an interactive page, you'll need some JS. If you do, instead of dealing with a ton of scattered JS scripts, I'd rather have a single React/whatever application.
So what makes sense to you is adding the additional layer of transforming the JSON data into HTML from an API - all of which are almost always in the end tailor made for the app anyway - using a significant chunk of code within a completely separate and bloated ecosystem and in a different language than what the server uses?
A bonus "feature" of this, and a very important one, is that this now also requires different specializations on your team and the personnel costs and communication overhead that comes with that. Great, now adding simple CRUD functionality to a website is a two week project syncing between backenders and frontenders, for something that someone wanting to scratch their own itch could hammer out independently in a single day back in the SSR days.
Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing different specializations and the communication overhead is already part of their workflow.
Your argument suggests that SSR requires only one type of specialization, but that's not entirely accurate. SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code. This means their expertise already needs to cover multiple areas and languages. While it’s true that frontend frameworks introduce additional build tooling, developers today are generally familiar with this ecosystem. The backend developers I work with do have a good understanding of React and can work with it comfortably, and I have seen junior developers picking it up within a week or two. They don't need to be specialists in order to be productive.
Yes, it is true that many backends are tailor-made for a frontend, but going exclusively HTML-first will lock you into this state, unless you are OK with revisiting it to add a JSON API later to support additional use cases. When I write an application, it usually comes with a CLI in case I need to use it from a server without access to a UI, and I hook it up with tools for integration tests using its JSON API. It's also common to see frontends that are powered by multiple backends, and in these cases, it makes sense to have a separate frontend application that uses APIs.
So yes, it does make perfect sense for me to have a layer between presentation and application.
> Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing different specializations and the communication overhead is already part of their workflow.
What makes you think this is confined to large companies? And even large companies have small teams.
> SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code
It's true, but it's a smaller scope, better & more stable documentation, and overall a smaller threshold to get going to add a form in passing to a SSR than getting going with a new ecosystem.
> unless you are OK with revisiting it to add a JSON API later to support additional use cases.
Adding another output format to an existing product is not a scary problem and usually not even a time consuming one, and best of all you can wait until it's actually needed. This includes endpoints for a CLI. Now the aren't shared either, so the HTML output can be adapted according to the needs of the website along its lifetime, and the debug endpoints' JSON output can be adapted according to the needs of the CLI along its lifetime.
Small companies are addressed indirectly in my second paragraph. Even if you have a small company or a small team, they still need full-stack experience. Documentation for frameworks like React is already very mature, so I don't think it is a problem. The scope might be slightly larger, but getting a React stack going nowadays can be done with a single command, and maintaining it has not been an issue for my team of mostly backend engineers: we are able to manage a few UIs in React for our tools without any problems. I would say the additional complexity introduced by React has been minimal, the team likes it, users like it, and the experience was pleasant enough to win me over.
Adding another output format to an existing product is not a scary problem and usually not even a time consuming one, and best of all you can wait until it's actually needed.
I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming, and by adopting it, I gain the flexibility to handle new use cases like integrations with other APIs, integrations with other frontends, and CLI tools right from the start. A proactive approach means I don’t need to revisit and rework the application later.
Not sure how the entire npm/react/SPA ecosystem can be described as stable when it's so many moving parts that it's almost a running joke. Latest I've seen is going full circle into the server-side again and some kind of a compiler?
> I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming
SPA UI frameworks are not particularly time-consuming? Then we have very different views on productivity.
Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived.
Because reality is often different from the running joke, the latter usually being an exaggeration for comedic purposes. If you constantly chase the latest and greatest frameworks, then yes, you’ll find yourself frequently rewriting your application over and over again. This applies to any technology, and it's especially common when less experienced engineers focus on the technology instead of the goal. Take PHP, for example - despite the jokes about it being obsolete and a horrible language, many developers find it effective when used correctly. I would agree with them. There are perfectly valid use cases where PHP is an excellent choice.
Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived.
Sure, but we are not paying a higher price in the name of proactivity, instead we are getting it as a bonus. As I said before, the maintenance cost has been negligible for us. Implementing and maintaining a React stack has not introduced significant overhead, the developers like it, the users like it, and we are happy with it.
For so-called "tech" companies that intermediate, surveil and attempt to profit from computer users accessing content the so-called "tech" companies did not create, that is actually a "problem". For example, as a "solution", Google intentionally adds delay to "loading" so that ad auctions can run.
When these companies use some marketing slogan like "Make the web faster" it is quite amusing. Ads are what slows it down and dissemination of ads is their "business model".
Can app makers in other ecosystems learn from the web here? Should mobile and desktop apps just be ultra thin clients with the next "page" being rendered on the server? Do you think this argument tickles the performance bone of other app communities?
Apps and websites are fundamentally different so no. Apps are by definition highly dynamic, while websites start out as static documents that some people put too much macros into to make them appear like (bad) apps.
Most of my personal projects haven't had any state that needs to be managed server-side: any needed data is either static or can be pulled from "someone else's" unauthenticated API. Which is how I prefer it, since all incoming data from users is a big liability these days.
I love having deployment be "drop a folder of static files onto a server".
Also scaling out SPAs is a non-issue. Servers have basically unlimited throughput for delivering static files, assuming you don't inline any 24MB uncompressed images. Or just throw it on Cloudflare, whatever, again, it is just static files.
They made this thing called a static site generator about 25 years ago, and modern ones like Astro are better than ever.
Just like your SPA, you have no server to look after, (eg) Cloudflare builds it all, hosts it all and there's no JS overhead for clients, no SEO hassle, etc, etc.
I'm not saying SPAs are wrong. There is a very valid set of uses and it sounds like you're well in there, though if your state model is so fragile to won't survive me accidentally refreshing, you need to look at that.
But many enthusiastic young developers start using a framework and decide to do everything with it. Same was true on server dynamic frameworks. Everyone's first project is technologically-inappropriate blog. These sites would be objectively better as SSG sites.
Btw, Astro is surprisingly excellent at using frontend components from multiple frameworks, even in the same project. If your interactivity is in-page, or you have a mixed MPA-SPA domain, it's well worth a look.
Even the DX, I prefer it to Next/Next projects where you're chained to a set of dev dependencies from the start. My last Nuxt upgrade took three weeks to unhook various deep integrations and fix things (Vue 2 to 3 too). Nightmare.
> though if your state model is so fragile to won't survive me accidentally refreshing, you need to look at that.
Highly interactive experiences are complex to manage full refreshes with, is it do-able? Sure. It is something I want to bother with for a project I work on 1hr a day after work? Not really!
> Everyone's first project is technologically-inappropriate blog. These sites would be objectively better as SSG sites.
I am amazed that Wordpress became the behemoth that it is for personal blogs, given that 99.99% of them would work well as statically generated pages.
Honestly the move towards SSG that then embed some discussion component seems like the best combo for most small and medium use cases.
> I personally do all my sites with 100% server site rendering and bits of JS here and there if I need some interactivity that can’t be done with CSS alone.
So actually not "100% server side rendering" at all. And probably paying all the costs of using JS more extensively, but gaining fewer of the benefits.
Yes you send a full, html page over the wire. It will render. script off. You can enhance it later.. You know a basic is this an email, is the pass word not empty check for a log in or some other fields if you have a basic contact form.
The web worked before all the JS frameworks... It still works that way today. It's fast, low bandwidth and easy to cache.
What does the term "100%" mean to you? How does that fit into "100% server site rendering and bits of JS here and there" in a way that forms a coherent concept?
100% of the rendered page is served by the server to the client. Most pages are HTML and CSS. In the rare occasions I need some interactivity (a gallery, some dynamic filtering, things like that) that functionality is provided by JS that’s included in the page, the same page that’s passed by the server to the browser.
JS doesn’t render anything. If you turn it off the page is served anyway, some minor things might not work.
>100% of the rendered page is served by the server to the client.
servers always send 100% of what they send.
is what is sent 100% rendered already? well, browsers do a fair amount of rendering, that's what they do with CSS and HTML. and then you're adding on JS. we differ in the language we use to describe what is happening.
perhaps you've rendered something from a database wrangled into the 100% page that gets sent, it's just not done rendering yet.
Well if you want to play the semantic game then there’s no such thing as a server side rendering because yes, the browser has to render that page on your monitor.
Consider the tool the author mentioned, jQuery. It is on the text almost as a museum piece.
The things jQuery did (compatibility, CSS selectors, fetch) became standards or stable almost a decade ago. We don't need a 2024 version of jQuery, what that tool did we can now do vanilla.
And that's about it. Perhaps React would be useful for a large project, with lots of complexity to manage, and assuming that people involved have experience in using it to manage such complexity.
On the other hand, that React project that contains only some forms and page navigation could totally be <form and <a with some small vanilla JS snippets.
Sometimes I choose React because it’s easier for me, despite it adding unnecessary complexity to the project.
For example, I’m terrible at front end, and design. Tailwind has a React library that handles many of the UI requirements and produces a decent-looking front end with minimal effort. I know enough React that the complexity doesn’t scare me, and there’s so much documentation and training available that it’s easy to find answers. It integrates easily with other frameworks. I can reuse components I built for other projects.
React is often not the optimal choice for the project, but can yet still be the right choice.
There are many pure CSS libraries out there that meet varying degrees of UX requirements. Form controls, typography, layout, everything.
MDN has a complete documentation with complete browser support, examples, reference. It's awesome.
On React world, I often have issues with community components. I needed a dynamic table in my last job, there was simply none. You had to pay for a premium component, or use a code that barely passes 3min auditing (material-table-core). It was a nightmare.
A dynamic table qualifies as something I'd rather have a framework do for me. Jesus, YUI did that for free 15 years ago (with tests, with cross browser, with rendering and painting considerations...). However, we ended up rewriting significant portions of the original component we chose (all data handling, all export and import, all menu, all cell rendering, all style).
Exactly. A good designer with a deep knowledge of HTML, CSS and JavaScript will tend to prefer vanilla code, and it makes sense for them to use that. A full stack dev - like me - with a smattering of knowledge across the front end may prefer to use React.
When people argue about whether React is right for a project, they are often trying to optimise for different non-functional requirements. Those against might be considering performance, filesize, and complexity. Those in favour may be optimising maintainability, reusability (with other projects), ease of hiring and onboarding new people. So they can both be right, and what they need to work out is which NFRs matter the most.
"And sure, maybe you don’t need jQuery, and that’s fine. Will you need more lines of code to do the same thing? Of course. But even without jQuery, your complexity doesn’t grow exponentially like it would if you brought in a framework with its build system, linters, compilers, and 700mb of Node Modules ..."
It's a community site, with lots of user generated content and interactivity, but nearly every page is rendered on the server.
There are bits that need to respond and re-layout the page on the fly (like https://bettybeta.com/bouldering/projects ), that get just enough Vue to be able to do so. But they really are Pages, which means that you don't need to download and process 14mb of javascript to look at the homepage or any content page you might land on from Google.
Roughly 100% of consumer-facing websites can be built like this.
> Do you have open source project with the 5%/95% ?
Not yet. I just use Alpine for form validation (with the awesome mask plugin), checkbox dropdowns, dialogs/modals, and toast notifications. Everything else is Go HTML templates.
I wish there was a way to do custom builds of Alpine and just include what I need, but it probably wouldn't be too hard to do it in vanilla JS.
I’d love a return to sane css frameworks like SMACSS. And I’m using “framework” in the conceptual way. It’s not a library or anything. Just a set of rules you create for your css. Composable, no compiling, no muss, no fuss.
I built something with it once. I wonder if it’s still in use.
While I don't agree with the tone of the author, I do have to admit, there seems to be something foundationally wrong with front-end development. Yes, it's more complicated than server development in that it is a real-time, multi-point input, multi-output (rendered elements on screen) environment with synchronisation and concurrency needs.
But I used to write front end applications with MFC (Microsoft Foundation Classes, which is C++) using Visual Studio circa 2005, and it was never as complex as an SPA today. There is something wrong somewhere, and I don't think it's JavaScript or the DOM. The flaw seems to be paradigmatic.
Your second paragraph disproves your first. Websites' needs didn't drastically increase (I'm ignoring nonsense like WebGPU; render graphics outside the web browser like a God-fearing Christian!), but their complexity did. Why? Well, we told everyone with a pulse they could make six figures "doing web development", and we're reaping what we've sown.
You can still design websites like it's 2005, and they'll be damn fast. But pitch something like MFC or even PHP to a 20-something frontend developer now and watch the blood drain from their face.
"We" build both. You might be building WebApps, I certianly don't and so are countless others. The web is not one homogenous thing where everyone is doing the same thing at the same time.
Different people work on different projects serving different needs and we have to acknowledge that otherwise we end up in these silly tech-religious arguments where people think there's one and only one way to do things and that's certianly not the case.
React is a Face Book abstraction leaking out on to the web.
It's good for them. It's a perfect framework (+ graphQL) for there every page is custom in a walled garden environment.
It isnt a good way to build a blog, or a shopping cart. But A mail client in a browser, or a B2B app with a lot of data, A CMS... great places for it!
And it's great for FB too. (as is every other open source tech from a large player). Think about all the money FB saves NOT having to ramp up front end engineers... they get them pre-trained now on their tool.
"Yes, it's more complicated than server development in that it is a real-time, multi-point input, multi-output (rendered elements on screen) environment with synchronisation and concurrency needs."
I would argue that most backends typically also deal with more than 1 user at the same time (and in real time).
> I used to write front end applications with MFC (Microsoft Foundation Classes, which is C++) using Visual Studio circa 2005, and it was never as complex as an SPA today. There is something wrong somewhere, and I don't think it's JavaScript or the DOM.
No, it's CSS. No real UI framework has anything remotely like CSS, and for good reason. But people like the author of this article keep trying to make CSS work instead of writing it off as the mistake it is, and so web development remains awful.
I think the flaw is that we've got one type of browser for everything.
Let's just have a bank browser for banking and a restaurants browser for deciding where to eat. Then the banker need only indicate that the account is overdrawn and the restauranteur need only indicate that the fries are gluten free.
The number of people who need to care about how these things are presented to the user could decrease by a factor of 1000 if we just standardized a little and stopped trying to control every little thing.
I was recently on a project where the backend was written in Python and finished in two months. The frontend guys are still dicking around with React components eight months after the project started. The front end on this project is child's
compared to the backend. It's frustrating.
There was a point in the history of front-end dev when they all started calling themselves "rock stars" and became convinced that they are the future of software development. The SPA trend gave frontend devs an excuse to write unmaintainable code, gave designers an excuse to call themselves software developers, and then they all told the world they are doing "full-stack development" when Node appeared. Meanwhile they never bothered to learn pre-SPA UI, UX, or content design principles.
Thing is, working on front end never gives you a chance to work on problems that backend has to deal with. I never let JS guys work on backend code, because they are lost if they cannot find a module online that does what they are asked to do, or is missing half of the features from the spec it promised to implement (always the hard ones). We then have to pick up the mess and rewrite it in Python or Golang, which is wast of time and money. I once quit when when the client showed me the Python code written by a JS dev. My devs refused to touch that shit and we went to work for another client.
> I never let JS guys work on backend code, because they are lost if they cannot find a module online that does what they are asked to do, or is missing half of the features from the spec it promised to implement (always the hard ones).
Stop self-aggrandizing. A huge percentage of backend devs would be lost without their giant MVC frameworks holding their hands throughout the dev process. Many of them do nothing more than write little controller functions while they lean on their frameworks, authentication modules, routing libraries, ORMs, and templating engines to do the hard work. You're not sending rockets to Mars after learning how to spin up a Django c.r.u.d. app.
To be fair to good JS backend devs, my view is biased by the fact that me and my team do Python and Golang work and the only time we interact with JS devs is when there is frontend to be written. Some frontend guys are good, most of them are poorly trained and those think they can write backend code and lobby managers to let them have a go at it. With disastrous results. I have never worked with JS backend devs who were any good. I am sure they exist, but I have yet to meet one.
I literally left front end development because of stuff like this. It felt like insanity. Throwing out the door debuggers, linters, all the tooling so we could express objects as attributes?… and enforce managing state better?..
It felt like a flood of junior programmers in an echo chamber set off by an opportunistic engineers at Facebook who were more interested in creating their own job security then work to evolve an existing standard.
Seriously who honestly thinks that the authors and governing board of HTML and CSS didn’t closely consider the features in react?
What kind of arrogance does it take to say they’re fucking dumb let’s reinvent EVERY tool on front end because we know better.
This one really gets me. Being looked at like an alien from mars when talking to people about styling a page with a few classes here and there rather than pulling in 6 different dependencies of Tailwind et. al is maddening. We are web developers. We get paid to know these things, not to complain about them being annoying and try to find hacky workarounds. And now I get to sift through your utility soup and hope to god there's a class in whatever framework you GPT'd some boilerplate for that does exactly what the designer wants.
I like writing UI with Tailwind, but I have absolutely no idea why. Ultimately what I do is look up all the actual CSS values I want on their website, then stick in the proper classes.
I think it must be because I have zero actual CSS to care about. There’s just nothing in my UI aside from React components, and there’s just enough sugar that it’s easier than using the style attribute everywhere.
Thank you. I'm at a css in js company and everything you wrote about it is The Truth. We've got nav menus written in reams of javascript. Stuff that could be done with zero js, or a couple of lines of glue. In a previous role I used Ant Design which were on the SASS train, trying to override the specificity of their stupidly long selectors was painful.
React is too loose, it just enforces no abstraction or discipline. JSX ends up an ugly nightmare of angle brackets, ampersands and question marks. You often have to piece together how the component works by staring at all the event handler code for minutes hours days. Most of my colleagues writing it would stare blankly if I mentioned MVC. I think I would come down on the side of Angular, it's opinionated, but at least they attempted to separate the template from the controller, and logic in the services.
There’s a lot I disagree with but I’ll point out one in particular.
> how do we make content presentable as easily as possible, with as little duplication as possible, and with as few negative impacts to the user as possible.
Why is this the priority? If I wrote a language that was solely focused on removing duplicate code, and doing the minimum to appear decent, that would be a pretty bad language. I care a lot more about composability and readability than de-duplication and floor raising. Let’s face it. CSS comes from a fundamentally different situation than the modern web. I’m talking about optional styles that do not affect the content, that are written by one or two people, and likely total at most a few hundred lines. That is nowhere close to modern websites. Bemoan that all you like, it doesn’t change the reality.
I fear that so much about what the web is has been forgotten. I've had some surreal discussions with frontend devs that don't have a fully formed concept of what a URL is. Their solution to "sharing" is to either have their users instruct each other using words on how to find a particular page, or to propose some overengineered URL shortening scheme to encapsulate state which belongs on the path or query string. It really feels as though usability is being treated as an afterthought.
Most app’s code sucks but it’s honestly not the fault of React or styled components or server side rendering etc. It’s the fault of people treating front end like it’s easy and can have any old fool thrown at it. The truth is self-contained pages allow for more errors per line of code with fewer crashed sessions than a comparably bad backend with highly coupled modules. So hiring managers and bootcamps throw inexperienced devs at front ends until the tickets get closed.
I’ve been doing this as a hobby since 2003, writing all caps <HEAD> tags and FTPing .htm files to a web host. I know a bit about how we got here. If you’re really this pissed off you should get a new job and build everything how you want it. I’ve work on greenfield projects almost exclusively for my entire career. It can be done.
I built a fairly successful vc funded startup with a front end lead that thought this way about frontend frameworks. For a suitably complex application what happens is that you end up organically building your own framework in order to manage the mess of application state that is the screen. Now in order to spin up, new engineers need to learn this unusual organic framework to get things done rather than just use the excellently documented React that they likely already know.
Ya. This is why React is popular. It's just a bunch of decently good front end best practices. Popular, not the best X for Y but with easy replacements.
Yeah. Seniority should come with the realization that all tools are there for a reason and every engineering decision is a trade-off. Accept that maybe you don't know everything and be open to change your mind. All these "opinions" don't get you (or your employer) anywhere.
When I started building websites professionally (in 1998) we had an adage that people used all the time to talk about how to get traffic to your website: "content is king!" It was a play on the "cash is king" motto of small businesses I think. It was very accurate too; if you wanted traffic then you had to build a site people shared. Search engines were not as effective as they are today.
Then the web changed a bit. In 2005 to 2015 (ish) people transitioned from being consumers of web content to creators of that content. We called it "Web 2.0". Content was still king because people went to their favorite sites to create things that other people would read. But anyone with half a brain could see what was coming next.
Around 2015 people stopped making content for other people to spend time consuming and instead shifted to making content that was seen for as little time as was necessary for them to hit a 'like' button. 'Content' in any meaningful sense died. It became a sentence on Twitter, or a photo on Instagram, or a really short video on TikTok.
The entire premise that users go to websites for the content is nostalgia. That side of the internet is effectively dead (despite some noble and awesome attempts to keep it going, HN being an example). Today very few people get paid to build static content sites. If you're a web dev you're paid to build an app that enables people to do things in a browser - and yes, that means working with something like React. All web devs try to crowbar React into everything simply because that's what they're paid to do, and they're paid to do that because that's what users want to do. Railing against it is a waste of time. The Internet today is not same as the Internet of 25 years ago.
Well said. Also been doing this since the 90s. I still like discovering new sites, blogs and creative things people make. HN is one of the better sites for that.
If you haven't already heard of it, you might like marginalia. It's a search engine/website finder/experiments. I've found it really useful for finding small blogs and interesting perspectives!
I want to both upvote and downvote your comment. I upvote all the top part. But I'd downvote the conclusion. That side of the internet is all but dead. It might not be the majority in terms of traffic (for obvious reasons) but it's probably still the majority in terms of number of websites and (some) people still care about quality content.
You can write a good website with React. You can write a good website with htmx. You can write a good website with HTML/CSS/vanilla JS.
The average developer who cares enough to learn and use htmx/vanilla JS is going to write a superior product simply because they care more about performance and/or because they are better than the average developer.
---
I'll plug my favorite way to build a site: Astro [0]. It allows you to write JSX that compiles to static HTML. You can use React/Vue/whatever as well for anything that actually needs to be dynamic.
I'm not affiliated in any way, but I did build my personal site [1] with it.
The entire article itself presents incredibly poor reasoning or no reasoning at all for its points.
It's really hard to appreciate it now because CSS (along with JS+HTML) has been extended and upgraded gradually over the years, but CSS is incredibly good for styling and formatting DOCUMENTS - which have a very specific definition, especially back in the 90's when it was first conceived. This is what is was originally designed for.
In that sense the complaints about CSS are perfectly reasonable: why are we using a document styling language for building arbitrarily sophisticated web applications when it was clearly not originally designed for that? You could say the same with HTML and JS really.
> Quit acting like CSS is some giant-ass mistake that needs fixing. A group of people who were collectively smarter than us wrote those specs. They didn’t make mistakes. Assume you are making the mistake, not them.
So what year again was the CSS standard was first published? Checks google quickly -- oh it was back in...1996. HTML was...1991. And JavaScript in...1995.
Yes, it's well known that people in the 1990's were much smarter than people in the 2020's! It's not like there's been decades of progress since then! CSS is utterly fit for purose and bereft of any flaw or defect! Absolutely nothing new needs to be invented or discovered about front-end web development in 2024! There's no point in trying to improve things!
OK, it's hilarious the author rails against things like SASS, and CSS is now being updated to incorporate many of the same features that SASS introduced:
- Not to mention things like CSS variables, calc() etc.
Usually people whine about the status quo or things staying the same for too long and in response, try to improve things. This article almost seems like a big whinge about how things should stop changing and regress or go back in time? That's not happening. If people had the author's sensibilities or attitude back in the 2000's we'd never move past `float: left` for positioning or tables for multi-columnar layouts. Utterly bizarre.
It looks like the author has written plenty of code to back their rant:
> I did agency work for 11 years before making the choice to work for a very large tech company. I have worked across sectors like insurance, healthcare, retail, banking, investing, marketing, and manufacturing. I have worked with global brands which are household names.
> I have written a lot of front-end code for a lot of companies. I have also dealt with a lot of consequences created by front-end code. My criticisms come from my role as a front-end developer and as someone affected by a front-end developer.
Just weird to do things one way and then get upset about it. If there's a better way do it that way. That's why levels.io guy is cool. He just walks the walk.
I had been programming for about 30 years, I loved it and was excited by it. After work I would go home and work on side projects.
React single-handily killed it. It encouraged, usually required, all of the awful design patterns I used to chase all the junior engineers and interns about. This has become endemic in the JS world.
Here's an example: did you know that the uuid npm used Math.random up through 2020 (v.7)? Cryptographically secure random number generation had been available in basically all browsers since 2011. 9 years. If I had an engineer submit that code, I'd rake them over the coals.
Speaking of that, I'd usually need a half-time engineer on larger projects just for the management of the complexity. All of the various frameworks and updates and breaking changes. It was a 20/hour a week job just to stay on top of things. For instance, koajs.
It's a bunch of dependency code of quality I would never let fly, but now I have to use it and grow my team, increase budget, push back deadlines - all to manage the piles. No thanks.
I left that job, quit the industry entirely about 2 1/2 years ago. Reactjs was such atrocious self-aggrandizing bullshit, it made me quit programming. It's fragile, over-engineered, mostly broken, confused poorly defined amorphous concepts that poorly solve mostly imagined problems and the entire industry of front-end is eating up that mode of design like it's some sacred text.
They'll use abstract buzzword concepts that have different conflicting definitions in basically every text you pick up, and they'll never concretely define them but continue to use them as abstract amorphous blobs.
I've got very popular front-end projects. I've been at the C-level of more than one company that sold based on front-end design. The first professional javascript based web app I did was in 1997. I deployed Server Side JavaScript (SSJS)/LiveWire in the 90s, a decade before Node ever existed. I've been at this for a long, long time.
After dealing with react, I never want to touch that stuff again.
We could waste each others time getting into the specifics but I can summarize it.
It has affordances and design patterns that inexperienced, new, novice programmers find attractive and tempting but comes with all of the warts and issues surrounding intuitive patterns. That's why it takes over 10 years to get good at programming - counterintuitive insights are the clarifying beacons on any sufficiently complex project.
People are "react programmers" instead of actually understanding the specs, standards, javascript, protocols or how things actually work.
It's about 100 times easier to find a mediocre junior programmer than a comptent one. React allows, at a great cost of time, resources, and money, a large team of mediocre junior programmers to eventually create what once required a competent engineer and that is why it's popular.
Your offshore outsourced $15/hr programming firm can now make a half-assed website or app and you don't actually need to find someone who knows what they are doing.
If you've actually worked in the industry, actually dealt with code, been put on projects that are off the rails, you know this is true. You know this is exactly what is happening.
Then management is unwilling to pony up the $250k to attract the right talent so you get stuck with the job of making heroic efforts to prevent the house of spaghetti from collapsing.
You've been there. You've done this. You know exactly what I'm talking about.
This is perhaps my least favorite reasoning: you're holding it wrong. There will always be organization issues. Conways Law exists. The tooling matters because it encourages or is ergonomic in certain ways.
I hear this in my circles around Python which encourages spaghetti code and reaching into private parts of other's code. Yes, you can prevent this with better libs/modules, solid leadership and a steadfast resolve with adequate tooling. Or you can use a tool that makes spaghetti harder to write and pick something like .net or Go.
There's an extension to this - a codependency. The system imposes structure back up the chain.
These choices can become good organizational fits because they reflect the separation of concerns of a project decided by management. It's almost invariably a management that doesn't know how to code or build software.
I will give you this: The emergence of mature powerful web browsers made it possible to move a lot of functionality to the end-user's device and that gave raise to the frontend / backend developer split. But you are pointing to a specific frontend technology (react) and that is not the culprit here.
It was the "view as a (pure) function of your model" approach that was architecturally new in react.
This article explains it using a bit of react jargon (action, store, dispatcher) which is kind of unnecessary - but that's what I got from a quick google:
That seems like kind of an overreaction. Sure, the first time I saw React I also thought it was an abomination.
But in the end it’s fine. Different, sure, but there really is something to using the same language on both front and back-end, and not having to wonder about how to reconcilliate data and markup.
React and the whole ecosystem gives you a thousand extra problems to care about, but it also takes a ton of them go away. It makes the simple things annoying but the hard things also merely annoying.
It's a sincere reaction and I'm making myself emotionally vulnerable by putting it out there.
I know that's forbidden on the Internet but I'm still deeply passionate about building good software and I'm just so disappointed by the precipitous decline in quality that's plagued the industry despite the increase budget and manpower dedicated to it.
It's inescapably the tools and methods. This ought to be the golden age. Things ought to be great. But they're terrible. Everything has been getting slower buggier and shittier. It's become more complicated while doing less. It's awful.
You mentioned you're passionate about good tooling, would you mind if I asked you what your thoughts are on Glamorous Toolkit[1] and how it compares to other tooling you've seen?
There's so many wonderful and exciting things going on in this space right now. It's hard to keep up with them. They all take 100s of hours to get half-way decent at.
Really, FWIW, the things I need are:
1. Introspection tools to find out what's going on without having to rewrite the build system.
2. Comprehension and navigation tools (like copilot) that I can interface with and give insight into where things might be happening
3. Timeline tools like rr
4. Advanced diagnotistic tools like ebpf
And that's really it. emacs and vscode are the things I cycle around. I still think these are all open problems.
Pretend I'm a person who agrees with you about React (I might be, after all[1]).
Have you ever seen that page "You might not need Jquery"? Can you please write a similar blog post (or even put it into a comment here so that I can bookmark it) titled "You Might Not Need React"?
I want to know what it is that React gives (maybe)millions of developers that you don't need.
All those things that React is commonly used for: what are you using instead? Show snippets, please.
So, yeah, throw me a bone here, please write "You Might Not Need React", because I can guarantee you that there are numerous devs who want to read such a post.
Pretty please.
[1] I looked at the React tech stack and learning curve for someone who only knows HTML, CSS and Javascript out of the entire web-stack, and noped right out of it.
It does take longer to learn and require more intellectual rigor to do things this way but you also get 10 year solutions instead of 10-month ones and things are way easier to debug, pivot, modify, repurpose, support, All the long-term things you have to do after the act of building when people are actually using the thing. Those are now easier
It doesn't need to be as polished as that, I just want to see <this is what react lets you do>:<this is how you'd do it without react>, even if all the "this"es in there were just patterns.
I just want to be clear here, I'm not engaging in bad faith, or trying to prove something. I truly just want to know what react code is commonly used for, and what a vanilla solution would look like.
It's hard because it's conceptually and fundamentally different.
Like what about useEffect? There's many many terse ways to implement this that in practice do the same things but in a slightly, arguably inconsequentially different kind of way.
I'm sure there's a large legion of pedants out there who would have a field day slapping their suspenders against their chests nitpicking how "not exactly!" the alternatives are.
If we can somehow avoid that trolly bullshit then I'm game.
I have to do "real" ssr every once in a while via the django jinja html files we have to send emails. It makes me want to die coming from our nice typescript react SPA frontend. Every object is a mystery and jinja syntax is functional but terrible to maintain and of course you're suddenly using tables because it's an email.
I'd rather every element be a div than do one minute of editing those stupid jinja files.
It sounds like your issue is with the syntax of Jinja, and the hellscape of HTML email. I'm not sure how 20 MB of inscrutable JavaScript would help, considering it's also just template rendering with extra steps (bonus: using the user's CPU cycles and power instead of your own).
> It sounds like your issue is with the syntax of Jinja, and the hellscape of HTML email. I'm not sure how 20 MB of inscrutable JavaScript would help, considering it's also just template rendering with extra steps
20MB of inscrutable JavaScript allows you to have a) a sane structured component system where you can actually build up UIs compositionally rather than a flat glorified string substituter (i.e. not actually "just template rendering"), and b) the control and abstractions needed to make good UIs out of nested tables.
> you can compose UI on the backend without string substituting.
Sure, but you're still going to be using "20 MB of inscrutable JavaScript". (Unless you use Wicket, but I'm not sure that's an option for emails, and would likely trigger the same complaints anyway). I mean, I hope you're not using the component style rendering layer for Python that I published ~10 years ago, because I haven't maintained it, and as far as I know there aren't any others.
As a home assistant user, jinja in yaml files is hot steaming ass.
Every time I read the jinja manual I want to cry. And a small part of me dies in side. It's like a templating language designed to get even with the person who microwave a tuna fish sandwich in the office, for lunch, daily... That some how leaked out to the web.
There are different template engines for SSR, with drastically different syntax. I've never written any Python, but in my own opinion, Smarty for PHP and Twig-compatible ones for many different languages are the best.
While generating any moderately complex HTML on the front end is a pain in the ass for me. I prefer avoiding it. If I need to request some data from the server to dynamically update the page with, I just make that endpoint return some server-side-rendered HTML that I insert wherever it needs to go.
This rant is missing the WHY in every section. While it has some valid points, it will unfortunately only satisfy those who are already in the same boat.
The rest of us will keep wondering why he implicitly assumes that backend generated with js is sooo much worse than if was generated with anything else. I've also written my fair share of PHP before AJAX was even a word, plus lots of ASP.NET, Java and Python backends. Honestly, their templating languages all suck, compared to React components that are type safe and infinitely easier to compose and refactor (jinja anyone?). While their languages and ecosystems are a lot more powerful, JS these days isn't that terrible as a language, just keep a tight grip on your package.json.
It is correct that there is something wrong with the culture of the front-end development, in that there seem to be no brakes on just piling crap on the next shiny thing and then building even more packages and abstractions around it, instead of fixing the underlying crap in the first place.
Ranting is easy. It's nice to vent once in a while, but then what? All that remains is that the author is fed up with tools that don't solve his problems. Ok?
The key difference between the web and any other type of development, is that you can distribute almost any type of application with the push of a button to billions of people, without the need to install anything. This is a superpower which _ofcourse_ comes with some complexity. Sometimes when you don't need that superpower and you have to navigate the complexity anyways it will be a frustrating experience, but that doesn't mean there is something fundamentally wrong or anything.
The author makes a few good points but on average sounds like an old man complaining about everything. There is a reason React took off, and there is a reason people choose React.
Sure, if you are building a simple content heavy front-end, it doesn't make sense to chose a React framework or React at all. But many apps today come with heavy front-end interactions and have to sync with their back-end in real time. Good luck doing that with jQuery Ajax.
And you can't blame the bootcampers. They were promised riches after a 6 months bootcamp. They were taught React and had little interactions with HTML. So they are doing what anyone else in their position will have done. So when they were out in the market, then React is was. Suddenly, everything became a React component; and if you made a website today, you'd better off start with React.
In defense of React/NextJs: I have been blogging for 10+ years. I started by using WordPress. I have constantly failed to maintain a server up and running for more than a year. There is always something that comes up. A bad WordPress update, DB goes wrong, a failed payment, a bad WordPress plugin update, Server goes down because?, etc...
5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github. Not sure I'd say the same about WordPress.
> There is a reason React took off, and there is a reason people choose React.
Sure, there's a reason. Doesn't mean it's a good one :-/
> 5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github. Not sure I'd say the same about WordPress.
Is 5 years considered a long time? Is that the bar? Because >6 years ago I wrote an internal site/app in C# using Jquery for front-end, and that is still up, working and being used by a few thousand people daily. It's even being extended every now and then.
No NPM, no React, no Vue, no Next, no front-end build step.
I coded this one for a friend more than 6 years ago: https://designed.space
It runs on a basic LEMP stack (or rather a LEP since it's a file based cms) on a VPS I have not touched in years. The stack is outdated, the CMS is outdated. It runs just fine with no issues.
I can move it to an up to date VPS and port it to a recent version of the CMS in a couple of hours and it would then be fine for probably another 6 or 7 years.
> 5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github.
Now try actually checking out the code and building it. I’m sure there is some Node.js runtime feature that is no longer supported in the LTS version you currently have installed on your notebook.
For more than a decade, worked with many large Single page applications (SPAs) across startups and large companies.
He has some good points regarding SASS. Other bits were about ranting.
The issue with frontend dev is there is a gajillion bootcamps promoting it so we have a bell curve weighted heavily weighted towards juniors.
Add in browser compatibility issues, framework churn and other headaches, there are fewer highly experienced FE devs who understand the browser in a deep way.
FE code also tends to be highly stateful. Managing state well is one of the harder FE problems that few folks talk about.
Add in the mix that some are apps and some are websites. There is no one right answer.
If you want to reduce maintenance costs, reduce the amount of Javascript code and tooling.
NPM-Javascript is a shitshow of constant breaking changes left and right, whether it is in your runtime framework, or your build system like gulp or more prominently webpack.
Try maintaining 10 projects with these frameworks. You'll quickly look for something that is not as maintenance intensive.
Example: No, you can't stay on Webpack version X, because (real example) it turned out that version of webpack relied on md5 which wouldn't work in newer node.js versions.
Arguably, for SPAs it doesn't matter what tags you use at all. Whatever you do is going to be inaccessible. Make everything a div. Who cares? We used to write all the UI components ourselves in Flash or Java.
Sure, yes, understand the content that you're writing your UI around, and make the UI serve the content. That just begs the question of why one would get anal about which HTML5 tags are used for headers or navs or buttons.
Yeah, not only this article doesn't mention whether he slings around his own library or uses a less insane JS blob like jquery, alpine, htmx or hyperscript, he laments essentially that foundations for big webapps and cookie-cutter shit turnkey products are sold for small operations and static websites. In a lot of parts of this rant I couldn't abstain myself from thinking that he wants a web for documents and the web for applications swung around a lot of very bad habits and useless complexity in the field while waiting for wasm, aka "New Applet" to be production-ready.
i cant count the number of times i've had to generate boilerplate + interfaces etc etc for something that would be as simple as an onclick (onClick?) handler would have done. i have yet to actualize the serious promises of this ecosystem in any meaningful way and it doesn't seem to get better. also jsx is ugly.
sure the browser accommodates. now how about dealing with wrapping everything in unnecessary empty tags and tree shaking and bloat etc. specialized dev inspector tools for each framework etc. there are layers...
there is. there is a build system. there are probably some typescript interfaces and lint checks you need to pass etc probably some other framework you need to familiarize yourself with if you are data binding etc. i'm not saying any of this is inherently bad - what im saying is 99% of the time this is overkill
I agree with a lot of this rant, but life is too short to care about `<section>`, `<header>`, and most other tags. If your content is highly legible to users—especially if they use assistive technologies—then it simply should not matter. The CSS Zen Garden is dead and it's time to till it and start over.
Semantic content is also about being legible for computers though.
Even though it looks good to users, some might also care about it being defined well for machines and automated processes.
FWIW, Google explicitly says it mostly ignores semantic HTML [0]:
> Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.
And a typical business web page likely won't have many "automated processes" it wants to accommodate except for search engine crawlers.
Well, I'm inclined to interpret "Google Search can rarely depend on semantic meanings hidden in the HTML specification" as meaning exactly what it says. After all, Google's own pages are made of <div>-soup, so I'd hardly imagine that they discriminate against it in others' pages.
Unless you have explicit statements or hard evidence to the contrary?
I think the idea is that the tags and the aria roles make it more legible to users using assistive technologies. For a significant number of aria roles, e.g. article, the recommended way to get that role is to use the corresponding HTML element. <section> is just a generic element but <header> has a banner role. Now admittedly there are a lot of HTML elements and a lot of aria roles, and I am not sure screen readers actually have different behavior for every role, but just by making a reasonable stab at it, you are doing better than many major corporations. (some of which have been sued over accessibility concerns)
IMO it's fair to say to colleagues that you're free to use any HTML tags as long as you take responsibility for them by knowing all of their idiosyncrasies.
Nope, that results in significant extra complexity because now you have to implement all the stuff that the browser does for the other tags so that your website works the way people expect. (and you will get it wrong)
Unfortunately you can't draw a table of number using just divs. It's just too slow and your users will notice. For tables of data, you have to use tables.
You can, you just have to set their "display" properties [0] to "table", "table-row", etc. The whole point of CSS is to divorce styling from the particular HTML tags.
Cost vs. benefit. If the ARIA roles are all in order (which can admittedly be a pretty big "if"), there's no user-facing benefit to semantic HTML over arbitrary HTML with the same style.
The "cost" in many of these front-end frameworks is having to manage HTML tags at all, instead of generating them automatically from some higher-level specification.
Also, you have to remember whether any of them might have a different default style in the browser than what you'd get from a regular div/span.
Is that really a thing? I’m genuinely asking because I have zero experience with this type of setups since I don’t need to use them and prefer to work in other ways.
The idea behind frameworks like Flutter and React Native is that you can specify the document as a tree of high-level components, which can then be rendered either as a web page or as a mobile app. In that case, there's simply no equivalent to the semantic HTML tags on the other platforms, so you'd end up with a big impedance mismatch if you tried to force them in there. (Though of course, such tools are definitely targets of OP's derision.)
None, unless you (or your team) is already familiar with it, I'd imagine. I think some (like Flutter) are designed to have similar markup regardless of which or how many platforms a particular project uses.
But don't take my word on any specific examples, I don't have any real experience outside of normal web React (which does give you full control over the HTML elements, except of course for third-party components).
Yo, they don't even have a table of contents element. How can you say you love semantic documents and not have table of contents. And no bibliography either.
No. That's just a nested ordered list. The difference that occurs when we all agree that it's also a ToC is night and day. You can also create custom elements, but again, if nobody has consensus on the meaning of those elements then they're just elements.
That means that as a client I am not empowered to automatically display your content in a new way.
A ToC is more important than a list and should build a graph to other parts of your document. If the only agreement we have is that something is a list, then we've reduced the semantic meaning of a list to the question of whether we should have visual signifiers like bullet points or numbers.
I want the niceness of Wikipedia generalized elsewhere but abstracted by my client or browser. The more we agree on the precise meaning of elements, the more we are empowered to programatically redesign or interact with content.
Screen readers actually do generate a couple of different things that you could consider a ToC from the semantic meaning of various tags. If you structure your document properly, it's not a terribly difficult task for the browser to generate it. Apple showed that Safari 18's reader mode is going to have one, actually.
i mostly agree with the rant, except for styling, i think tailwind is great.
nowadays i default to htmx, alpine, sqlite and typescript, recently i’ve been working on a framework/starter using these tools: https://www.plainweb.dev/
What a silly rant. There is a huge world of different approaches to front-end and lots of them do cool and interesting things that would both up your productivity and give you completely new opportunities ... if you bothered instead of just being an old fart.
It would be cool if all of the fancy front-end people would learn how to use HTML properly before lecturing the “old farts.” The <ol> example comes to mind.
The way some people code "HTML" these days is like an apprentice carpenter swaggering up to a house building site, and then banging in nails with the butt of their power-drill, and telling the "old fart" carpenters what losers they are for bothering to use a hammer.
Use the right tool for the job. HTML is a toolbox, not a bucket of <divs> and <spans>.
You can be old and experienced and still have an attitude of being open to new things ... at least to the point where you understand them before you embark on a rant.
I just want to say I like pre-rendering > server side. Because you get a lot of performance benefits while still writing in a client side style. It is a low hanging fruit though I suppose a combination with ssr would be better.
This article could use a LOT of source links. Not because I believe points are wrong, but because if the author wants to rant that no one knows/has heard of things, why would anyone know what they're talking about?
>The number of times I’ve seen numbers written inside of a <li> that’s inside of a <ul> — instead of just using an <ol> — is deeply disturbing.
I've been reading and writing HTML since the 90s and off the top of my head can't recall ever seeing <ol>. Why is it better? For screen readers? A sentence to illustrate goes a long way.
Didn’t markdown come out in the early 2000s? So you’d have to try HARD to not see a <ol> especially because pre html5 there were even fewer tags available.
> <ol>. Why is it better? For screen readers? A sentence to illustrate goes a long way.
It's better because it means it's a list of something in order, as opposed to a definition list or an unordered list. The distinctions are important.
It means, for example, that you can meaningfully skip to the middle of an ordered list of the 100 tallest buildings, and be guaranteed to be looking at the 50th tallest building.
You're technically not guaranteed to have ordering. You can put an ordered list into any order you want. But semantically it indicates that the order of the list matters. I like the semantic model, but it can easily be abused and not mean anything at all.
The author writes >> I’ve seen numbers written inside of a <li> that’s inside of a <ul> — instead of just using an <ol>
An ordered list <ol> automatically adds a number to each list item indicating its position in the order in the list which would save developers the effort of adding code to insert numbers into ordinary list items in an unordered list.
What? How could you have been writing HTML since the 90s and not see all those examples of OLs with numbered items, including lowercase roman numerals or uppercase letters?
Somehow, even if I never used roman numerals, that example sticks in my head (esp the lowercase).
Anyway, if you cared deeply about content in the 90s, you might have focused on the semantic meaning behind tags (I've also looked a lot at other SGML and later XML based formats like TEI, DocBook...), tried to strictly decouple presentation (CSS) from the HTML (content), and be annoyed that the CSS box model never supported nice content-related flow features like TeX did since the 80s (and still doesn't).
Now, don't get me wrong, I wasn't some wizard — I was simply an easily impressed (with things having some meaning) high-schooler around that time :)
Yea I've been coding every framework under the sun since the 90s and I'm pretty happy with Next.js at the moment. It can render on the server and re-render on the client with the same framework, same language, same functions. Statically typed server to client and back to server. JSX/TSX has no strange template syntax and again static type checking. Compiling automatically tree shakes, bundles, code splits per route. I can do SSG, SSR, CSR, ISR. I can specify per route/api caching strategies. I can host serverless or self host. I'm knocking websites out left and right.
It feels like I'm building a single application not two separate frontend/backend applications; managing overhead rendering and communicating between them. Next.js, Nuxt, Remix, SvelteKit - are all part of this next generation batteries included frameworks that can seamlessly transition from server side rendering to client side interactivity.
I mean look at this unmanageable bug prone code from the blog post. Nothing here is safe, no way to validate the classes where the data is coming from/going to. No validation of the api or its parameters. If you scaled this example you'd end up with nightmare level code. Yea I've been there already, I'm not going back.
I agree with some of what the author is saying but add about 10 years of experience. Been coding sites since I was a kid in the mid 90s (I was a web master). I have 10 years working on brochure sites but have spent the last 10 working on major SaaS.
Few things I disagree with:
- The content rant was weird. I've always worked with content designers, instructional designers, or good marketing copy people. Was that about semantics? Sure ya, SEO and a11y.
- Cascading CSS is great until you write a million+ line SaaS app and have 1000 devs working on the code. Then you need scope. The rant is specific to brochure sites.
- SSR. Weird. Do devs really think that? I guess I'm out of touch or my colleagues are better than most.
- A lot of rants seem to be ripping of jr devs. Show them the way! Very yells at cloud.
- CSS nesting I really like. Example of nesting elements inside a class is a hack that should not be done. Nesting is easier to read if done properly.
SPA shouldn't be used for content heavy web pages anyway. SPAs today especially React were basically like Facebook's engineers decided to write js/css/html in the style of php.
Here’s practical experience from me running the tech side of a startup while sharing the author’s values.
Server-side rendering (the normal kind from 1990s):
1. It is glorious. Everything that 37signals has to say about it is true.
2. However. I really miss React-style components as an abstraction. There are many ways around it that we use depending on the case (plain CSS classes, our own tiny Go/HTML component library, HTML custom tags), but we’re yet to produce something as ergonomic for more complex compositions.
3. We’ve added Hotwired Turbo for smoother page updates. I find it’s a lot more orderly than htmx, but we do miss some things that htmx would offer.
CSS:
1. We started out with just plain CSS, using BEM and CUBE to structure it and manage complexity.
2. That still got us questioning the DIY nature of the U (utilities) part of CUBE — it got increasingly complex and random, and really just like every program grows a broken LISP interpreter inside, every custom CSS utilities library grows a broken copy of Tailwind inside. So we adopted the actual Tailwind for utilities. Tailwind is truly glorious, both for sheer productivity of writing the code, but also as a language for describing styling at just the right amount of detail — more powerful than CSS properties alone (hover:color-red-700, disabled:cursor-default), but more constrained than full CSS.
3. Tailwind introduces a build step, though, which sucks (and slows down the build by the whole second! My m2 Air can probably do a 60s supercomputer-level nuclear explosion simulation during that time.) Thankfully, part of our startup is doing custom themes for each client, for which actual Tailwind sucks even more (themes are edited at runtime, and you wouldn’t want to run actual Tailwind with its million Node dependencies on your server), so we’ve implemented a subset of Tailwind in Go, just the things we actually used, and it runs at runtime, eliminating any build steps for themes.
4. Bottom line: Tailwind is absolutely glorious as a shared design vocabulary. Non-tech people were able to adopt it and handle theming thanks to it. The actual implementation of Tailwind seems unacceptably slow, but I hear a Rust compiler is coming.
JavaScript:
1. Plain old JavaScript is great, but needs some structure. We found that structure in Hotwired Stimulus, which we absolutely love.
2. But again, I do feel the desire for React-style rendering occasionally. We embed our widgets on customers’ e-commerce sites, and a chunk of HTML rendered based purely on data coming from an API with live updates is a perfect case for React.
3. Needless to say, running code on other people’s e-commerce sites is where I would never dare use a React-based stack, because I’d spend the rest of my life doing due diligence on the dependencies. (Our competitors are much less responsible about this, and it works out for them too, so this is more of a principles thing.)
4. This is probably the case where an in-house 500-line implementation of React-style rendering would be preferable to anything else. We already have a 100-line version, but it lacks many desirable features.
Bottom line: Yes, you can (and should) run a modern startup based on a pragmatic server-side rendered stack, but you definitely want to add just a few modern things: something like Hotwired, something like Tailwind, some solution for more powerful components in your templates, and something like Preact for certain use cases.
That was the first article written like that I've read in a long time, and I enjoyed it, and laughed at some of it, and the topic certainly resonates with me.
Tend to agree. The “piledrive” article yesterday was the same. It’s not that the author didn’t have good points, and it’s not that I even mind profanity. I just think the shocking language is a stand-in for a stronger argument.
In 2001 the EU switched (mostly) from a local currency to the euro. For years people would calculate prices back to the currency of old. If you do it nowadays, over 2 decades later, people look at you funny.
People who still rant about the simplicity of jQuery are of the same cloth.
Except that unification did give enormous benefits, it allowed those countries to trade more freely. The horribly inefficient JS-ass 5-megabyte-bundle SPA blogs benefit no one in the long run.
By the way, on my recent visit to Europe, there still was a total in francs "for information" on the receipt from a random grocery store in Paris.
> By the way, on my recent visit to Europe, there still was a total in francs "for information" on the receipt from a random grocery store in Paris.
As an european: that's a problem. Why? Inflation. People who still change regularly to the old currency only do so for some of their finances AND romanticise the past.
Wow, I think this is the first time I've seen a page be wrong about so many things at once. No, the difference between header and section or p and div is not important (after you started off so promisingly by saying that content is what's important - the difference between a p and a div is not content). No, CSS really is the problem. No, you can't actually do server-side rendering in a different technology stack if you want the term "rendering" to mean anything (as much as semantic arguments are pointless in any case). Yes, JavaScript is actually the least-bad solution to every problem in web space; it's not ideal but it's a proper programming language that isn't completely nutso (just mostly nutso), which is more than you can say about CSS or HTML.
If you actually want your life to be simpler, use React for everything, like everyone else. Stop worrying about how many dependencies you have and wasting your time reimplementing them worse.
Screen readers and other assistive technology fully expects your HTML to be semantic. It doesn’t always matter, but it matters often enough.
CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything.
If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier.
JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time. I’ve seen people essentially re-implement default <form> behaviour too many times to count, and spend time looking for solutions to problems they only have because they insist on using technology for making interactive sites when they’re making something largely static.
If you want a simpler life, choose the simplest technology that will solve your problem.
> Screen readers and other assistive technology fully expects your HTML to be semantic.
No they don't. They were developed to work on the web as it existed at the time and handle it fine. A screenreader doesn't magically do something different and better with an <em> tag than a <b> tag, and only confused thinking and propaganda has made people think so. (And anyone who actually cared enough to test with a screenreader would know this - but people don't actually care about screenreaders, they just use them as a stick to beat technologies they don't like)
> CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything.
> If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier.
You still need class names, because you're always going to have some distinctions that matter in your domain but can't be mapped onto the fixed list of HTML tags. So either you use divs and class names for everything, or you use a mix of tags and use a mix of class names and tag names, which just ends up being less consistent and more confusing.
You have components that are shared between pages, so you either have to include all your CSS on every page, you manually figure out which components are used on which pages and make mistakes sometimes (leaving you with missing styles), or you use a Javascript UI framework.
> JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time.
I find the opposite. You're always going to need JavaScript eventually. Trying to do stuff with CSS and HTML tags just wastes your time and the end result ends up being more complicated because it's a mishmash of both. If you use a well-known JavaScript UI framework from day 1, it's so much easier to end up with a simple, consistent, maintainable site.
They do. They use tags and semantic structure to figure out what to read when.
You also skipped the "and other assistive technology" part of my sentence. Tools for navigating, or alternative rendering, improves when your site is semantic.
I use these tools every now and again, I'm not basing this on theory.
> You still need class names,
Not as many. If you use divs and classes everywhere, you end up using classes for semantic meaning.
> You have components that are shared between pages, so you either have to include all your CSS on every page
Use classless CSS as far as you can, use site-specific (layout) stylesheets, and use webcomponents for those components that are truly novel. Webcomponents with shadow dom means it can include it's own stylesheet without affecting the rest of the site.
In many cases, you get by with just classless CSS. Site-specific layout is a one-liner. Webcomponents bring their own styles.
So no, you don't need to bring an entire JS UI framework for this.
> You're always going to need JavaScript eventually
Depends entirely on what you're building, and a lot of the time you can get away with something simple like HTMX and JQuery.
But even if you do end up needing a JS framework for some portion of your site, limiting the amount of stuff that needs to be handled by this framework _greatly_ reduces the amount of complexity, and amount of code, that the developer has to write.
> If you use divs and classes everywhere, you end up using classes for semantic meaning.
You're always going to use classes for semantic meaning anyway, because the HTML standard doesn't and can't define all the semantic distinctions that will be relevant in what you're making.
> use webcomponents for those components that are truly novel. Webcomponents with shadow dom means it can include it's own stylesheet without affecting the rest of the site.
I guarantee you the author of this rant hates webcomponents even more than they hate Javascript. (Indeed I'm pretty sure they qualify as a "JS UI framework").
> But even if you do end up needing a JS framework for some portion of your site, limiting the amount of stuff that needs to be handled by this framework _greatly_ reduces the amount of complexity, and amount of code, that the developer has to write.
You can draw an arbitrary line and say JS is "code" and HTML and CSS are "not code", but that doesn't actually make them any simpler to understand. Expressing your whole site in the same framework used the same way results in something that's much easier to read and maintain.
Everything you just wrote is either wrong or even exactly the opposite.
The author of the article might be blunt and you might not like that in your mind things seem different, but the problems he highlights are real.
On the contrary. The reason front-end development is so much worse than regular development is some bizarre collective fetish for avoiding Javascript, avoiding dependencies, and writing ad hoc, informally-specified, bug-ridden, slow implementations of half of React. It's some kind of Luddism meets Protestant work ethic nonsense, and I'm continually baffled that otherwise intelligent people - people who would never have this kind of attitude in regular programming - keep falling into it.
I would love to see a list of projects that do less of the front-end garbage. Someone mentioned the levels.io guy. I also like HTMX. Personally, I've seen great success using 95% server-side rendered sites with 5% Alpine JS sprinkled on top.