Comment by jiggawatts | Hacker News Reader

Comment by jiggawatts | Hacker News Reader

Parent Full thread

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. Theoretically, sure, but every app I come across just dumps half the database down the wire and picks out a few dozen bytes in JS code. There's a comment right here in this discussion advocating for this! [1]

Another angle is this: if you had a top 100 site with massive bandwidth costs, then sure, converting your app to a SPA might make financial sense. But instead what I see is tiny projects start as a SPA from day one, and no chance that their bandwidth considerations — either cost or performance — will ever be a factor. Think internal apps accessed only over gigabit Ethernet.

I’ve seen static content presented as a SPA, which is just nuts to me.

[1] "It's much better ux when a user downloads the whole catalogue" from: https://news.ycombinator.com/item?id=44688834

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

Does a real-world example of bandwidth saving even exist for SPAs? It’s always the other way around where what could’ve been a single page load, ends up being 6 separate asynchronous calls to different APIs to fetch random bits and pieces while the user stares at spinners.

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.

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

That's absolutely not my experience from any of the SPAs I've worked on. If the API used by the SPA is so "specialised, single-purpose", then that isn't something inherent to SPAs, only inherent to developers (or architects) who are inexperienced or bad at their job.

>every SPA app I’ve ever seen is two orders of magnitude slower than ordinary HTML would have been.

I'd argue then you don't have an SPA. However I don't see how you could have a application like Figma or Discord and say "ordinary HTML is faster" (or even possible).

For ever one real "app" like Figma there are hundreds of web pages with some forms and light interactivity. Numerically there are far more enterprise LoB apps than there are true web applications that SPAs are well suited for.

You claimed "every SPA" app, now its down to "most". I'm not going to argue against the fact that some people have hammers and only see nails.

Every popular technology has been over implemented - these same enterprises probably have a 100-node Spark cluster to process 1GiB of data.

"Every SPA app I've ever seen". I'm yet to see a fast one. Maybe they exist! I wouldn't know.

YouTube, for me, is unfathomably slow. It takes about a minute before I can get a specific song in one of my playlists playing. Every view change is 5-20 seconds, easily.

Facebook and the like now show polyfills for 10-30 characters of text, because hundreds of thousands of servers struggle to deliver half a line of text over terabits of fibre uplinks. Meanwhile my 2400 baud modem in the 1990s filled the screen with text faster!

Jira famously was so slow that this would never fail to be mentioned here any time it was mentioned. Service Now is better, but still slow for my tastes.

Etc...

If you disagree, link to me a fast SPA app that you use on a regular basis.

PS: Just after writing this, I opened a Medium article, which used -- I assume -- SSR to show me the text of the article quickly, then replaced it with grey polyfills, and then 6 full seconds later it re-rendered... the same static text with a client-side JavaScript SPA app. 100 requests, 7 MB, for 2 KB of plain text.

You mean a chat cliënt? That seems a good worse case scenario.

If you limit history to the most recent message (and have an link to the archive at the top) you could simply reload the entire page on some interval that declines with message frequency (and when you submit the form)

Since the html document is pretty much empty the reload happens so fast you won't see the flashing. With transitions it would be perfectly smooth.

With modern css you can put the elements out of order. You can simply append the new line to the end of the html document that represents the channel. (And to the archive) Purging a few old lines can be done less frequently.

I haven't tried it but it should work just fine. I will have to build it.

Initial load will be 100x faster. The page reloads will be larger but also insanely robust.

>You mean a chat cliënt? That seems a good worse case scenario.

No, I mean discord. An application where you can chat, recieve phone calls and watch a live stream all at the same time.

A pure html chat client is uninteresting - there have been realtime html chat clients since I was teenager, even before the release of jquery.

The things I was wondering about were: 1) can a non spa chat client be as good as a spa. 2) at what point is a spa justified. (is chat enough?)

Phone calls and live streams are things for which a tab needs to stay open. If you want to do other things simultaneously both the browser and the OS could facilitate it - but do so rather poorly.

It's not why people make spa's it seems?

> You mean a chat cliënt?

Calling Discord "a chat cliënt [sic]" is barely one step removed from "I could build that in a weekend". So go ahead. Wait, what is stopping you?

No audience.

Reply on news.ycombinator.com