3 ms·
Coming from similar background as author (various legacy web apps with all the challenges of learning now useless js frameworks) - I’m now have a different opin
by sheeshkebab 8y ago
Coming from similar background as author (various legacy web apps with all the challenges of learning now useless js frameworks) - I’m now have a different opinion:
SPA approach should be the default unless you have specific requirements to add html SSR (and even then google is pretty good at indexing public spa content too).
So, respectfully disagree.
- acjohnson55 8y agoYou're disagreeing, but not providing any justification for why SPA should be the default. Why do you think this?
- a_wild_dandan 8y agoI'll try adding to the conversation by at least justifying why I like SPAs: clearly decoupled front-end/back-end logic, likewise parallel updates/deployment from different teams, back-end mocking, minimal data updates for DOM changes, easy integration with microservices, powerful front-end tools to deal with client feature creep (e.g. interactive widgets), reusable UI components, easy migration to multiplatform desktop apps (e.g. Electron), possible single language for everything (JS, rather than a mishmash of JS/HTML/CSS/Python/PHP/etc), easy integration with hybrid or SSR stacks ( Next.js, Gatsby, etc). But all this is just rationalization for one simple fact: I'm vastly more productive building SPAs. I know the tools, and I can quickly deliver anything from simple sites to richly interactive experiences very quickly. I can go from SPA -> SSR (via, say, Gatsby) easily. But going the other direction from SSR to something interactive has been far more painful for me. That's why I default to SPAs and adjust from there.