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

341–350 of 516 posts

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

#341

Post by motorest »

cleoxjefbjxis wrote: post #303
zero_shift wrote: post #275

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…

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…

> You miss the whole point and the author is correct about this:

your comment is funny, because you are so wrong you aren't even aware how and why you are wrong. It's in "not even wrong" territory. I'll explain you why.

> Modern CSS is powerful, and HTML is the way to deliver web content.

Irrelevant. That's not why the world uses JavaScript frameworks. It seems you aren't even aware of the most basic reasons why the world migrated to SPAs. The most basic reasons are performance (and perceived performance), not only because the require less data to be moved around the internet but also every flow doesn't require full page reloads.

Also, classic old timey server-side rendered WebApps end up being far more complex to develop and maintain as you mix everything together and you are unable to have separation of concerns regarding how your platform is deployed and ran and how your frontend works. SPAs even allow your frontend team to go to the extent of handing your backend as if it was a third-party service, and some SPAs are even just that. There are plenty of CMSs out there which eliminate the need for a backend by providing all content needs through their commercial APIs. This makes webapppp projects greatly cheaper and simpler to finance and support as you can simply bother about developing and maintaining your SPA.

Lastly, those JavaScript frameworks you're trying to criticize also use CSS and HTML, by the way. So as you may understand your point is moot.

> Every web framework is _literally_ a hack to make the web something it isn’t.

You are clearly talking about things you have no understanding over. It matters nothing if you specify a DOM with a static file or procedurally. Updating only specific elements or branches of a DOM is a very basic usecases. In fact if you had any frontend experience at all you'd be aware that all mainstream GUI frameworks, including desktop, represent their UIs with a DOM.

So here you are trying to argue that frontend development is not frontend development just because you have an irrational axe to grind regarding a specific class of web development technologies?

> For thise JavaScript people, I recommend trying Laravel or Ruby/Rails.

If you hadn't already proven you are completely ignorant and detached from reality, this argument alone would leave no room for doubt.

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

#342

Post by ethan_smith »

fleebee wrote: post #100

It's worth noting that the Speculation Rules API and the View Transition API are not stable in Firefox and therefore aren't supported by all major browser.

This browser compatibility gap is a crucial point - without Firefox support, these APIs can't be considered production-ready for sites that need cross-browser consistency, undermining the article's central argument.

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

#343

Post by weego »

cleoxjefbjxis wrote: post #303
zero_shift wrote: post #275

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…

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…

Every web framework is _literally_ a hack to make the web something it isn’t

This sentence is doing an awful lot of heavy lifting that doesn't fit with reality

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

#345

Post by layer8 »

xyzsparetimexyz wrote: post #283
dzhiurgis wrote: post #66

Earlier quoted context omitted.

Gmail takes 3s to load. And HN is a website, not an app.

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

Document-centric, form-driven websites aren’t traditionally called apps. The Wikipedia website isn’t an app. Web forums aren’t apps. “App” implies that essential parts of the interaction logic are driven by client-side code (JS, not HTML) that couldn’t similarly be implemented by HTML forms.

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

#346

Post by brabel »

paradox460 wrote: post #205
Cthulhu_ wrote: post #70

Earlier quoted context omitted.

> and load up a giant pile of jQuery spaghetti I'll have you know I spent time on organizing and structuring my code with early JS design patterns like IIFEs to limit scope, lazy loading of modules, and minification. Anyway, in my experience, AngularJS was the biggest attempt at making structured front-end applications, and it really appealed / appeals (Angular is still very popular apparently) to Java developers; bi…

Wasn't there the Google closure compiler before angular?

And GWT which allowed literally running Java on the web (without a plugin, it compiles Java to JS). It still exists and is maintained but not a Google project anymore despite the name.

https://www.gwtproject.org/

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

#347

Post by cjonas »

weego wrote: post #343
cleoxjefbjxis wrote: post #303

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…

Every web framework is _literally_ a hack to make the web something it isn’t This sentence is doing an awful lot of heavy lifting that doesn't fit with reality

Ya this is nonsense. The web is what it is.

You could maybe say "every framework is a hack to workaround protocols primarily designed in the 90's before we really understood the full application of the web"

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

#348

Post by jazzypants »

layer8 wrote: post #340
codingdave wrote: post #14

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…

> It solved a real problem, of not wanting to reload all that code every time a user on an old browser, with a slow connection, changed some data. Why would the browser have to reload the code (JS files) on every page transition, with proper caching headers?

Click on a link on Amazon and take notice of all the kb of data in the head of every document that doesn't get cached.

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

#349

Post by brulard »

hollowturtle wrote: post #122
zeroq wrote: post #10

SPA is not only about seamless transitions but also being able to encapsulate a lot of user journey on the client side, without the need of bothering server too much. Let me give you an example - one of my biggest gripes about web ux is the fact that in 2025 most shops still requires you to fully reload (and refetch) content when you change filters or drill down a category. A common use case is when you come to a sho…

Thing is, and I believe it's a valuable example counterpoint, if I shift-click on a link, like sci-fi category, to open it in a new tab(very common thing people do), having a multi page application is zero work added, on an spa you have to manage that. If the link doesn't exist and categories can only be accessed by a select input then ux isn't that great

Modern SPA frameworks give you this by default. You can deep link and get the specific page with all the parameters/filters etc applied server rendered in remix/react-router, next, sveltekit and most other frameworks. I agree that too many apps have basic things like CMD+click broken

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

#350

Post by jazzypants »

twelve40 wrote: post #284
codingdave wrote: post #14

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…

> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load ...and yet, i keep running into web (and even mobile apps) that load the bundle, and subsequent navigation is just as slow, or _even slower_. Many banking websites, checking T-Mobile balance... you wait for the bundle to load on their super-slow website, ok, React, Angular, hundreds of megs, whatever…

Yeah, I see a lot of poorly written back-end APIs too.
Post reply on HN