Why You (Probably) Shouldn't Start With an SPA - Simon Hamp

# Why You (Probably) Shouldn't Start With an SPA ... - When does an SPA make sense? - So, why are SPAs bad again? - Your front-end and back-end get decoupled! - It may hurt customisability - Performance will suffer - So what's the alternative? I came across this interesting article by @gregnavis the other day. ... ### ¶ Your front-end and back-end get decoupled! **Your back-end and front-end are *always* coupled.** So trying to split them in anything but the most extreme circumstances is an exercise in futility. I think this is probably the worst part of this whole story. If your back-end team want to move in one direction, they've got to align with the front-end team. If timings and priorities don't work out, it's going to force someone to either put a hold on some work that really needs sorting out or do some grunt work just to patch over a hole that's about to appear. **This is communication overhead.** It adds risk. It adds complexity. It adds meetings into engineers' calendars. It adds friction, and stress, and distraction. **It flies in the face of that number one principle: let your teams focus and be happy.** This literally costs you money one way or another, cost that you could avoid. Deployments get unavoidably riskier in ways that are super difficult to test because testing distributed systems is really hard. Again, this might all be fine, *in the most extreme cases*, where you *need* the decoupling. Then this extra expense, and complexity, and churn-causing evil, is just a *necessary* evil that you have to learn to swallow and live with. … Sure there will be challenges too, but they won't be as big or as painful as the other challenges you'd face with an SPA. … And both of those tools needed that power and have become fantastic tools because of it. But there is one pain point that it's created that's quite hard to escape: **the customisation story for each of these is harder because of it**. How so? Basically, because each tool needs to build the assets to ship their product. And once they're built it's hard for third-parties to build on what's already there. How is it harder? Let's say I'm creating a Statamic add-on that allows CMS owners to post to social media from their control panel. As Statamic uses Vue and already has a bunch of components I can leverage, I am going to use some of them. But I'm also going to add some of my own functionality that doesn't already exist within Statamic. Now what happens? Well I build the Javascript... but wait. I can't change the bundled JS that's part of Statamic core. … And on top of that, the builds have to happen *at the client's end*, which means we're now offloading some of the responsibility of making this whole thing work to people who don't need or want to know anything about this stuff. They just want to install your thing and get on with their jobs and lives. *Why* is this such a pain though? It used to be (in other platforms) that I could just load some extra JS file into the admin interface and do what I want. … ... But if you're not building with those standard in play—I understand, it might not be possible because of browser support etc—and you want to expose your user's to third-party plugins/add-ons, then *you've* got to figure out how to make it easy for other developers. Some of that's going to require the specific implementation, the other part is going to be documentation. No matter how you cut it, it's going to be harder to get right than if you had server-side rendered views that you allow your third-party developers to load at runtime. ### ¶ Performance will suffer This isn't really an *extra* reason as Greg did touch on this a little already, but I wanted to go harder on performance. **You should never choose to build an SPA because of some supposed performance benefit.** That is the wrong hill to try and defend for many reasons, but primarily because you've got the whole of the web stack—on horses, with bazookas—nipping at your heels. … Sure, you can argue some of this advancement may have been *driven* by SPAs and their apparent benefits. But there's some inevitability to all of this (both the appearance of SPAs and the advancement of HTTP) which makes the whole argument moot in my opinion. As adoption and overall performance of the web platform increases, SPAs will even start to feel slow in comparison. Some feel slow already!