The Mirage of Single Page Applications
When discussing front-end applications, I usually see people instantly go for a Single Page Application (SPA). It's almost as if an SPA is viewed as the only way to build a modern front-end for your application, regardless of your requirements. Is this a good thing or should we really pay more mind to the alternatives? Previously, we have discussed how we got started with our prototype of Tracepaper. Let's take a deeper dive into the illusion of SPAs why we chose to build one.
It all depends on the context. When it comes to SPAs, I'll be the first to ask, do we really need that? In my opinion, SPAs introduce quite a bit of complexity. Usually its a completely different stack that we have to learn and support in addition our existing (back-end) application. Depending on the size of your project or organization, this could even mean setting up a completely new CI/CD pipeline. And then we haven't even discussed the rapid development speed of these frameworks, often releasing a new version every six months. For a tech start-up, this might be seen as an advantage and chance to always work with the latest technologies. For an enterprise application, however, this can be a giant drawback.
It is an absolute must to look at the context we're in as it defines the terms of what a good fit would be. What kind of organization am I working for? Is it a large enterprise, where business process continuity is the most important aspect, or is it a smaller tech-focused start-up? We also have to ask ourselves the question, what do I really need an SPA for? Do I have very specific requirements, where an SPA is simply the better option? Perhaps your application requires complex user interaction or, maybe, we just need a simple web interface.
If we're not certain that we need a full-fledged SPA, maybe, we can simply get the same result by opting for a Server Side Rendered (SSR) front-end, that is served by a back-end application. Even though this approach has been around for quite some time, it is still a very good architecture to choose. And it's much simpler to implement and support long term. It is even getting more and more popular with companies such as Basecamp promoting this way of working. An SSR application even has advantages over SPAs when it comes to public-facing websites. Since SPAs are fully client-side rendered, it lacks support for Search Engine Optimization (SEO). On the other hand, this is where SSR really shines. In most cases, a SSR front-end is more lightweight and faster to serve to the client as well.
At this point, you're probably quite sure we opted for a Server Side Rendered approach, but we actually decided to build a Single Page Application for Tracepaper with VueJS. Both Bo and I have a deep founded love for SSR applications, but for Tracepaper, that wouldn't really make sense. In a previous post, Bo wrote about how a good fit for Serverless is one of our most important drivers. The Draftsman Engine, also known as the generator, generates completely serverless applications. Since we want to keep our response times snappy, and we want to eliminate cold starts to optimize the user experience, we have decided to not build a 'back-end' to send the HTML over the wire. The elimination of cold starts is the primary reason why we chose to go with a SPA, even though we don't have any complex user interaction requirements. On top of that, Tracepaper is a private environment, so SEO support isn't a factor here.
Right now, we are happily building Tracepaper in VueJS. And in case you wonder why we chose to go with VueJS. Well that's actually quite a simple answer. This was the first framework I ever built a SPA with, and to me it seems to be one of the most straight forward to use. Along the way I even convinced Bo to give it a try, and now we both enjoy working with it whenever we need an SPA.
In the next post I would like to give you more insight into our design process and the Power of Utility-first CSS. Subscribe to our newsletter to get notified when we have a new post ready.