Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

371–380 of 516 posts

Re: It's time for modern CSS to kill the SPA

#371

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolu…

Not sure what kind of clients you work with, but in my experience this is actually accurate and you won’t believe how many times I had to put my hands and fix SPAs that should have been a static website to begin with. I think this is a consequence of a generation of webdevs, especially front-end, that graduated from bootcamps teaching them only JS frameworks and React as if that’s the only way the Web works. They were given a hammer, told how to use it, and everything then just looks like a nail.

Re: It's time for modern CSS to kill the SPA

#372

Earlier quoted context omitted.

How is HN not an app? All the content is user generated. Everything is interactive. What's the difference?

Most of the time spent is content consumption (viewing html documents), rather interaction (which is only 2 simple actions).

Navigating to a thread isn't much different than navigating to a store.

Upvoting isn't much different than adding to the cart.

Payment isn't much different than adding a comment.

I think the interaction levels are incredibly similar. The primary difference is the amount of images displayed, but that really isn't a significant aspect of web design or Internet traffic in 2025.

Re: It's time for modern CSS to kill the SPA

#373
"It’s faster, simpler, and better for everyone."

For who? In the modern day and age most devices can handle some JavaScript just fine. The DX provided by front end frameworks/libs is just unrivaled. Vanilla JS/jQuery work fine for small stuff, things quickly get out of hand in complex projects, when you have to bake in things like UX, validations, and have to program around the limitations of HTML. I'm confused as to why make such a claim as "Don't do SPAs for websites" and then throw in a dumb broad statement like "Just do vanilla". Yes, you can use CSS and achieve a lot of complex functionality. Yes you can use the existing HTML tags for a lot of things. Is it more maintainable than just using React? No.

You can't live in a silo. Yes, if plain HTML works for your website, why bother with anything else? Just do forms for any submit, input validation, there you go. But for a company competitive in the industry, particularly B2C SaaS, UI/UX does matter. And lagging behind, more than a trend, means customer perception.

We tend to be biased in our takes as tech-literate people (I do), but the average person gets lost if a button isn't emphasized enough.

Re: It's time for modern CSS to kill the SPA

#374
post #234

Earlier quoted context omitted.

I'm sorry but what!? Have you talked to your users? The ones that actually are forced to use your app day in and out? They want functional back buttons, they want to be able to open any action in a new tab. No one who actually uses your product would prefer an SPA once the flash wears off. Let me tell you as a developer who has been on both sides of things, developing server rendered pages and not having to worry abo…

We did an A/B test of an old SPA app, and a modern re-write using SSR and server-rendered pages. By every performance metric, the new app was faster. But we kept getting user feedback that the new site was "clunky" and "slow", even though we saw that the p90 was much lower on the new site. Most of our users asked us to enable a toggle to let them go back to the old "fast" site. I'm not sure if this is a universal exp…

SSR can feel worse than SPA if you don't get the end-to-end latency under a certain threshold. If your SSR pages are taking upward of 100ms to render on average, it's going to start to feel like shit once you factor in the network latency.

My design goal for modern SSR pages is 500 microseconds render time on the server. A modern CPU can crank through several gigabytes of UTF8 text per second. There really isn't any excuse from a technology perspective. SSR pages being perceived as clunky & slow boils down to a skill / people / organizational problem. The computers and associated networks can definitely do it well.

Re: It's time for modern CSS to kill the SPA

#375

Earlier quoted context omitted.

Laravel is fine. It's not amazing . Like most "Modern PHP" it exhibits a Java fetish and when used carelessly can degrade into an upside-down impression of Enterprise J2EE patterns (but with an almost non-existent type system). What I find interesting though is the assumption that web dev is done by "JavaScript people", that even the best "JavaScript people" have no technical breadth, and therefore fester in a cesspo…

It’s connected with the questions around occupational licensing of programmers, unions, and similar structures which would not be so much about getting paid more but about getting quality up, squashing bullshit, and getting our quality of life up. Without a cohesive community, mutual respect, and recognition of a shared body of knowledge, we don’t have the solidarity to make it happen. As for Laravel, I’d say people…

> The OG web was missing a few things. Forms were usually written on one HTML page and received by a separate cgi-script. To redraw the form in case of errors you need one script that draws the form and draws the response and a router that choose which one to draw

Yes, I was there, I wrote and used these pages. It sucked. Things are better now.

> So the knowledge to build the form applications we were building in 1999 is lost like the knowledge of how the pyramids were built.

Building a form with zero user affordances is not difficult. It just isn't good.

We absolutely know how the pyramids were built. You get a whole bunch of humans to move a very large amount of stone and then stack it up in a big pile. The reason nobody builds pyramids today is because we have better alternatives.

Re: It's time for modern CSS to kill the SPA

#376

SPAs make sense when your users have long sessions in your app. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load. Smooth transitions are a nice side effect, but not the reason for an SPA. The core argument of the article, that client-side routing is a solution for page transitions, is a complete misunderstanding of what problems SPAs solve. So absolu…

This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never rea…

> Non-JS developers mystified and irritated at a bunch of practices they've never really internalised

My current explanation goes something like this:

"I'm a smart guy. Front end development looks simple. If I find it hard to do, that must be the fault of javascript somehow"

Re: It's time for modern CSS to kill the SPA

#377
post #316

Earlier quoted context omitted.

You miss the whole point and the author is correct about this: Modern CSS is powerful, and HTML is the way to deliver web content. Every web framework is _literally_ a hack to make the web something it isn’t. People who haven’t seen the evolution often pick up the bad habits as best practice. For thise JavaScript people, I recommend trying Laravel or Ruby/Rails. And then once you realize that JavaScript sucks you’ll…

Even with Laravel you will write lots of Javascript unless you go for blade templates or that other templating thing. Javascript is also great for making the web interactive. Maybe the sheer amount of SPAs out there shows us what we really want from the web. Most things ppl use in their day to day life cant be built with HTML and CSS only

> Maybe the sheer amount of SPAs out there shows us what we really want from the web.

A distribution and installation system that works on almost any device?

Re: It's time for modern CSS to kill the SPA

#378
post #359

Earlier quoted context omitted.

This article is full of misrepresentations and lazy takes. The author has had other anti-JS polemics widely upvoted on HN, which were just as carelessly written. But people upvote it anyway. What is the cause of this? 1. Bad experiences with JavaScript apps that have aggregated complexity (be it essential or incidental complexity)? 2. Non-JS developers mystified and irritated at a bunch of practices they've never rea…

I find myself agreeing with the article (although I also agree that it assumes you've chosen an SPA when you shouldn't have). To add my own perspective: I work on an app, the front-end of which essentially consists of 6 nav tabs, 3 of which show an index of records with corresponding add/edit forms. We don't have any hyper-fancy interactive components that would require heavy JS libraries. And yet... we develop in Re…

People absolutely use technologies poorly and make things harder than they should be.

At the same time, the part of the program that interfaces with the physical world (e.g., people) is always going to be far more complex and thus harder than the bits that get to live entirely inside the computer world.

Re: It's time for modern CSS to kill the SPA

#379

"It’s faster, simpler, and better for everyone." For who? In the modern day and age most devices can handle some JavaScript just fine. The DX provided by front end frameworks/libs is just unrivaled. Vanilla JS/jQuery work fine for small stuff, things quickly get out of hand in complex projects, when you have to bake in things like UX, validations, and have to program around the limitations of HTML. I'm confused as to…

A lot of website-in-spa break basic web stuff that simply works in old school HTML. It’s possible to do all that stuff correctly in react, but vast majority of people working on those simple websites seem to not give a damn.

Vast majority of information/portfolio websites have best UI/UX with classic HTML with some JavaScript sprinkled on top where it matters. Nothing says competitive-in-the-industry like contacts page that takes ages to load.

Re: It's time for modern CSS to kill the SPA

#380
> Native CSS transitions have quietly killed the strongest argument for client-side routing

Huh? We didn’t build my company’s product as a SPA because of transitions. We did so because it is a shared codebase with native and because it has an offline mode.

Post reply on HN