|
While there can be UX benefits to using SPAs, something I have not often seen expressed, but which I believe is that the main advantages of SPAs are for business rather than technical reasons. 1. Clear separation of concerns for front-end and back-end teams. With SPAs, the work is clearly divided into front-end and back-end parts, with the back-end team working on the server side code and the front-end team working on the static assets (HTML, JS, CSS). Both sides only communicate through a clearly defined API (e.g. REST, GraphQL, SOAP) which allows both teams to work independently of each other, and means that if there are bugs or problems, there is less confusion on which team is causing them and thus which team needs to fix them. Compare that with server side rendering using an MVC framework such as Rails. The migration and model code "obviously" belongs to the back-end team, and the static assets (JS, CSS) and views/templates belong to the front-end team, but what about the controllers and routing? Both teams are going to need to work on those parts of the codebase, and that's going to increase the need for inter-team communication and confusion on which team owns what. For example, I interviewed at a company where the front-end team was US based and the back-end team was outsourced to India, and they were moving to a SPA so the teams could work more independently. Previously they had used JSP, which meant the front-end team had to write HTML and then send it to the back-end team and then they had to coordinate how the back-end team was going to re-write the HTML as a JSP template. 2. Cheaper mobile and desktop apps. While it seems HN is very negative about non-native apps, it's not hard to see the business case of quickly and cheaply converting your website into a mobile or desktop app using something like Electron, Cordova or a web view. Even if you do plan to make a native app, the SPA and native app can reuse the same APIs, reducing the amount of work for your back-end and QA teams. 3. Flexibility in changing back-ends. While less common than the other two cases, if you decide to change your back-end code (such as Twitter moving from Ruby to Scala) if your app is an SPA you only need to recreate the APIs and don't have to rewrite all your templating code (this is less of a problem if you use a more "neutral" cross-platform template language like Handlebars). For me personally, I'm moving all my personal projects to Elixir/Phoenix from PHP, Rails or Java, and because I used server side rendering I had to convert all my templating code to EEX. |