Hacker News Reader

Comment by iio7 | Hacker News Reader

There is no sudden about it, SPA's are yet another one of the so-called "modern web" cancers of the Internet. They go completely against the protocols and architecture they run on and the only reason why they became so popular to begin with is because of all the hype from the big business, like so much else.

A web application or a website, by its very nature, is a series of small requests. When someone sends all requests in one big lump of a page, they have just defeated this very important architecture. Not to talk about the fact that they break searching on pages and a whole lot of other things.

View on HN

> A web application or a website, by its very nature, is a series of small requests. When someone sends all requests in one big lump of a page, they have just defeated this very important architecture.

This whole take is just bizarre. Literally none of this matters to users except to the extent that it affects performance. While I would agree that many/most SPAs are implemented extremely poorly and inefficiently for reasons relating to what you're talking about it, and that that poorness spans both technical faults and UX problems, it's a very myopic view to complain that the foremost function of the web should be to rigidly adhere to a particular set of architectural patterns that are in flux and often outdated by modern standards.

> Literally none of this matters to users

Users prefer the hypertext model to opaque blobs.

ask any user what "hypertext" is and you'll get a confused look; similarly, give them a black-on-white, no-css page and they'll think it looks quite ugly and isn't a good experience. spas are commonly horrible to use but restricting everything to the model of the internet as it existed in the 80s is not a good thing either

Just because my mother in law doesn't use the word hypertext doesn't mean she doesn't know how to use a link, and isn't frustrated when some places can't do it.

99% don't know how anything works, but they still have preferences.

Hypertext doesn't have to break with SPAs.

> Literally none of this matters to users

Being able to bookmark deep links matters. I've worked places where users complained they couldn't bookmark their work because everything is just "the page".

That's the fault of the application developers, not SPAs in general. SPAs support routing, for instance if you are using React router it uses the browser's history API to add the navigated pages to the history and to change the path that appears for the users, if a user then bookmarks that page when they reopen it react router and co should take him back to the same area of the app they were in before.

Not defending SPAs, just pointing out that they are not to blame for this.

If your web page has to reimplement basic web browser functionality, like scrolling, or the back button, or linking, you have strayed far from the path to wisdom.

>Literally none of this matters to users except to the extent that it affects performance.

Yeah, just render my browser's back button dysfunctional, fam. Doesn't matter to me at all. Take all my control away and lock me into your walled garden of totally custom, approved-only interactions.

Do you care about your back button because it's an architectural principle of the web, or because it provides a useful function? Go back and read my comment carefully and you'll probably realize you're arguing against a strawman.

I'm not an expert, but it looks like things are starting to move towards a nice optimum. Many of the hot new frameworks do server side rendering and only send JavaScript to the client as needed.

I think you misunderstand what an SPA is. It also sends a series of requests as you navigate the website. It doesn't break search because everything is rendered to HTML.

It does break search. A traditional SPA returns to the client an empty HTML page (except for header stuff) and a script to parse. The script then populates the DOM with the elements, problem is that crawlers are not really good at waiting for the "render" to happen, and running JavaScript just to see what's in the page opens a whole other can of worms. SPAs are awful for search engines and that's why we get the hybrid monsters that Next.JS, Nuxt, SvelteKit and co. produces nowadays (not saying they are bad from a user perspective though, much prefer web apps made with them over client-side rendered SPAs).

We spent the last decade trying to fix the whole mess that client-side "rendering" created in the web, we'll probably spent the next decade trying (and failing) to standardize things such as web components, declarative shadow DOM, among other things. That's because we as developers keep insisting in complexity: hydration, SPAs, bundlers (and in consequence bundle bundlers such as Vite). The only true solution is to bet in simplicity, but that's not sexy, and sex sells.

In conclusion: The React revolution and it's consequences have been a disaster for the human race.

The SEO argument is a strawman. Large swaths of the Internet return a blank page if you try to access them with JS turned off. Are you saying search engine crawlers haven't figured out how to deal with that?

There is nothing inherent in SPAs that make load time slower. If your REST API takes 5 seconds to serve up JSON, what's to say your SSR rendered page won't also take 5 seconds?

   > Are you saying search engine crawlers haven't figured out how to deal with that?

Except for Google which has spent a tremendous amount of effort on that, yes I am.

   > There is nothing inherent in SPAs that make load time slower.

I never said they are. The difference is only for crawlers which now have to run JavaScript whereas before they could just retrieve the document and index it as it was served to it instead of trying to determine when the SPA has done the full loading of the page.

Not convincing. Even a PHP page wouldn't be indexed as it was served if it loads JS scripts. And if your page isn't running JavaScript, comparing SPA and SSR is moot. One could just use one of the hundred odd HTML templating tools to produce a static page.

Please read a bit of the history of this debate:

https://stackoverflow.com/questions/36702789/google-crawler-...

Till today the Google Crawler is the only one that gets even near good search results of SPAs. That's because they have to run a full browser to load every page to parse it. Every. Single. Page. That's why it is hard to do correctly. Read a bit about their current approach here:

https://developers.google.com/search/docs/crawling-indexing/...

Specially:

   > Keep in mind that server-side or pre-rendering is still a great idea because it makes your website faster for users and crawlers, and not all bots can run JavaScript.

Recently in 2019 Bing Bot just gave up and is using the same approach a Google:

https://blogs.bing.com/webmaster/october-2019/The-new-evergr...

So nowadays having a SPA isn't as bad for SEO as it used to be, but again, and I'll keep nailing on this, that is only because we spent the entire last decade throwing millions of dollars and hundreds of hours of engineer time to make SPAs a viable option.

Saying that an SPA returns an empty HTML page is the old days. If you're already aware of Next, Nuxt, etc. then you know that the most popular frameworks of each ecosystem already support SSR whether you're building for an MPA, SPA or hybrid.

Next basically is React and the React team implicitly admits this.

Traditionally Next.JS isn't really a tool to develop a single page application (although you could CSR every page if you want to), since single page applications are... single page. These are all multi page full stack frameworks that make use of incremental static regeneration and hydration to have the best of both worlds.

We agree though, it's just a naming thing really. I make the distinction like this because traditionally a SPA can simply be served by a CDN since it's simply a single file, meanwhile all of these frameworks either require a server to render pages on request or prerender all the applicable pages and leave a few of them to totally client-side "render".

Also note how Vercel (at the time called Zeit, mostly known for Now) called Next.JS back in 2018 when they originally released it:

https://web.archive.org/web/20180628030830/https://nextjs.or...

   > Next.js is a lightweight framework for static and server‑rendered applications.

> A web application or a website, by its very nature, is a series of small requests. When someone sends all requests in one big lump of a page, they have just defeated this very important architecture.

I have a hard time seeing this as how most SPAs work.

I see this as how most SSR systems work. Which does seem broken & bad. A user has no potential to understand this world. It's just a mainframe generating some pre-rendered experience that has no real data inside of it.

So actually, no. I think SPAs have moral value. The alternatives that have upstarted recently seem bankrupt, with no legs to stand on. I don't understand where this post comes from. There's an extremely hostile negative high-bullshit pissy attitude here, that isn't backed up by a single thing I can recognize:

> There is no sudden about it, SPA's are yet another one of the so-called "modern web" cancers of the Internet.

Most SPAs seem to be the last defender of doing what you asked for?

Reply on news.ycombinator.com