DEV Community

Cover image for Routing: I’m not smart enough for a SPA
Taylor Hunt
Taylor Hunt

Posted on

Routing: I’m not smart enough for a SPA

In part 2, I glossed over a lot when I wrote…

I decided this called for an MPA. (aka a traditional web app. Site. Thang. Not-SPA. Whatever.)

Okay, but why did I decide that? To demo the fastest possible Kroger.com, I should consider all options — why not a Single-Page App?

Alright, let’s try a SPA

While React was ≈2× too big, surely I could fit a SPA of some kind in my 20kB budget. I’ve seen it done: the PROXX game’s initial load fits in 20kB, and it’s smooth on wimpier phones than the Poblano.

So, rough estimate off the top of my head…

Source Parse size gzip size
preact 10.6.6 10.2kB 4kB
preact-router 4.0.1 4.5kB 1.9kB
react-redux 7.2.6 15.4kB 5kB
redux 4.1.2 4.3kB 1.6kB
My components1 5.9kB 2.1kB
Total 40.3kB ≈14.6kB
  • The HTML is little else than <script>s, so its size is negligible.
  • The remaining 5.4kB is plenty for some hand-tuned CSS.
  • This total is pessimistic: Bundlephobia’s estimate notes “Actual sizes might be smaller if only parts of the package are used or if packages share common dependencies.”

Seems doable.

…But is that really all the code a SPA needs?

Some code I knew I’d need eventually:

Buuuuuut I don’t have concrete numbers to back these up — I abandoned the SPA approach before grappling with them.

Why?

It’s not always about the performance

I didn’t want to demo a toy site that was fast only because it ignored the responsibilities of the real site. To me, those responsibilities (of grocery ecommerce) are

🛡 Security even over accessibility
Downgrading HTTPS ciphers for old browsers isn’t worth letting credit cards be stolen.
You must protect data customers trust you with before you can use it.

Accessibility even over speed
A fast site for only the able creates inequality, but a slower site for everyone creates equality.
Note that speed doubles as accessibility.

🏎️ Speed even over slickness
Delight requires showing up on time.
Users think fast sites are more easy-to-use, well-designed, trustworthy, and pleasant.

Accordingly, I refused to compromise on security or accessibility. A speedup was worthless to me if it conflicted with those two.

Security

MPAs and SPAs share most security concerns; they both care about XSS/CSRF/other alphabet soups, and ultimately some code performs the defenses. The interesting differences are where that code lives and what that means for ongoing maintenance.

(Unless the stateless ideal of SPA endpoints leads to something like JWT, in which case now you have worse problems.)

Where security code lives

Take CSRF protection: in MPAs, it manifests in-browser as <input type=hidden> in <form>s and/or samesite=strict cookies; a small overhead added to the normal HTTP lifecycle of a website.

SPAs have that same overhead2, and also…

  • JS to get and refresh anti-CSRF tokens
  • JS to check which requests need those tokens, then attach them
  • JS to handle problems in protected responses; to repair or surface them to the user somehow

Repeat for authentication, escaping, session revocation, and all the other titchy bits of a robust, secure app.

Additionally, the deeper and more useful your security, the more the SPA approach penalizes all users. That rare-but-crucial warning to immediately contact support? It (or the code to dynamically load it) can either live in everyone’s SPA bundle, or only burden an MPA’s HTML when that stress-case happens.

What that means for security maintenance

With multiple exposed APIs, you must pentest/fuzz/monitor/etc. each of them. In theory that’s no different than the same for each POSTable URL in an MPA, but…

Sure, 8 out of 9 teams jumped on updating that vulnerable input-parsing library. Unfortunately, Team 9’s senior dev was out this week and the juniors struggled with a dependency conflict and now an Icelandic teenage hacker ring threatens to release the records of anyone who bought laxatives and cake mix together.3

This problem is usually tackled with a unified gateway, which can inflict SPAs with request chains and more script kB to contact it. But for MPAs, they already are that unified gateway.

Accessibility

Unlike security, SPAs have accessibility problems exclusive to them. (Ditto any client-side routing, like Hotwire’s Turbo Drive.)

I’d need code to restore standard page navigation accessibility:

  • Remember and restore scroll positions across navigations.
  • Focus last-used element on back navigations (accounting for autofocus, tabindex, JS-driven .focus(), other complications…)
  • Focus a page-representative element on forward navigation, even if it’s not normally focusable. Which is filled with gotchas.

And do all that while correctly handling the other hard parts of client-side routing:

  • Back/forward buttons
  • Timeouts, retries, and error handling
  • User cancellations and double-clicks
  • History API footguns — see its proposed replacement’s reasoning
  • Only use SPA navigation if a link is same-origin, not an in-page #fragment, the same target, needs authentication…
  • Check for Ctrl//Alt/Shift/right/middle-click, keyboard shortcuts to open in new tabs/windows, or non-standard shortcuts configured by assistive tech (good luck with that last one)
  • Reimplement browsers’ load/error UIs, and yours can’t be as good: they can report proxy misconfiguration, DNS failure, what part of the network stack they’re waiting on, etc.

In theory, community libraries should help avoid these problems…

The majority of routers for React, and other SPA frameworks, do this out of the box. This has been a solved problem for half a decade at least. A website has to go out of its way to mess this up.

— warning: HackerNews

We use those libraries at work, and let me tell you: we still accidentally mess it up all the time. I asked a maintainer of a popular React router for his take:

We can tell you when and where in the UI you should focus something, but we won’t be focusing anything for you. You also have to consider scroll positions not getting messed up, which is very app-specific and depends on the screen size, UI, padding around the header, etc. It’s incredibly difficult to abstract and generalize.

Even worse, some SPA accessibility problems are currently impossible to fix:

For example, screen readers can produce a summary of a new page when it’s loaded, however it’s not possible to trigger that with JavaScript.

— Why Gatsby is better with JavaScript § Accessibility

Also, remember how speed doubles as accessibility?

For accessibility as well as performance, you should limit costly lookups and operations all the time, but especially when a page is loading.

— Accessibility and Performance · Marcy Sutton

Emphasis mine — if you should avoid heavy processing during page load, then SPAs have an obvious disadvantage.

A boy sits next to a skeleton on a sofa. The boy plays the cello, the skeleton holds his head in regret. Or it’s preclempt with the beauty of music? Either way, it dropped its scythe.

I needed something to break up the text.

Let’s say I do all that, though. Sure, it sounds difficult and error-prone, but theoretically it can be done… by adding client-side JS. And thus we’re back to my original problem.

Sometimes it is about the performance

You probably don’t have my 20kB budget, but 30–50kB budgets are a thing I didn’t invent. And remember: anything added to a page only makes it slower.

Beyond budget constraints, seemingly-small JS downloads have real, measurable costs on cheap devices:

Code Startup delay
React ~163ms
Preact ~43ms
Bare event listeners ~7ms

Details in Jeremy’s follow-up post. Note these figures are from a Nokia 2, which is more powerful than my target device.

I see you with that “premature optimization” comment

The usual advice for not worrying about front-end frameworks goes like this:

  1. Popular frameworks power some sites that are fast, so which one doesn’t matter — they all can be fast.
  2. Once you have a performance problem, your framework provides ways to optimize it.
  3. Don’t avoid libraries, patterns, or APIs until they cause problems — or that’s how you get premature optimization.

The idea of “premature optimization” has always been more nuanced than that, but this logic seems sound.

However… if you add a library to make future updates faster at the expense of a slower first load… isn’t that already a choice of what to optimize for? By that logic, you should only opt for a SPA once you’ve proven the MPA approach is too slow for your use.

Even 10ms of high memory spikes can cause ZRAM kicking in (suuuuper slow) or even app kills. The amount of JS sent to P99 sites is bad news

ZRAM impact is system wide. Keyboard may not show up quickly because the page used too much.

Having less code can make everything faster.

— Alex Russell

I had performance devtools open and dogfooded my own code as I made my demo. Each time I tested a heavier JS approach, I had tangible evidence that avoiding it was not prematurely optimizing.

It’s not just bundle size

Beyond their inexorable gravity of client-side JavaScript, SPAs have other non-obvious performance downsides.

Fresh loads happen more than you think

The core SPA tradeoff: the first load is slower, but it sets up extra code to make future interactions snappier.

But there are situations where we can’t control when fresh loads happen, making that one-time payment more like compounding debt:

Page freezing/eviction
Mobile browsers aggressively background, freeze, and discard pages.
Switching apps/tabs unloads the first annoyingly often — ask any iOS user.
Browser/OS updates and crashes
Many devices auto-update while charging.
I’m sure you can guess whether SPAs or MPAs crash more often.
Deeplinks and new tabs
Users open things in new tabs whether we like it or not.
Outside links must do a fresh boot, weakening email/ad campaigns, search engine visits, and shared links.
Multi-device usage really doesn’t help.
In-app browsers share almost nothing with the default browser cache, which turns what users think are return visits into fresh load→parse→execute.
Intentional page refreshes
Users frequently refresh upon real/perceived issues, especially during support. The world considers Refresh ↻ the fixit button, and they’re not wrong.
SPAs often refresh themselves for logins, error-handling, etc.
A related problem; you know those “This site has updated. Please refresh” messages? They bother the user, invoke a refresh, and replicate a part of native apps nobody likes.

But when fresh pageloads are fast, you can cheat: who cares about reloading when it’s near-instant?

SPAs are more fragile

While “rebooting” on every navigation can seem wasteful, it might be the best survival mechanism we have for the Web:

These errors come, in large part, from users running odd niche or out-of-date browsers with broken Javascript or DOM implementations, users with buggy browser extensions injecting themselves into your scope, adblockers blocking one of your <script> tags, broken browser caches or middleboxes, and other weirder and more exotic failure modes.

— Systems that defy detailed understanding § Client-side JavaScript

A line chart titled “Errors grouped by browser”. The chart and samples are illegible to me: my only takeaway is that the y-axis tops out at 3,000.

A typical Datadog error summary.

Given that most bugs are transient3, simply restarting processes back to a state known to be stable when encountering an error can be a surprisingly good strategy.

3 131 out of 132 bugs are transient bugs (they’re non-deterministic and go away when you look at them, and trying again may solve the problem entirely), according to Jim Gray in Why Do Computers Stop and What Can Be Done About It?

— Erlang in Anger § On Running Software

Overall, SPAs’ reliance on client JS makes them fail unpredictably at the seams: the places we don’t control, the contexts we didn’t plan for. Enough edge-cases added up are the sum total of humanity.

When a SPA is a good choice

Remember PROXX from earlier? It did fit in 20kB, but it also doesn’t worry about a lot of things:

  • Its content is procedurally generated, with only a few simple interactions.
  • It has few views, a single URL, and doesn’t load further data from a server.
  • It doesn’t care about security: it’s a game without logins or multiplayer.
  • If it weren’t accessible4 or broke from client-side fragility… so what? It’s a game. Nobody’s missing out on useful information or services.

PROXX is perfect as a SPA. You could make a Minesweeper clone with <form> and a server, but it would probably not feel as fun. Games often should maximize fun at the expense of other qualities.

Similarly, the Squoosh SPA makes sense: the overhead of uploading unoptimized images probably outweighs the overhead of expensive client-side processing, plus offline and privacy benefits. But even then, there are many server-side image processors, like ezgif or ImageOptim online, so clearly there’s nuance.

You don’t have to choose extremes! You can quarantine JS-heavy interactivity to individual pages when it makes sense: SPAs can easily embed in an MPA. (The reverse, though… if it’s even possible, it sounds like it’d inherit the weaknesses of both without any of their strengths.)

But if SPAs only bring ☹️, why would they exist?

We’re seeing the pendulum finally swing away from SPAs for everything, and maybe you’ll be in a position someday where you can choose. On the one hand, I’d be delighted to hand you more literature:

On the other hand…

Please beat offline-first ServiceWorker-cached application shells or even static HTML+JS on a local CDN with a cgi page halfway across the globe.

— Mihail Malo

This is true. It’s not enough for me to say “don’t use client-side navigation” — those things are important for any site, whether MPA or SPA:

  • Offline-first reliability and speed
  • Serving as near end-users as possible
  • Not using CGI (it’s 2022! at least use FastCGI)

So, next time: can we get the benefits that SPAs enjoy, without suffering the consequences they extremely don’t enjoy?


  1. Estimated by ruining my demo’s split Marko components and checking devtools on the homepage. 

  2. Some say that instead of CSRF tokens, SPAs may only need to fetch data from subdomains to guarantee an origin header. Maybe, but the added DNS lookup has its own performance tax, and more often than you’d think

  3. No, this was not an incident we had. For starters, the teenagers were Luxembourgian. 

  4. PROXX actually did put a lot of effort into accessibility, and that’s cool. 

Discussion (19)

Collapse
jon49 profile image
Jon Nyman

With service workers you can get the same benefits of an MPA but have everything be instant on your device by streaming the HTML from the service worker itself. The main downfall of this is that the service worker isn't mature yet in that I can't load modules on-the-fly with dynamic imports. I created my own importer to do this but it turned into so much work maintaining it all that I just ended up using a library similar to HTMX (my own HTMF).

Apps for the general public I think MPAs make a lot of sense. Apps for internal business I think something like HTMX (or HTMF :-)) can make really good sense (a mix between MPA and SPA).

It really depends on the constraints of the project to determine if a full SPA is needed or a mixture or just an MPA.

I haven't used SPAs a lot but one thing that I don't like is the repaint between pages when I'm doing the MPA/SPA with the service worker when I don't stream the HTML from the service worker. It is much cleaner to do the latter. But, like I said before, it is difficult to do when you don't have a framework built that way already as most people are focused on SPAs rather than a service worker app with streamed HTML for each page.

Collapse
tigt profile image
Taylor Hunt Author

I got on-the-fly imports working well in Marko, since its Rollup plugin already has logic for server vs. client bundles. (I lied to @marko/rollup in just the right way so that it also made out a third, tree-shaken bundle that thought it was for the server, then I transpiled it for the SW environment.)

That repaint between pages is interesting if you still have it — Chrome was the last browser to remove that flicker when it shipped Paint Holding in 2019, I thought. When and where are you seeing it?

Collapse
jon49 profile image
Jon Nyman

Yeah, I guess the repaint issue is because I created my own "spa" framework. Basically, it isn't SPA but kind of is. Since I have separate HTML pages cached with a service worker and then I have all the code on the front end (since I have the app as an offline first app). So, each time I go to a different page it has to load the data on the fly after changing the page. So, I have a list of my weight for the year with comments and such and when I go to that page it takes time to get all that data onto the page since it has to load the JS first before adding the dynamic data. If I did it from the service working the user wouldn't notice all that. I guess that is why SPAs do their own routing so it doesn't seem so janky. I don't really work with SPAs much since I'm more of a back end person but I imagine in a SPA they create the page first before moving over to the new page. Also, like you, I don't like the size of JS on the front end and frameworks seem to be pretty beefy and cause issues for the user - like you were mentioning. That is why I've been pushing for doing everything from the service worker. I was thinking of just loading all the code in the service worker and just streaming the HTML from there.

But there are also issues with service workers. Like, when using a service worker ideally you have the SHA unique characters appended to your file name. But that is hard to do without getting involved in the SPA world. So, tooling isn't really great when doing it this way. But maybe I'll pick it up again and try it again. I haven't been doing as much coding on the side as I have in the past as I've been trying to spend more time with the family before they leave the house :-). But I get some free time here and there.

Thread Thread
tigt profile image
Taylor Hunt Author

It’s very interesting that you and I seem to be converging on the same ideals, but from opposite directions. You might like the next post in this series for that especially.

Collapse
jon49 profile image
Jon Nyman

Oh, and the on-the-fly imports (dynamic imports) I was talking about I was more talking about doing it in a service worker. Which isn't allowed in service workers yet - but I have created my own, but it is a bit of a pain to do :-) compared to just having it work out of the box.

Thread Thread
tigt profile image
Taylor Hunt Author

Yeah, I reused the Rollup ecosystem’s code for that, myself. Pretty odd that import still isn’t allowed in Service Workers, but at least importScripts() lets us fake it.

Thread Thread
jon49 profile image
Jon Nyman

Yeah, actually, I'm looking for specifically dynamic imports so I only need to load the code is only being used at the moment rather than having to load all the pages code at once. So this:

developer.mozilla.org/en-US/docs/W...

For regular imports they work with the latest Chrome as of earlier this year (if I remember right). But Firefox still doesn't have it.

But this discussion has been great. It's made me think of how I can simplify my offline app more using a truer MPA style coding.

Yes, I'm definitely looking forward to your next post! Thank you for putting all the time and effort into these posts!

Collapse
frontsideair profile image
Fatih Altinok

Love the header image.

I'm mostly convinced that client-side routing is almost always bad news. I was already disillusioned with SSG and currently enjoying Remix a lot. So I'm looking forward to the next installment.

Collapse
tigt profile image
Taylor Hunt Author

Yeah, I think at this point I like everything about Remix’s technical approach except for React itself. Remix’s principles and fundamentals make a lot of sense to me — but React’s tradeoffs clash with them sometimes.

Collapse
frontsideair profile image
Fatih Altinok

I'm also conflicted about it. Progressive hydration and streaming SSR with Suspense ease some of the pain, but there are still some drawbacks. On the other hand, since changing the DOM is unavoidable in most apps, I like using a single mental model for building and modifying the DOM, and React is a pretty stable choice. I'm still evaluating new choices that I see.

Thread Thread
tigt profile image
Taylor Hunt Author

I agree wholeheartedly. With those priorities, you might as as interested in Marko as I was. It keeps the mental model of a tree of components, but is much more efficient with SSR and doesn’t need a client-side router.

Thread Thread
frontsideair profile image
Fatih Altinok

Marko has been on my radar for a long time, but I guess unfamiliarity was a significant barrier for me. There's also SolidJS which has similar claims, for that matter. I guess at some point I'll have to bite the bullet and write a small project in either one to gain some first-hand experience.

Collapse
jon49 profile image
Jon Nyman

Your post inspired me to rewrite my app in an MPA style with minimal JS. Granted it is an offline app so it is all JS but it is written from a service worker. It really simplifies things. Make a post on a form - no problem, just refresh the page! I still get the occasional white flash on the page when going between pages, which is annoying. But the simplicity is amazing.

I'm excited for your next posts!

github.com/jon49/WeightTracker/tre...

Collapse
tigt profile image
Taylor Hunt Author

Oh damn! I am going to be reading the heck out of this code — you may have pulled off what I was trying to demonstrate for the next post faster than I could!

Collapse
jon49 profile image
Jon Nyman • Edited on

lol, Thanks. Yeah, it isn't the first time that I've attempted this. That's why I was able to do it so fast. I've been fascinated about running an app from a service worker ever since I heard Chris Love say that service workers are the death of SPAs.

I have actually created a module loader to load JS on-the-fly from a service worker so you can have a pretty large app. But it was too much work and I just wanted to finish the app. So, I ended up making it with HTMF and Razor Pages (C#).

github.com/jon49/MealPlanner/blob/...

Chris Love's website: love2dev.com/

Collapse
cmgustin profile image
Chris Gustin

I’m loving these articles, even if some of it is a little over my head on the technical side. I’m blown away at how deeply you know the topics, and the writing is not just clear and communicative, it has style and voice which is rare in technical writing.

Out of curiosity, the references are really thorough. Are you constantly reading and bookmarking things to use day-to-day, or do you search out what you need and research as you write?

Collapse
tigt profile image
Taylor Hunt Author

You guessed it: I have an ongoing bookmarks folder for this. Sometimes I do search for things when I need a stronger case or a more up-to-date link, though.

Collapse
jon49 profile image
Jon Nyman

Another hard thing about MPAs is that I haven't been able find documentation on how to build robust MPAs. That knowledge is hard to find with searches pigeon holing old web pages. So, e.g., how do you prevent a double click? If I remember right from what I've read you need to do a redirect after a form submission and somehow that stops the double click. There are other patterns like that, but where to find them?

Collapse
tigt profile image
Taylor Hunt Author

Ah, you’ve got two concepts there — which I think reinforces your point that this knowledge isn’t easily accessible.

Redirecting after form submission avoids the “Really resubmit this data?” dialog when hitting Back after a <form method=post>, known as the Post/Redirect/Get technique.

Preventing double-clicked form submissions without JavaScript doesn’t have a single name: each framework tends to have its own (WordPress reuses WP_NONCE, for example). I like calling them “idempotency keys/tokens” after Stripe’s API popularized the term. (Stripe uses an HTTP header, but as you probably suspect it’d be <input type=hidden> for no-JS functionality, such as the django-idempotency-key module.)

Idempotency keys are a good idea even if you have JS briefly disable a submit button after the first click, because it covers network hiccups too. For example, browsers have built-in HTTP retry logic, but if the server’s response was the one that got lost along the way, the browser+network combo could cause duplicate requests.

As for where to find these techniques… I also wish I knew! I had to find them the hard way, almost exactly like you described. Heck, I only learned about idempotency keys last month.