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

261–270 of 516 posts

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

#261

Post by usrusr »

dsego wrote: post #118
jiggawatts wrote: post #78

Earlier quoted context omitted.

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.…

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 working on the project you might actually succeed in sticking to that architecture even when serving as plain old HTML, but smaller teams are likely to eventually write full stack spaghetti (which might still be fine for some use cases!). Once there was a fashionable term "progressive web app", with manifest workers optionally moving some backend stuff into the browser for offline-ish operation, and these days I also see a parallel pattern: progressively moving a browser UI into an electron-esque environment, where you can features requiring more local access than the browser would allow.

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

#262

Post by dannye »

jongjong wrote: post #126
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 are nice when your app requires complex state; multiple rows of nested tabs, modals, multiple interlinked select inputs which load data dynamically, charts or graphs which can lazy-load data and update on the fly in response to user actions. There is a certain level of complexity beyond which you need to load data on the fly (instead of all up front on page load) and you literally cannot avoid an SPA. Choosing t…

> there are no weird rendering glitches or timing issues or weird gotchas that you have to dig into to.

Ehm... define the Web Component render blocking in the head, because you want to prevent FOUCs. Then try to access the .innerHTML of your Web Component in the connectedCallback

https://dev.to/dannyengelman/web-component-developers-do-not...

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

#263

Post by dannye »

niutech wrote: post #254
Tokumei-no-hito wrote: post #204

Earlier quoted context omitted.

i remember seeing web components years ago, it sounds like they've improved a lot. what do you do about the lack of (i assume) ecosystem? due to the ready ubiquity there's practically a library for everything. do you find that using WC you are having to hand roll a lot? i don't mean to be a package slave but for complex and tedious things like graphs / charts.

There is an ecosystem for Web Components: Polymer, Lit, WCB, ready-built web components at https://webcomponents.org

Latest blogpost on that site is from 2018

I presume Web Components are so great they haven't had anything happen since 2018

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

#264

Post by sfn42 »

Izkata wrote: post #259
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…

> 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 fast if you do it right. Since you're only sending minimal amounts of data everything is fast. This is actually a great example of what I me…

Yeah you can do that, but it's not necessary. You'll have to figure out a clever way to first wait for the data the user actually needs on the first load, then silently cache the other stuff in the background. Then you'll have the best of both worlds, but it complicates the application. It might make sense for Gmail and google maps, but there are a lot of web apps for which it does not make sense to put the work into this.

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

#265

Post by danielscrubs »

pas wrote: post #224
danielscrubs wrote: post #220

Earlier quoted context omitted.

I 100% would like to see an MPA Google Maps. Being able to come back to a webpage with previous directions? I think it would be glorious.

You are mixing up linkability/history and being an MPA/SPA. Many websites simply have some session/state dependent page.

Google Maps cant even preserve state in their iOS app.

They are either the worst developers in the world or it is not simple.

I don’t rule any of the two possibilities out.

Some things you get for free with the correct architecture. For whatever reason, SPA does not have a great track record with their users.

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

#266

Post by aswerty »

I'm not a fan of the SPA, or at least in practice, but there is something very attractive about going with a solution that everybody knows.

At work we are building a new "website like" frontend and it is a SPA (that internally operates as a MPA) built with React. The main reasons are we: know this setup well and know when hiring we will find people who know this setup as well. Beyond that, it will allow us to build out more application like features in the future if needed.

This approach has been popular in the industry for over 10 years now. Whereas most of the current discussion and tech on the frontend feels like churn and betting on the next thing. A lot of people just want tools that are mature and can get the job done regardless of them being the best tool under specific criteria.

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

#267

Post by unchar1 »

donatj wrote: post #234
nfw2 wrote: post #180

Earlier quoted context omitted.

Performance, developer experience, user experience

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 experience, but I think a lot of other sites that tried the CSR -> SSR move had similar experiences. It's just harder to talk about, since it goes against the usual narrative.

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

#268

Post by youngtaff »

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. When it is worth the pain to load a large bundle in exchange for having really small network requests after the load.

Only for certain types of applications… the route change time for many SPA’s is way higher than for the equivalent MPA

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

#269

Post by youngtaff »

aryonoco wrote: post #131
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…

Angular not only appeals to Java developers, it also appeals to .NET developers. TypeScript of course borrowed a lot from C# (having the same designer) and dependency injection, MVC patterns etc closely resemble .NET patterns. Interestingly, new Angular is slowly moving away from these, introducing Signals for state management and standalone components, and I see these developers actually struggling a lot to adopt ne…

Angular was created so Java developers could create browser apps

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

#270

Post by youngtaff »

mattbrewsbytes wrote: post #90
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.

> HTTP 2 has been adopted by browsers for like 10 years now and its multiplexing makes packaging large single bundles of JS irrelevant

H2 doesn’t make packing irrelevant… there’s still an IPC overhead with many small files… and larger bundles tend to compress better (though compression dictionaries might help here)

Large Js bundles are a huge problem though

Post reply on HN