Single Page Application Is Not a Silver Bullet

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.

Is anything ever?

Why is there such a strong tendency towards treating things as a this-is-it(-this-time-for-real) thing? This only confuses people and muddles up expectations.

I work in ecommerce and I feel it’s somewhere in between. We need to build for seo optimizations for the category/product experiences yet there is a lot of application like intersections, especially on the category filtering and the product sku selections. Quickshops, In store pickup modals, user specific recommendations trays, add and edit reviews et all. Different caching for server render at the edge vs personalized components adds another layer. Being able to serve with a shared routing scheme both client side (for improved performance) and server side for faster initial page load and seo on non-Google crawlers is a tough problem. Especially when you add in client hydration of the redux store. That parse time is a real killer on mobile. You add in service workers and prefetching and the complexity ratchets up further. The other issue we deal with is marketing pixels and trackers. But that’s another story. There is a ton of complexity in building a highly functioning ecommerce site.

>Rather than build a full SPA I can sprinkle a few components here and there on pages that are highly interactive

In practice, I've found "hybrid" apps hard to pull-off. In my experience, the question becomes, where do you draw the line?

Take the simple/common case of presenting a list view. From the list, you want to allow the user to click to view details, which you then present dynamically--maybe in an overlay. It's a great user-experience. Everything pops, the user can easily return to the list view without a full page-load, etc.

But, you now have a details view that is not reachable directly via its own URL. So, you use the framework's routing capability to assign one. Now, things are getting weird, because you're routing a dynamic view on top of a server-rendered one. You'll likely end up finding that you'll have to route the server-view as well for general navigability. And, you also have to account for people hitting the details URL directly (i.e. render the proper underlying server view, then let the client route to the dynamic URL).

Not to mention the back-button.

All manageable, of course. But, it gets messy to maintain such a hybrid approach. By the time you've integrated the routing, etc. the question becomes why hybrid? Why not full SPA?

If your app is super-simple wherein you're just doing the tiniest bits of dynamic stuff and you don't need things like first class URLs, navigability among dynamic content, etc. then, yeah, maybe. But, that's not really a hybrid-SPA solution because there's no SPA there.

In fact, I'm not sure there is a such thing as "hybrid-SPA". By definition, seems it's either a SPA or it's not.

This isnt a problem with SPAs per se, just a problem with the app's design.

You can split SPAs into multiple apps that communicate. The main app would be loaded on open and the rest of the source could be pulled in when needed.

React is not the cause of slow loads, your architecture is.