Hacker News new | ask | show | jobs
by Softcadbury 2139 days ago
Yes you're right, but keep in mind that with SPA, only the first loading is slower, then you don't need to reload again when changing pages.
6 comments

Try to open 10 actual html websites. Now try to open 10 SPA. Tell me which feels slower. SPA slowness is not exclusively from all the third party JS and CSS loads. A lot of it is just innate to being an application instead of a document.
Assuming there are repeat visitors. Someone sent you a link to an article. You don't care which website the article is on, you just want to read it and close it without exploring whatever else the website had to offer. So you download a several-megabyte JS bundle to be able to read several kilobytes worth of text. By the time you encounter another link to that particular website, your cache of its assets would be long gone.
Not necessarily true. I've seen many SPA apps where the API calls that get made when you navigate between pages are slow too. So subsequent pages are slow also in addition to the first page.
This isn't even a hard technical constraint. With async javascript "module" loading, and stuff like the new federated webpack stuff, you can have a lot functionality loaded in on-demand.

That won't always work out or be necessary though.. For an app like Lucidchart or something, I can deal with DL'ing updates every now and then. I spend most of the time in the running app.

In theory. In practice most SPAs are slow at first load and slow when changing pages then crash when too much data is requested.

Beyond that, unless your users are a captive audience (have to use your software for their job) you should probably be optimizing for a positive first impression.

Cold caches are common for users.