Why you probably want to make a SPA

I am currently working professionally on a website that is not a SPA. I'd like to rely on this experience to explain the pain points I encounter in the hope to convince you to build a SPA from scratch on you next project.

First, I'll discuss some arguments you may have against SPAs hoping to change you mind:

• Habit: you are maybe used to build website with frameworks like Django which, because of the context in which they were created, favors building websites with their template engines and to add JavaScript (most likely with jQuery) only to parts of the site, where you need the page to be dynamic. I think it's the weaker argument against building a SPA: in web development, technologies are changing and evolving and if you keep doing things out of habit, your skills will become irrelevant sooner or later. Note that I am not suggesting you should learn every new shiny thing that appears: it will take you a lot of time and it will never really pay off since the shiny thing will be replaced by something shinier very quickly. What I am saying is that we now have some mature and popular frameworks and libraries to build SPAs. They will stay around and thus are worth learning (you'll find a list near the end of this article). So, my advise is: learn one of them to expand your skill set and make SPAs your new habit!
• You've never done it: I think it is very similar to the habit argument seen above. So I'll just say: it can be learned, others have done it and have shared how they did it. So you should be able to get help to start by reading some articles or books, browsing StackOverflow or by hiring a consultant.
• Too complex for what you are doing: I have to admit these frameworks can be daunting, mostly at first. They come with new concepts, ideas and ways of doing things. And you will be running a full application in the browser of your users which is objectively more complex than just displaying a good old HTML page. I think it can be a very good argument against building a SPA. Depending on your context and current skills, a SPA may not make sense. For instance, you are prototyping or the site you are building is just for internal use or you are building it on your spare time to have fun. But for a website that you build professionally and that will release to the public, I still think you should go for a SPA even if you think you may not need it at first because you probably will need one (keep reading 😉).
• You'll ever have the need: I think you probably will have the need and sooner than you think. For better or worse, users expect more and more dynamic and interactive web pages that respond quickly without page reloads. The more your site will grow, the more you will need dynamic parts: the header to show the user is logged in, some search results to display dynamically, a small dynamic component to improve user experience on a page, a tiny embed app… And these parts probably won't stay isolated: they will have to talk/interact with each other. It will be much easier to do in a SPA: you have a top component or a store to store global information so each sub-components can be updated correctly when one changes. Without, you may need to rely on custom events, global state that you manage yourself, maybe even a page reload or you'll have different technologies you'll have to make interact (let's say jQuery because that's what you started with and ReactJS because you needed it for complex interactions). Note that part of the pain can be mitigated with a global store injected in multiple components. But it will probably end up in a strange mix of technologies.
• Find the skills: If you go for a SPA, you will need to be (or need your colleges to be) proficient in both backend and frontend development. If you already have frontend development skills or frontend developers in your team, then you're fine. If not, there are two different kind of skills you'll need:
  • UX/design/HTML/CSS skills: This is to design the page and have something both pretty and usable. Let's face it, you'll need that anyway and you probably already have it (maybe with a contractor). You can make it easier for you by relying on a CSS framework so you don't have to do all the heavy lifting (backend developers tend not to like that anyway and it's harder than it seems). Just get some basic skills to be able to do some adaptations to what the designer gives you. In the end, UX/design is a job on its own and I don't think it is fair to expect this from you (nor to expect you designers to be developers).
  • JavaScript skills with a JavaScript framework: Probably the easiest thing to get. The code will be similar to what you are already writing and most backend developers don't really mind writing JS from time to time (mostly modern JS though, not JS for IE though). And since you rely on a framework, it will handle most of the compatibility between browsers for you. Since JavaScript skills are in high demand (even in the backend side with NodeJS), learning these skills is in your interest too. You may stumble on browser specific issues from time to time or have trouble to adapt some CSS code, but you can leverage this with either getting some time to learn, hiring a contractor or a "true" frontend developer (if you can afford it).
• You can use frameworks like ReactJS or Vue.js [1] to enhance only part of the page, this way you'll have the best of both worlds: a globally static website with dynamic parts only where needed. The problem is that as stated above, as your site grow, you will have more and more of those dynamic parts and they will have to interact which will be way easier to do in a SPA.
• They come with their own set of challenges: True. You will have to organize your code differently and your backend will be more like an API than a "good old website". But this can be learned. You will also most likely need server side rendering (or SSR for short). It may require some adaptation in your infrastructure but I think it is mature for the big frameworks so it shouldn't really be an issue. You should be able to find many resources about this online for your framework of choice.

Now, I'll give some arguments about why SPAs are cool and so why you really want to do them:

• If you don't start with a SPA, it will be hard to change later. You will have to redo your whole site: the frontend in a JS framework and part of your backend so it can be used in a API fashion. That's a lot of work you can avoid by doing a SPA first.
• For better or worse, users expect JS and dynamic things. So you will need dynamic components on your site whether you want it or not. I think you should go for the easiest world and make your site dynamic first.
• All the dynamic parts are done in the same technology. You may be tempted to use jQuery to add basic dynamic parts. But as your site will grow, this will likely not suffice or become too complex to manage. So you'll add something like ReactJS or Vue.js. But then you have a weird hybrid and will have to make your jQuery parts work with your framework parts which is more complicated than it sounds and results in a poor developer experience (and once your developers will be used to modern frameworks, I think they won't be pleased to work with ever jQuery again).
• Maintaining two templates: for SEO or user experience to speed up initial page load, you might want to render the dynamic components on the server and cache them before they are rendered in the browser of the user. Since this is traditionally done in your backend templates, you'll have templates for server side rendering in your backend and JavaScript components that will take over in the browser to add dynamism. So you end up duplicating the work. Or to avoid this, you may want to render your application directly on the server. But part of the page will be rendered by your backend templating engine while some elements will be rendered by something else. It is way harder to do correctly than do all the rendering work in one technology.

Before concluding, a few word if you are currently in a hybrid site with part of it done in the "good old way" and part of it in a JavaScript framework. No matter why you got there, it's where you are. Converting everything to a SPA will be long, painful and costly. It will look a lot like a rewrite and you should avoid it if possible. Although I favour SPAs and if the developer experience won't be that great in an hybrid website, I think you should avoid the cost and risk associated with a rewrite (even of just the frontend) if possible. Most issues impact you as a developer but can be worked around to still provide a good user experience. My opinion is: use the JavaScript framework everywhere you can, always use it for new work and convert steps by steps the older part of your site as need rises. Look into SSR because you will need it sooner or later. In the end, let your new dynamic parts eat up the older static parts.

Here's a small list of frameworks (at time of writing in the beginning of 2020) that you may want to look into to build a SPA:

• ReactJS: Maybe the most popular choice right now. While it was initially design to be included in a "static" page to add some dynamism to it, you can build full SPAs with it and even mobile apps. React itself is quite small so you will probably need to add some other libraries to extend its capabilities a bit. React can be added incrementally to you site to add dynamic parts step by step.
• Vue.js: Another popular option. Very similar to React in principles (small, incremental) with a different approach that you may prefer coming from a "traditional web development" background.
• Angular: While the first two are relatively small and can be added incrementally, Angular is a big framework designed to build SPA. I don't think you will be able to enhance an existing static website with it (not easily at least). While its size may be daunting, it is complete and you probably won't need additional libraries with it. Furthermore, its tooling is mature and able to reduce the size of your code to only include the code you actually use to keep the JS you send small. Given its approach, it might be the right choice for you if you come from a Java/.NET background.
• Aurelia: Not as popular as the other options, but I think it is a sweet spot between the completeness and complexity of Angular and minimalism of React or Vue. Like Angular it is a complete framework designed to build SPA, but it focuses on web standards and tries to get out of your way so you can write standard JavaScript or include standard JavaScript libraries as easily as possible. Which makes it easier to learn and develop with (in my opinion at least).

To conclude, I am now convinced that SPAs are the way to go by default. There may still be use cases for "good old website" but I think the list is small and is getting smaller. Even if SPAs may require you to learn new skills and if they come with their own set of challenges, I think (and I hope I have convinced you) that SPAs will make you life easier in the long run.

If you have a remark or disagree, please leave a comment below.

[1]	You may say these are more libraries than frameworks. I agree, but I'll keep calling them frameworks to ease writing since I also want to include SPA frameworks like Angular or Aurelia.