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.
The vast majority of websites out there probably don’t even need JS.
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.
JS doesn’t render anything. If you turn it off the page is served anyway, some minor things might not work.
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.
But I suspect that’s a pointless definition.
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.
https://developer.mozilla.org/en-US/docs/Web/HTML/Constraint...
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.
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.
Which makes Astro the wrong tool for the job, and SPA frameworks like Svelte the right tool for the job.
Doing these things server side makes no sense, it'd just make everything harder for me to debug!
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.
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.
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".
Parasites.
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.
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.
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 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.
SSR does this as well. The server serves data (HTML), the client (web browser) renders it.
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.
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.
edit: fixed a typo
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.
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
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.
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.
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.
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.
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.
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).
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 built something with it once. I wonder if it’s still in use.