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

251–260 of 516 posts

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

#251

Post by [deleted] »

raron wrote: post #144
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…

> 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. There are complete CAD applications running in browsers for PCB and mechanical design with many layers, 3D view, thousands of components, etc. For example: https://easyeda.com/ https://www.onshape.com > because HTML compresses incredibly well Haven't compression under TLS have been mostly d…

[deleted]

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

#252

Post by niutech »

raron wrote: post #144
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…

> 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. There are complete CAD applications running in browsers for PCB and mechanical design with many layers, 3D view, thousands of components, etc. For example: https://easyeda.com/ https://www.onshape.com > because HTML compresses incredibly well Haven't compression under TLS have been mostly d…

No, HTTP compression is widely used (brotli increasingly).

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

#253

Post by goodpoint »

wolpoli wrote: post #192
TimTheTinker wrote: post #27

Earlier quoted context omitted.

Low-bandwidth/spotty connections (combined with aggressive caching) are one of the strongest cases in favor of SPAs (emphasis on the A for Application, not website). Visit (and cache) the entire frontend for the app when you have a good-enough connection, then further use of the app can proceed with minimal bandwidth usage.

Honest question: Where are the places with low-bandwidth internet? Are we talking about cruise ships and satellites internet use cases?

3 billions people live in places with low-bandwidth / unreliable / expensive internet

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

#254

Post by niutech »

Tokumei-no-hito wrote: post #204
jongjong wrote: post #126

Earlier quoted context omitted.

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…

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

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

#255

Post by aquariusDue »

naet wrote: post #163
throwaway7783 wrote: post #18

Earlier quoted context omitted.

HTMX (and similar) solves a lot of this. It so happens that we end up building two apps one frontend and one backend with SPAs as built today. I'd rather build a lot of it on the server side, and add some dumb interactivity on the client (show/hide, collapse/expand, effects). There is still a place for SPA though.

HTMX does the opposite of this, it requires many more round trips to the server instead of using client side JS to do work.

I find Datastar to be a better replacement for HTMX, especially now that it can also do plain requests instead of Server-Sent Events. You also don't need Alpine.js combined with HTMX anymore.

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

#256

Post by eric-burel »

TL;DR: article means traditional websites with server navigation (now dubbed MPAs, multi page applications) have evolved positively with better handling of page transitions. But they choose to frame this idea by trashing SPA, while both MPA and SPA have a role to play.

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

#257

Post by Dylan16807 »

chaps wrote: post #58
chrisweekly wrote: post #47

Earlier quoted context omitted.

Java applets are entirely distinct from SPAs, at least as that term is used in the webdev community.

Hm, alrighty then. Seems like an unnecessary distinction to me in that it deeply constrains what SPAs can be, but I'm not a webdev.

The rule is either "uses html to render" or an even looser "renders in the browser". That doesn't seem like a deep constraint to me. You exclude a couple very popular but historical plugins where the browser set up a rectangle and handed it off to an external piece of code, and pretty much nothing else.

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

#259

Post by Izkata »

sfn42 wrote: post #139
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…

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 mentioned elsewhere about how people seem to have forgotten how to make a SPA responsive. These are both simpler implementations, but not really the best choice for user interaction. A better solution is to take the paginated version and pre-cache what the user might do next: When the results are loaded, return page 1 and 2, display page 1, and cache page 2 so it can be displayed immediately if clicked on. If they do, display it immediately and silently request and cache page 3 in the background, etc etc. This keeps the SPA responsive with few to no loading spinners if they take the happy path, and because it's happening in the background you can automatically do retries for a flaky connection without bothering the user.

This was how gmail and google maps blew peoples' minds when they were first released, by moving data to the frontend and pushing requests to the server into the background, the user could keep working without interruption while updates happened the background without interrupting their flow.

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

#260

Post by renegade-otter »

heisenbit wrote: post #241
throw-the-towel wrote: post #132

Earlier quoted context omitted.

This is not true. In practice SPAs break completely when some network request fails which happens a lot on bad connections.

Sadly the art of error handling is often neglected by some SPA developers. I suspect that failures on the client are also less tracked this is tolerated by businesses.

That has nothing to do with them being "SPA developers". They are just bad developers, lazy, or inexperienced.

Errors/messages/warnings is one of the first things I do in an app framework, since it's incredibly hard to "bolt that on" later.

Post reply on HN