[vincentriemer]

As an avid developer of SPAs (currently working on one for my own blog frontend) I'd say a lot if this stems from people being convinced SPAs 1) provide a faster development cycle, 2) they believe that they've offloaded all need for optimization on the framework they use and 3) "serious" development teams build SPAs.

Anecdotally I find SPAs, while I'm more comfortable developing them, will take longer to build. You need to pay more attention to the quirks the author mentions and you need to spend more time explicitly optimizing your code. I like this paradigm because if there is inconsistent logic, poor performance, or other issues, it's my fault and I have the opportunity to fix it.

As a counter example to the ones mentioned in the above article, around 2 years ago I build a drum machine webapp entirely in JavaScript/React (https://io808.com). This has ~17 JS library dependencies and ~6000 lines of source code but the gzipped bundle size comes out to ~97 KB.

Just because you're building an SPA doesn't mean you need to spend less time optimizing your code, in fact it likely means the opposite.

[jamra]

I’ve used React in the past and I believe what you’re mentioning is very React specific.

Angular has lazy and eager loading, which reduces bundle sizes. It also doesn’t require so many frameworks to manage manually. They are still there, but they are sort of imported automatically by angular cli so it doesn’t take a lot of mental overhead.

Some issues I had, though, were with bugs in newer versions. Some of those issues stopped development outright.

Another issue I have on one team is the fallacious notion that the front end programmer will take over the front end so no one else will need to think about it. Business specific logic seems to be out of reach for my particular developers, which prolongs the development cycle.

The benefit of state management and inter component communication have to be balanced the the practicality of who is doing the work and if those people can take ownership of all associated areas touched by the SPA.

[swyx]

is there a way for React to do eager loading? i asked around on twitter but got told "thats not React's job".

[throwaway284534]

Loading of modules can be managed by Webpack's chunk configuration. Each import declaration can be turned into a promise that executes your code when all dependencies are fetched.

[connorelsea]

I think the react dev team is currently working on an official async loading pattern for a future update. But currently webpack, rollup, etc. offer dynamic import, code-splitting, tree-shaking

[shados]

Not sure if that's what you mean, but when Andrew Clark keeps mentioning the "async" word, he means async rendering, not async loading.

[connorelsea]

What is an unsolved async loading problem in React you are experiencing?

[shados]

I don't have any issues with async loading. I'm just saying that I believe what you are referring to when you say the React team is working on an official async pattern is not actually async loading, but async rendering.

At least every time one of their members said the word async in the last couple of weeks/months, it's what they referred to, and it's a completely different (and unrelated) thing. I can't read your mind though, so I'm just guessing.

[hazza1]

Not sure many people think SPAs provide a faster development cycle, individual pages are always going to be more simple.

You'll get code reuse but that's trivial to get working elsewhere, you just save on redownloading shared code.

[sumoboy]

Missing out of this conversation is the operational side. Moving beyond localhost, analytics, seo, content mgmt that create a whole different set of challenges vs non-spa.

Likes others have mentioned, it's about the UX that you want to provide that dictates the SPA path.