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

81–90 of 516 posts

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

#81

Post by Cthulhu_ »

LegionMammal978 wrote: post #11

There's still value in web applications what can perform most of their operations client-side, when feasible. Lots of websites seemingly operate under the assumption of "If the client manages to connect to the server once, then surely it can maintain a stable, low-latency connection in perpetuity." This renders those websites unusable on flaky connections or with very high latency. Of course, plenty of SPAs are guilt…

Consider also the origins of SPAs and their accompanying backends - mobile apps. I've worked with various projects where both web and mobile frontends would be using the same backend.

In theory you could build a SSR on top of that same backend, but for some reason that feels wrong, like an extra layer of indirection.

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

#82

Post by Cthulhu_ »

game_the0ry wrote: post #74

CSS is uderrated and almost never even discussed in front end interviews. Its all javascript javascript javascript. Javascript is over-rated. CSS > JS

I don't know if CSS is underrated, but it's definitely a speciality that a lot of software developers don't (want to) specialize in. It's like the front-end equivalent of SQL; so much is possible in SQL, but most logic is built in application code because SQL is scary.

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

#83

Post by sverhagen »

QuadrupleA wrote: post #76
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…

Side note, sick of jQuery being always associated with spaghetti in the tech lexicon. Any Turing-complete system is spaghetti in the hands of bad programmers. And simple & clear in the hands of good ones who know how to design.

Languages... (is jQuery a language, I guess so, let's go with that)... live in a context... there is culture, tooling, libraries, frameworks. Some languages have good culture, some have bad culture. I guess it's not even so black and white: language have good or bad culture in different areas: testing, cleanliness, coding standards, security, etc. If jQuery is misused in the hands of bad programmers ALL THE TIME, that becomes the culture. Not much to do about it anymore once the concrete has set. You can't still be an exception to rules, good for you! But that doesn't change the culture...?

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

#84

Post by Cthulhu_ »

epolanski wrote: post #44

I'm fully convinced that it's time to kill SPAs on 99% of websites and that the community is too defensive on the topic.

You're kind of already answering your own statement; websites should not be SPAs and vice-versa. Personally I think that an SPA should be something that lives behind a login.

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

#85

Post by SoylentOrange »

I’d like to add to the reasons for why you want an SPA over something with SSR:

* You have a large number of users compared to your resources and you can’t afford for your user base to always hit your server. Comparatively, deploying API-only apps is far cheaper when you’re resource-starved (eg early stage startup).

* You don’t care about SEO, for example you’re building internal tooling. You then don’t need to care about hydration at all. Much simpler to separate concerns (again esp at the beginning).

* Offline mode (eg PWA or reusable code in Electron) or cases where you want to be resilient to network failures. In the case that your app is dependent on the server for basic functionality like navigation, you can’t support any type of offline mode.

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

#88

Post by 725686 »

emseetech wrote: post #15

The View Transitions API is beautiful and I can't wait for it to become widely available. I've soured on SPAs in the past few years. So much more can be done with standards than people realize. SPAs were best for specific use cases but we made them the default for everything. Marketing pages are built in React! Basic pages with marketing copy have a build step and require hundreds of megabytes of dependencies. Like t…

"The View Transitions API is beautiful and I can't wait for it to become widely available."

a few comments below

"The view transitions API is a disaster."

I love HN.

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

#89

Post by geraldwhen »

jiggawatts wrote: post #78
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…

The real reason SPAs are popular is because JavaScript is the new Visual Basic and there are millions of developers that know nothing else. Workforce market forces like that have a vastly greater effect than “bandwidth optimisation”. My evidence for this is simple: every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been. There is almost never a bandwidth benefit in practice.…

Can’t hire for anything else. Competence in development no longer exists. And AI is making this march to idiocy worse.

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

#90

Post by mattbrewsbytes »

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…

If you work at a place that has a modern CI/CD pipeline then your multiple deployments per day are likely rebuilding that large bundle of JS on deploy and invalidating any cache.

HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant. SPA’s that use packaging of large bundles doesn’t leverage modern browser and server capabilities.

Post reply on HN