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

271–280 of 516 posts

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

#271

Post by KronisLV »

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…

> SPAs make sense when your users have long sessions in your app.

SPAs also make sense when you want to decouple the front end from the back end, so that you have a stable interface like a RESTful API and once AngularJS gets deprecated you can move to something else, or that when your outdated Spring app needs to be updated, you'll have no server side rendering related dependencies to update (or that will realistically prevent you from doing updates, especially when JSF behavior has changed between versions, breaking your entire app when you update).

> When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.

The slight difference in user experience might not even enter the equation, compared to the pain that you'd have 5 years down the line maintaining the project. As for loading the app, bundle splitting is very much a thing and often times you also get the advantage of scoped CSS (e.g. works nicely in Vue) and a bunch of other things.

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

#272

Post by sfn42 »

LegionMammal978 wrote: post #172
sfn42 wrote: post #139

Earlier quoted context omitted.

This works for some websites, not all. And often it results in significant loading times, because you're loading tons of unnecessary data. In many cases it is much better to send requests more frequently, similarly to how a server side rendered website would behave. Instead of fetching 10,000 products, just fetch a page of products. Much faster. Have endpoints for filters and searches, also paginated. This can be fas…

> Network requests themselves are not slow. Even a computer with a bad connection and long distance will probably have less than 500ms round trip. More like 50 to a few hundred at most. Anything beyond that is not the client, it's the server. Not if the client is, e.g., constantly moving between cell towers, or right near the end of their range, a situation that frequently happens to me on road trips. Some combinatio…

> Not if the client is, e.g., constantly moving between cell towers, or right near the end of their range, a situation that frequently happens to me on road trips.

Right, but how often is a user both using my website and on a roadtrip with bad coverage? In the grand scheme of things, not very often. I also think this depends on what the round trip is for. Maybe the 10s round trip is simply because it's a rather large request.

> I don't at all disagree that too many tiny requests is the cause of many slow websites

That's not really what I was saying, though I don't disagree with it. If you're sending multiple small requests then there are two ways to go about it: You can send all of them at the same time, then wait for responses and handle them as they come back. The other option is to send a request, wait for a response, then send the next etc. The latter option causes slowness, because now you're stacking round trips on top of one another. The former option can be completely fine.

But I'm not saying the client should be sending lots of requests. I'm saying they should get the data they need rather than all the data they could possibly need. This can be done in one request that gets a few kilobytes of data, you can fit 64kb in a single tcp packet. That's quite a bit of data, easily enough space to do useful stuff. For example the front page of HN is 8kb. It loads fast.

I'm also not saying you should use SSR. I do think that SSR is a great way to build websites, but my previous comment was specifically about SPAs. You don't have to send requests for every little thing - you can validate forms on the frontend in both SPAs and SSR.

Round trips are costly but not that much. A lot of round trips are unavoidable, what I'm saying is that you should avoid making them slower by sending too much data. And also avoid stacking them serially.

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

#273

Post by kertoip_1 »

nromiun wrote: post #242

Lots of pushback here in the comments. But I can't think of the last time I enjoyed using a SPA website over a multi-page one. The initial loading feels delayed, the page scrolling feels unnatural and jarring (completely opposite of how a native app feels). Also, one of my banks recently changed their old website to a new SPA one. And it is now completely useless. It can't load information in time, so most of the for…

Yeah, the worst thing is when parts of the same application are under the hood different SPAs.

First example that comes to my mind: web version of ProtonMail. Going to settings feels like loading a completely separate website. Or OVH dashboard.

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

#274

Post by jiggawatts »

usrusr wrote: post #261
dsego wrote: post #118

Earlier quoted context omitted.

And the frontend-backend paradigm has seeped into the engineering culture and even the non-engineers on the team understand things in those terms. The main way we break apart work into tickets is API endpoints and client-side UI stuff.

This. The mental model of an API with a frontend deployed as static resources just happens to be very attractive. Even more so when the SPA isn't the only frontend, or when you don't know that the SPA will remain the only frontend forever. When you have an SPA sitting on top of an API, introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial. If you have a huge org workin…

> introducing new clients for feature subsets (e.g. something running on a Garmin watch) becomes trivial.

This never happens, for some values of never.

When a SPA app is initially developed, the "client" and the "API" are moulded to each other, like a bespoke piece of couture tailored to an individual's figure. Hand-in-glove. A puddle in a depression.

There is absolutely no way that some other category of platform can smoothly utilise such a specialised, single-purpose API without significant changes.

The reality is that most SPA apps are monoliths, even if the client app and the API app are in different Git repos in order to pretend that this is not the case.

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

#275

Post by zero_shift »

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…

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 really internalised?

3. The undercurrent of "frontend is not real programming" prejudice that existed long before React etc al. and will continue to exist long after it?

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

#276

Post by romanovcode »

nfw2 wrote: post #180
adamtaylor_13 wrote: post #161

Earlier quoted context omitted.

“But they are better” By what measure?

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.

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

#279

Post by tossandthrow »

nromiun wrote: post #242

Lots of pushback here in the comments. But I can't think of the last time I enjoyed using a SPA website over a multi-page one. The initial loading feels delayed, the page scrolling feels unnatural and jarring (completely opposite of how a native app feels). Also, one of my banks recently changed their old website to a new SPA one. And it is now completely useless. It can't load information in time, so most of the for…

> But I can't think of the last time I enjoyed using a SPA website over a multi-page one.

You likely don't even notice that most of what you browse are SPAs.

The reason why there is pushback is because the article is straight up misinformation.

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

#280

Post by bigtones »

vasco wrote: post #278

It's incredible to write an article about UX with a main argument of "this way is as good as that way" without visual examples to prove they actually behave the same.

Right, I would like to see some examples of what he is talking about considering his tone of voice - he is literally telliong people to change their ways and use modern CSS and the entire article is devoid of such css.
Post reply on HN