Hacker News Reader

> It’s like we suddenly and collectively became afraid of the page reload on websites

I used to work at a place where page reloads was constantly an issue brought up as a negative. They couldn't be bothered to fix the slow page loads and instead avoided page changes.

I argued several times that we should improve performance instead of caring about page reloads, but never got through to anyone (in fairness, it was probably mostly cos of a senior dev there).

At some point a new feature was being developed, and instead of just adding it to our existing product, it was decided to use an iframe with the new feature as a separate product embedded.

Oh my god iframes should be removed from browsers so no one should be able to use them ever.

I think there are a couple of legitimate uses of iframes, but in most cases, it’s not something you want to use.

If you want to take payments in your application using a vendor like Nodus, ie, if you have an app that is being used by a CSR/Salesperson, and they need to take CC or eCheck data, showing the payment application in an iframe (within the context of the app) lets you have that feature within the application but importantly, means you don’t have to be PCI DSS compliant yourself

Opening the payment flow in a separate window while displaying a message like "please complete the payment with your chosen payment provider" is almost as good from a usability standpoint and a lot better when considering security best practices.

Browsers have no good way of sandboxing external code. See the trouble that Figma went through to get plugins to work: https://www.figma.com/blog/how-we-built-the-figma-plugin-sys...

I love SPAs. I love making them, and I love using them. The thing is, they have to be for applications. When I'm using an application, I am willing to eat a slower initial load time. Everything after that is faster, smoother, more dynamic, more responsive.

> Everything after that is faster, smoother, more dynamic, more responsive.

IF and only IF you have at least med- to high-end computer and smartphone. If you have low-end hardware you first have to wait for that 20MB to load AND get to use slow and choppy app afterwards. Worst of both worlds, but hey, it's built according to modern standards!

> But for something like pornhub? Well PHP serves them just fine,

Kind of fun to make this argument for Pornhub when visiting their website with JavaScript disabled just seems to render a blank page :)

> how many people still vastly prefer the old.reddit.com site to their modern SPA

Also a fun argument, the times I've seen analytics on it, old.reddit.com seems to hover around/below 10% of the visitors to subs. But I bet this varies a lot by the subreddit.

There might be a legal requirement for them to make sure you accept the "I'm 18" dialog before displaying anything.

Been possible to do without JavaScript before, and is still possible today :) Where there is a will, there is a way. I'd still argue Pornhub is a bad example for the point parent was making.

> visiting their website with JavaScript disabled just seems to render a blank page :)

Average people don't disable Javascript. So they predictably don't spend much time trying to make the site work for people who aren't their core audience.

Why SPAs became popular? Because they "feel" native on mobile. Now you have page transitions and prefetch which really should kill this use case.

IMO the bloat he talks about on the post is not representative of 2024. Pretty much all frontend development of the last 2 years has been moving away from SPAs with smaller builds and faster loading times. Fair enough it's still visible in a lot of sites. But I'd argue it's probably better now than a couple years ago.

Personally, I don't see why one would hate SPA concept. I like it, because it enables to lower the traffic and make interactions... normal? And to use local computing when possible, instead of adding 2 and 2 over HTTP.

When people hate SPAs they actually hate terminally overweight abominations that no one (i.e. google) keeps in check, and that's the reason they are like that. Why should on-page interaction be slow or cost one 20MB of downloads? No reason. replaceChild() uses the same tech as <a href>. SPA is not a synonym for "impotent incompetence 11/10".

If humanity didn't invent SPAs, all these companies would just make half-a-minute loading .aspx-es instead. Because anything else they can not.

> Why SPAs became popular? Because they "feel" native on mobile.

They... Don't :) The absolute vast majority of them is a shittier, slower, clunkier version of a native app

> IMO the bloat he talks about on the post is not representative of 2024. Pretty much all frontend development of the last 2 years has been moving away from SPAs with smaller builds and faster loading times.

He literally lists Vercel there. One of the leaders in "oh look at our beautiful fast slim apps". Their front page loads 6.5 megabytes of javascript in 131 requests to those smaller bundles.

Well to stay within the example porn website of OP, because it is not an SPA you cant really make a playlist play in full screen - the hard page reload will require you to intersct to go fullscreen again on every new video. Not an issues in SPAs (see youtube).

I feel like the term SPA has since ceased to have any meaning with the HN crowd.

I mean i do generally agree with your sentiment that SPAs are way overused, but several of the examples of TFA arent SPAs, which shoould already show you how misguided your opinion is.

depending on the framework, SPAs can start at ~10KB. really, the SPA is not the thing thats causing the bloat.

You’re right. People miss that SPAs aren’t heavy by definition, but by accident and/or acquire bloat over time. You can totally have a super-useful, full featured, good looking and fast SPA in 150 KB gzipped including libraries. Only it takes knowledge and discipline to do that.