Considerations about the tech stack and architecture

SPAs require JavaScript. A non-trivial number of users have JavaScript disabled (the last statistics I saw were somewhere between 1 in 20 and 1 in 50 users with JS disabled). Serving a site that doesn’t work to these users is terrible UX; adding a fallback so that the site does work for them means basically writing exactly the same software as we would if it wasn’t an SPA in the first place. One way you lose users, the other way you’re doubling the work you have to do.

Many of the benefits that SPAs bring can be included in other ways instead - there are libraries like Turbolinks that can make navigation smoother, and front-end frameworks or even just custom JS that can do dynamic data pulls and page updates.

Finally and most crucially, SPAs are not something that every developer is familiar with. The default, as far as one exists, is a multi-page web app, which the vast majority of developers are familiar with. As far as a project like this is concerned where we’re relying on volunteer time to build everything, we want to maximise the number of potential contributors, not reduce it.

5 Likes