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.
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.