Hacker News Reader

Comment by axegon_ | Hacker News Reader

> fast and responsive

I'm sorry but I have to disagree. I've never seen a fast or responsive SPA, not to mention the absurd amounts of resources they require. A tab taking up 400 mb of memory is pure insanity and this is the de facto standard these days. Look at HN: this is the definition of fast and responsive. It will work equally well on my dual-xeon workstation and a first gen raspberry pi zero. This is fast and responsive. Most people who use a computer to navigate the internet would not care if the browser blinks when you navigate a page. Mobile users don't really use the web beyond social media and chats so it makes no difference to them either. SPAs solved a problem no one had by creating 1000 other problems. Just take us back to server side html rendering and I guarantee most ordinary people as well as most developers will love it.

View on HN

> I've never seen a fast or responsive SPA

Here, let me blow your mind. It's in Czech, but you can click the orange buttons to try the activites: https://gramazing.com/features .

Made with NextJS (client side only), Django, hosted in Germany on a cheap VPS.

And you could do all that with a static generated site. Why it needs to be an SPA?

Yes, I could do it with server rendered site, it wouldn't be as fast though. Also SPAs were my bread and butter with my previous employer, and I have gotten to a point where I am much more comfy with NextJS+Django than SSR Django, Django+homebrew JS or something like HTMX (as much as I wanted to like that one).

Statically generated site is something completely different and I couldn't make Gramazing like that.

> SPAs solved a problem no one had

The problem was: can we make the same data APIs to serve the web and mobile apps?

Current gen frameworks can totally consume the api on server and spit out perfectly normal html to browser just like normal mpa. However this depends on whether you have a competent ops team that is capable to deploy something other than static html. And not having that is the reason you choose spa at first place in a lot of times.

That seems irrelevant to whether SPAs were solving a nonexistent problem when they were invented.

It solves the problem that your ops team sucks and can't deploy anything other than static html while you are required to make a site with proper custom url (and custom content base on url). And to me the quality of ops team is a REAL problem. If it isn't a problem for you then you are just too lucky (I'd envy you ;_;) or never doing any web development.

To be honest, server side rendering is always the king regard of performance. A properly optimized static html generator can make you see the page under 0.5s after you click the link even under most awful network. And it isn't even enough for most spa to download the javascript alone (it will at least need 3 rtt to see basic layouts, one time html, one time js, the js load the images and style)

What I'm saying is that problem might be solved (or solvable) now, e.g. with stuff like Phoenix or NextJS, but it wasn't solved when SPAs were invented.

SPA was never made to solve those problems in my opinion. They are basically unfortunate side effects that introduced when SPA was made to resolve it's original targets. (And without SPA, we would probably never know mess with routes is so damn problematic.)

I had always assumed the problem was "the page flashes for 0.3 seconds when we navigate from View #1 to View #2 as we reload the header and sidebar"

Reply on news.ycombinator.com