4 ms·

I've found SPAs to be less work. Instead of having two templating systems (server-side and client-side) there's just one on the client side. Now I don't have to

I've found SPAs to be less work. Instead of having two templating systems (server-side and client-side) there's just one on the client side. Now I don't have to share code between client and server, but more than that, the two are logically separated. The client can just be a client, rather than a strange half-extension, half-app of the server. Secondly, if you also want to expose an API, do you put it in the server that does the rendering, or do you have a third component that the server talks to? With an SPA, there's only the app and only the API and the two are separated out by their respective duties quite cleanly. Once I started building out SPAs for data-driven applications, I never looked back to the old model of generating HTML server-side. It seems barbaric to me. The only hesitation I would have is if the SPA needs to be SEO optimized, in which case you can go either isomorphic (again, not a fan) or scrape pages via a headless browser as .html into a directory that your webserver serves up.

pier25 6y ago
I agree having two templating systems is a problem (more on this later) but by going SPA your front end now becomes massively more complex than sprinkling some JS here and there. For example you now need to manage application state which is not a trivial problem on large projects. You also need to replicate native browser UX if you're serious about making a good SPA (eg: your forms are filled when going back, the content and scroll position are preserved when going back, etc). As for the duplicate template problem, this is easily solved by doing SSR + hydration. I concede this is generally complex to set up (unless using something like Next.js) but it's worth it IMO. It's really the best of both worlds (MPA vs SPA). You are still creating components and having a sophisticated interactive UI just like in the SPA world, but front end development is greatly simplified since you're only dealing with one page at a time. Also, in many cases, you might not even need an API. How many times have you create an API only to feed your SPA? It's a lot of overhead. Also these days I don't think the decoupling argument is so strong unless you're working on a complex project with multiple teams.

pier25 6y ago

I agree having two templating systems is a problem (more on this later) but by going SPA your front end now becomes massively more complex than sprinkling some JS here and there. For example you now need to manage application state which is not a trivial problem on large projects. You also need to replicate native browser UX if you're serious about making a good SPA (eg: your forms are filled when going back, the content and scroll position are preserved when going back, etc). As for the duplicate template problem, this is easily solved by doing SSR + hydration. I concede this is generally complex to set up (unless using something like Next.js) but it's worth it IMO. It's really the best of both worlds (MPA vs SPA). You are still creating components and having a sophisticated interactive UI just like in the SPA world, but front end development is greatly simplified since you're only dealing with one page at a time. Also, in many cases, you might not even need an API. How many times have you create an API only to feed your SPA? It's a lot of overhead. Also these days I don't think the decoupling argument is so strong unless you're working on a complex project with multiple teams.