SPA Wars

 

In recent months, the lights of the FE community have been eagerly (rabidly?) engaged in debating Single Page Applications (SPAs). SPAs are web applications that load a single web document, and then use JavaScript APIs to update the document’s body content. Compared to traditional web pages, in which the browser loads individual pages, SPAs feel more like a native app. What’s not to like?

When they first took off during the 2010s, SPAs were a revelation. However, the turn against them is accelerating. Critics point out that SPAs are difficult to build, requiring more experienced developers. They are expensive to run (both environmentally & monetarily). SPAs are prone to performance problems, largely caused by client-side rendering. SPAs prioritize the developer’s experience over that of the user, and can be especially frustrating for users with accessibility issues (older devices, poor networks). SPAs lack resilience owing to their dependence upon JavaScript. The browser can recover from HTML’s failure, but when JS fails everything crashes. They are overkill for many projects. While frameworks for creating SPAs including Angular, React, Ember, and Vue are excellent solutions for the use case of large, complex apps, most projects do well to avoid them.

Here are just a few folks that have jumped into the SPA Wars fray:

• Andy Bell: The (extremely) loud minority
• Johan Halse: What to expect from your framework
• Oxford Harrison: Rethinking the Modern Web
• Zach Leatherman: A Historical Reference of React Criticism
• Simon MacDonald: Why does everyone “suddenly” hate Single Page Apps?
• SitePen: Intro to HTML-first Frontend Frameworks
• Manuel Matuzović: Why I’m not the biggest fan of Single Page Applications
• Guillermo Rauch: SPAs were a zero interest rate phenomenon
• Alex Russell: The Market for Lemons
• Laurie Voss: The case for frameworks

While tech debates are not unique in themselves, it is worth paying attention to shifting attitudes about SPAs for a number of reasons.

 

Why Are You So Nice?

First, a sort of performance of harmony and goodwill has been a recurring feature among prominent players in the JS framework space. As recently as last year’s Jamstack Conf, representatives from SolidJS, Angular, Astro, NuxtJS, and 11ty participated in a panel entitled “OSS Is Out to End the Framework Wars” underscoring the Kumbaya feelings they argue are uniting the industry. In fact, I wrote about this show of amicability because it was so marked—particularly when moderator Sara Vieira asked panelists:

Why are you so nice?

If the theater of niceness is so important, then why is it that when it comes to SPAs the kid gloves are off?

Although Laurie Voss’s rebuttal to Alex Russell’s evisceration of SPAs (linked above) doesn’t take on this question head on, his invocation of evolutionary game theory, and the Hawk Dove game specifically, does a good job grappling with this question:

while a world of doves all cooperating with each other would be nicer, indeed the best possible world, it is not the world you end up with because it is not stable. It only takes a single hawk to show up to throw it out of whack.
…
Our hawks are developers, greedily sucking up browser resources to save themselves time. The doves are customers, meekly trying to load a website and hoping it will run. If the developers were allowed to use all the resources, the site would run for nobody — an all hawk population. But on the other hand, if the website were designed to run perfectly for every single customer, in every location, on every device, then the developers would spend their entire time in optimization work and never ship anything new.

Both Voss and Russell take an economic approach to the SPA Wars, which is certainly top of mind for anyone in the FE space. But this lens offers compelling insights for those interested in following how vendors and foundations are conducting themselves in respect to the competition which has resulted from the explosion of JS frameworks.

 

What We Talk About When we Talk about SPAs (it’s React)

When I first decided to leave academia and pursue a career in FE engineering, a mentor counseled me to skip learning JS altogether, and jump right into learning React because that’s where the jobs are. Still not entirely sure how that would have worked, but I quickly understood the sentiment. Hiring managers in 2018 weren’t hiring vanilla JS developers. They wanted FE engineers that could work on Angular, Vue, and, of course, React. When I spoke to folks manning the booths at my first tech conference, We Rise, several asked me about my background in these technologies.

Today, although pundits like to speak of JS frameworks inclusively, to quote Voss, React is unambiguously “the elephant in the room.” There is quantitative support for this. Relative to other frameworks for creating SPAs, React has a large market share. 71% of developers use and are satisfied by React according to last year’s Jamstack Community Survey, although React came in 6th according to StackOverflow’s 2022 Developer Survey of most loved web frameworks and technologies. Much of this has to do with the relative youthfulness of the competition. More hiring managers look for React skills than, say, Qwik or Fresh. While Fresh only appeared last year, Facebook Meta released React a decade ago this year. Yet, for all of its seemingly quantifiable popularity, SPAs represent a tiny, tiny portion of the web. Andy Bell makes much of this in his submission to the SPA Wars, citing W3Techs’s crawl the top 10 million websites to argue:

Even if you add together React and Vue, it’s still less than 5% of all websites.

This jives with my lived experience as a FE developer at a digital marketing agency. I had a hand in a few React apps, but the majority of the time we worked with brownfield projects that heavily featured vanilla JS, JQuery, and Bootstrap. We wrestled with legacy code, often inherited from other agencies, and typically on WordPress.

React does an excellent job of accomplishing what it is intended to do: support complex, personalized, dynamic apps with long sessions and login-gated content. However, the success of what Johan Halse calls this “templating language with benefits” (incidentally, Halse’s contribution to the SPA Wars is the most amusing) makes React the war’s most visible belligerent.

 

What’s Next?

If the future isn’t going to be built using React, then what will FE engineers use? All signs point to the next generation of HTML-first FE Frameworks, multi-page applications, and, frankly, being more selective when choosing a framework to fit the project.

Frameworks today are tailored for specific use cases, and many are more performant than their predecessors. While Gatsby is most appropriate for building static websites involving rare content changes, NextJS allows users to create complicated sites with frequent server interactions. Frameworks using compilers reduce the amount of JS they ship significantly.

The documentation of most JS frameworks are very upfront about appropriate use cases. Astro’s docs, for example, not only advise prospective adopters “Astro was designed for building content-rich websites,” they also include this disclaimer:

In addition to warning app developers when not to use Astro, the docs also point them to a more fitting app development framework: Next.js. Once again, the ethos of niceness prevails!

I’ll leave it on this positive note, and look forward to the next skirmish.

Disclosure: Google (Angular) and Vercel (Next.JS) are RedMonk clients.