4 ms·

> Less traffic in data-rich apps (even taking into account compression, HTML is heavier than JSON and not just due to syntax overhead - consider all those page

> Less traffic in data-rich apps (even taking into account compression, HTML is heavier than JSON and not just due to syntax overhead - consider all those page headers, footers and other common parts). This statement is way too overly broad. JSON is terrible for tabular data, since you have to include the field names in each row. HTML will be much better for data heavy sites in this case. Also, as others have mentioned, you still need to download and process the JS needed to display the data (libraries, likely styli ng, etc.). > Better UX for slow networks: even in countries with 5G coverage there are still a lot of corners where your device will struggle to connect. 1. Offline and autoconnect are lovely ideas, but most js devs don't care enough/aren't permitted the time to write with this sort of resilency in mind. In practice it isn't really an advantage. 2. When a SPA does fail, it is often worse than a back end framework. The browser will tell you the request failed and a very general reason why. Whether it worked or not is abundantly clear. Most SPAs just sit there and silently die, while you stare at the screen waiting to see if it will actually do something. 3. Most of the mobile devices you're talking aren't that powerful, so loading them down with a bunch of JS to run, makes for a really bad for UX.

ivan_gammel 3y ago
> JSON is terrible for tabular data Sure. When you use API, you can design it with a domain-specific data format. When you use SSR, you stick to HTML page overhead. >When a SPA does fail, it is often worse than a back end framework. This is not an argument against SPA, it’s an argument to invest in UX. When done right, SPA and native clients do deliver better UX than SSR/generic browser. The effort to achieve that is not huge, in fact this behavior can be built as a reusable component.
- infamia 3y ago
  > Sure. When you use API, you can design it with a domain-specific data format. When you use SSR, you stick to HTML page overhead. Now you hydration, your JS to run, and a custom serialization/deserialization format (and a custom parser) to maintain. > This is not an argument against SPA, it’s an argument to invest in UX. When done right, SPA and native clients do deliver better UX than SSR/generic browser. The effort to achieve that is not huge, in fact this behavior can be built as a reusable component. We're well over a decade into SPAs and we're still seeing these problems/errors. I routinely see SPAs keeling over without any feedback built by large, richly resourced. The tool has something to do with it if so many different people and organizations are failing.
- rokkitmensch 3y ago
  > This is not an argument against SPA, it’s an argument to invest in UX. ZIRP-era thinking. Gotta get by with less of everything now, unless you're a growth/hyperscaler snowflake, in which case the advice doesn't apply to us common-or-garden engineering shops.
  - ivan_gammel 3y ago
    A lot of UX gains can be achieved in a lean way with minimal effort. It is unfortunate, that the state of the industry is such, that half of „senior“ engineers only mastered CRUD and 90% of engineering and product managers are just random people without essential knowledge or skills required for their jobs. ZIRP era thinking is to assume that money will and only money can solve the problem of building a decent product.
    - rokkitmensch 3y ago
      Time is the other variable!
bcaxis 3y ago
> HTML will be much better for data heavy sites in this case I've never seen HTML be smaller than json for data representation. For any kind of data. Ever. [Snip SPAs reasons that aren't inherent to SPA] > Most of the mobile devices you're talking aren't that powerful, so loading them down with a bunch of JS to run, makes for a really bad for UX. Even mobile CPUs are more powerful than your average cloud vCPU. They get refreshed much more frequently if for no other reason than the batteries give out. That doesn't even take into consideration the fact that the server is rendering x requests vs the client's one. Any spend on server hardware to make it fast will never make up for the network latency vs a well built SPA that can avoid refetching some data again entirely. Page one, server render is faster. Every subsequent navigation will favor a well built SPA.
- rokkitmensch 3y ago
  > well-built hell of a caveat you casually slipped in there, comrade.

ivan_gammel 3y ago

> JSON is terrible for tabular data Sure. When you use API, you can design it with a domain-specific data format. When you use SSR, you stick to HTML page overhead. >When a SPA does fail, it is often worse than a back end framework. This is not an argument against SPA, it’s an argument to invest in UX. When done right, SPA and native clients do deliver better UX than SSR/generic browser. The effort to achieve that is not huge, in fact this behavior can be built as a reusable component.

infamia 3y ago
> Sure. When you use API, you can design it with a domain-specific data format. When you use SSR, you stick to HTML page overhead. Now you hydration, your JS to run, and a custom serialization/deserialization format (and a custom parser) to maintain. > This is not an argument against SPA, it’s an argument to invest in UX. When done right, SPA and native clients do deliver better UX than SSR/generic browser. The effort to achieve that is not huge, in fact this behavior can be built as a reusable component. We're well over a decade into SPAs and we're still seeing these problems/errors. I routinely see SPAs keeling over without any feedback built by large, richly resourced. The tool has something to do with it if so many different people and organizations are failing.
rokkitmensch 3y ago
> This is not an argument against SPA, it’s an argument to invest in UX. ZIRP-era thinking. Gotta get by with less of everything now, unless you're a growth/hyperscaler snowflake, in which case the advice doesn't apply to us common-or-garden engineering shops.
- ivan_gammel 3y ago
  A lot of UX gains can be achieved in a lean way with minimal effort. It is unfortunate, that the state of the industry is such, that half of „senior“ engineers only mastered CRUD and 90% of engineering and product managers are just random people without essential knowledge or skills required for their jobs. ZIRP era thinking is to assume that money will and only money can solve the problem of building a decent product.
  - rokkitmensch 3y ago
    Time is the other variable!

bcaxis 3y ago

> HTML will be much better for data heavy sites in this case I've never seen HTML be smaller than json for data representation. For any kind of data. Ever. [Snip SPAs reasons that aren't inherent to SPA] > Most of the mobile devices you're talking aren't that powerful, so loading them down with a bunch of JS to run, makes for a really bad for UX. Even mobile CPUs are more powerful than your average cloud vCPU. They get refreshed much more frequently if for no other reason than the batteries give out. That doesn't even take into consideration the fact that the server is rendering x requests vs the client's one. Any spend on server hardware to make it fast will never make up for the network latency vs a well built SPA that can avoid refetching some data again entirely. Page one, server render is faster. Every subsequent navigation will favor a well built SPA.

rokkitmensch 3y ago
> well-built hell of a caveat you casually slipped in there, comrade.