Hacker News Reader

Comment by philosopherlawr | Hacker News Reader

You're basing a lot of this viewpoint on fast internet connections. Javascript code rendering will be faster if you have a slow internet connection and are using an updated browser with a fast javascript engine

View on HN

Eh, I've yet to experience an spa that feels or is faster than the equivalent simple html, no matter what network I'm on - with the exception of being off-line (and I've seen few enough spas that actually work better offline than static pages, ie not broken navigation/functionality).

Note that I've of course seen countless slow, bloated static pages - but that's pretty much never because of the tech stack - but because of bloated css, silly large images, and often horrible convoluted html.

Hn is of course a typical example of a web page that on paper would be great as an spa, but works fine as a static page with minor js (broken up/down links notwithstanding..).

D-lang forums is another :

https://forum.dlang.org/

Assuming a 64 kbps connection, and a 50%+ gzip compression, downloading a couple of pages of text is done in about half a second. If the user has such a terrible connection, they've hopefully turned off image loading. I don't think adding 40-400 kbs of gzipped js is going to help with the speed...

https://gist.github.com/Restuta/cda69e50a853aa64912d

How do you know when you're using a SPA and when you're not? Seems to me, a well designed SPA is indistinguishable from a regular HTML site unless you're actively looking at the network tab. Could it be that you have a bad impression of SPAs, because you only really notice it when you're using a badly designed one?

One nice thing about regular HTML websites is that they only need to be downloaded once. When I was taking the train in to school, I'd often have a bunch of tabs open on my phone. If I tried to switch to an old Reddit (SPA) tab while going through a tunnel, the page would try to reload, fail, and replace all the content that was already there with an error message. With HN, by contrast, I could open up a bunch of tabs while I still had good internet and switch to them later even when I didn't.

In theory you have a point. In practice though the initial loading of the first page is so slow that it completely negates the benefits entirely.

It also doesn't work well when opening lots of tabs (which is a popular technique that helps immensely when browsing on a slow connection as pages are loaded in the background).

And if you have a really slow or spotty connection the javascript page would barely load at all.

I think you're basing this off of old technology. With webpack 2 and HTTP/2, this is less of an issue. But, the top comment's statement I think is the most valid: if you're loading static text, then simple html pages are the best. Notice the rise in popularity of static site generators for this purpose. A SPA will win out when you have lots of interactions and you only experience the initial loading of the first page once - and then the majority of your user experience is around interacting with the app.

From time to time I have to use 64kbps on my cellphone. At that point the biggest pain in the ass becomes first loading and in that classic HTML app shines, it loads a LOT faster - if you have 1.5MB page or 600kB makes a huge difference. But once it's all static content is cached it pretty much doesn't matter if it's XHR or full page load since I'm loading only tens of kBs at max.

Also if I have to use 64kb I completly disable js in my browser and whitelist just a couple of websites - best adblock on mobile.

I actually prefer HTML over SPA apps on slower Internet connections. I've found SPAs to be more infuriating to use when the connection is bad.

Designing with intermittent connections in mind is a lost art, even the windows 10 start menu won't work properly with one.

Unfortunately connection are more intermittent now than ever before.

My homepage has about 81kb of data to transfer, including images.

If you turn off images, you get in with 12kb of data. I think 12kb of data should be transferred faster than even the more lighter JS frameworks around...

i much rather see my html page slowly loading before me than a js button that doesn't load and when i decide that it's taking too long and i want to go back then everything just messes up because it doesn't work with the back button in the browser

Reply on news.ycombinator.com