Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

It's time for modern CSS to kill the SPA

jonoalderson.com

Post reply on HN
Print view View original

451–460 of 516 posts

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

#451

Post by zwnow »

esskay wrote: post #397
zwnow wrote: post #316

Earlier quoted context omitted.

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

What 'other' templating thing? I'm assuming you're likely talking about either Intertia or Livewire. Inertia's more geared towards SPAs than Livewire though. Most Laravel devs tend to use JS sparingly - not everything needs JS. Theres next to no reason why the vast majority of sites on the web would ever need to be heavily reliant on JS. Rendered HTML/CSS with JS being used sparingly for page functionality is a far b…

Yea Livewire, couldn't think of the name.

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

#452

Post by zwnow »

brigandish wrote: post #377
zwnow wrote: post #316

Earlier quoted context omitted.

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?

Interactivity and a way to build experiences and applications. Not just passing documents back and forth

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

#453

Post by dzhiurgis »

da_chicken wrote: post #372
dzhiurgis wrote: post #312

Earlier quoted context omitted.

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.

When you posit like that makes me think doordash shouldn’t be an app at first place.

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

#454

Post by DangitBobby »

al_borland wrote: post #298
Quarrel wrote: post #281

Earlier quoted context omitted.

> They are either the worst developers in the world or it is not simple. Or they have a good reason to not do it (in some PMs mind). At a guess, resetting the view, and displaying the nearest Domino's Pizza sponsored highlight pin on the map, could be one of them.

My biggest gripe with Google Maps is when I pan to a specific area, hundreds, or even thousands of miles from my current location, then search for something like “restaurants” and it pans me back home and searches there, so I then have to go find my distant location again and click the search here button. If this is an intentional choice, all in an effort to show me more local ads… ugh. I really hope this isn’t the c…

Google Maps makes it really hard to explore your travel destination, or I am holding it wrong. That and the lack of weather integration are my main issues with it.

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

#455

Post by wild_egg »

8n4vidtmkvmk wrote: post #228
wild_egg wrote: post #137

Earlier quoted context omitted.

> in exchange for having really small network requests after the load. I'd love to see examples of where this is actually the case and it's drastically different from just sending HTML on the wire. Most SPAs I've worked on/with end up making dozens of large calls after loading and are far far slower than just sending the equivalent final HTML across from the start. And you can't say that JSON magically compresses som…

With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, but I don't have stats to back that up.

> I don't have stats to back that up.

Your comment then falls under my "superstition" label.

My experience has been that the HTML version will send overall less data since it contains precisely what is required by the UI and nothing more. The JSON APIs try to be "generic" across clients and either send more than the client needs or send less and cause the client to wait on a waterfall of requests to load everything.

You should always run benchmarks for your use case but the majority of web projects are not Figma or AutoCAD and benefit drastically from simpler approaches. A single compressed HTML response will beat a cascade of JSON ones every time.

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

#456

Post by nfw2 »

bob1029 wrote: post #374
unchar1 wrote: post #267

Earlier quoted context omitted.

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…

Every single action should have no perceivable latency between the action and the feedback that the action was received. You can implement that with SSR but it is clunky and also requires a lot of JS generally.

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

#457

Post by nfw2 »

romanovcode wrote: post #276
nfw2 wrote: post #180

Earlier quoted context omitted.

Performance, developer experience, user experience

Developer experience - Yes, in most cases. Performance - No, in most cases. User experience - No, in most cases. What are you talking about. Majority of SPAs have abysmal performance compared to regular HTML rendered websites and that reflects poorly on user experiences.

Performance - For pages that have different content for every user, the best performance will be reached by caching the app code on the client, only loading the data needed to render, and rendering once on the client. Rendering on an aws machine that is weaker than my 15 year old macbook is not a recipe for good performance.

User Experience - Every single user action should have no perceptible latency between the action and the feedback that that the action was received. This can't be done gracefully without javascript. Moreover, SPAs enable a better ux by enabling developers to build complex features that wouldn't be possible on traditional webpage.

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

#458

Post by brulard »

threatofrain wrote: post #448
brulard wrote: post #447

Earlier quoted context omitted.

By your logic PHP and Java won the programming language war. And according to github stars, (which may be considered rough measure of overall usage, not of current trend) next.js has 4x more than remix. So if your sw consultancy is one fourth size of Microsoft, you are close to a trillion dollar business. Even if you exagerrated by few orders of magnitude, thats still very big achievement, so congrats.

https://npmtrends.com/next-vs-nuxt-vs-remix Also look at trajectory. Oh my, don't you think? When I choose things like Tanstack Start, I am very clear that this is beta software and an early bet. When I'm talking about winners in the ecosystem, I am not going to bring up Tanstack and most definitely not Remix. I don't want to confuse people into thinking they belong on the same table of discussion for ecosystem winne…

Your information are outdated. Let me correct your chart a little https://npmtrends.com/next-vs-nuxt-vs-react-router-vs-remix

Remix no longer exists as it was all migrated to react-router. react-router v7 is what remix v3 should have been.

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

#459

Post by 8n4vidtmkvmk »

wild_egg wrote: post #455
8n4vidtmkvmk wrote: post #228

Earlier quoted context omitted.

With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, but I don't have stats to back that up.

> I don't have stats to back that up. Your comment then falls under my "superstition" label. My experience has been that the HTML version will send overall less data since it contains precisely what is required by the UI and nothing more. The JSON APIs try to be "generic" across clients and either send more than the client needs or send less and cause the client to wait on a waterfall of requests to load everything.…

For first load, yes. The idea is that you never have to send the template again after that.

Cascading is a separate problem. You can bundle all the data into a single request if you want.

You can even send JSON along with the HTML in the first request.

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

#460

Post by 8n4vidtmkvmk »

goatlover wrote: post #367
8n4vidtmkvmk wrote: post #228

Earlier quoted context omitted.

With HTML you have to send both the template and the data. With json, it's just the data. So it's less information total. It should compress a little better, but I don't have stats to back that up.

Do browsers have trouble loading and rendering HTML in 2025? Page load should be blazing fast if it's not loaded down with a bunch of other stuff that hasn't already been cached.

They don't. The reason to do it is not to save bytes, but because you have a dynamic page that needs to respond to the user without doing a full page refresh on every minor interaction.
Post reply on HN