3 ms·
I've thought about this a lot and my position is that it all boils down to how bad is the result when you apply any of these approaches wrongly. Turns out stat
by Tade0 6y ago
I've thought about this a lot and my position is that it all boils down to how bad is the result when you apply any of these approaches wrongly.
Turns out static pages with JS on top can be even worse than badly done SPAs - especially when the server infrastructure is lacking and a single request takes a significant amount of time.
- ljm 6y agoSurely all of the money invested into that SPA could be redirected into a simpler full-stack app, with sprinkles of progressive JS? On the one hand you have a shared-nothing architecture that serves HTML and can enjoy varying forms of caching. On the other you have an application that still depends on a server, but replaces all of that simplicity with a stateful client-server architecture that requires _more_ infra to manage, at a greater expense.
- Tade0 6y agoThere's one important factor you're missing: for lack of a better word - "staffability". Just about every programming language has also a web framework implemented in it, so if you want to create a full-stack web app, the range of options is just dazzling, which results in a highly fragmented ecosystem. Meanwhile on the front-end there's essentially one language(with different flavours) and 3-4 leading frameworks, so once a developer has these covered, they can be hired to do anything in this part of the stack. The overall result is that it's easier to scale work if you offload it to the front-end, because by the time you found your <insert highly specific language/framework combination>, your front-end developers would have done most of the work twice over. There are many more reasons why you would want a SPA instead of a full-stack app, but this is one of the strongest.
- deleted 6y ago[deleted]