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:
- 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).
- You can use frameworks like ReactJS or Vue.js  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).
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.
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.
|||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.|