3 ms·
I have similar kind of experience and made similar conclusions for myself. In addition to the points you have made already, I would like to add that almost eve
by cybrox 2y ago
I have similar kind of experience and made similar conclusions for myself.
In addition to the points you have made already, I would like to add that almost every larger project needs a lot of business logic on the backend side anyways. There is no possibility to have this logic in the frontend and there never will be (for security reasons at least). So given these circumstances, we usually already have quite a few people experienced with - and very efficient in - these backend technologies.
So why would I spend a lot of time re-creating all kinds of routing, models, properties, etc. in an SPA? We currently run an Ember SPA for our largest project and 1/3+ of the time spent on it is pure waste because it is simply additional work to facilitate the use of this SPA at all.
In every project I've worked on, the interactive and dynamic elements actually used that are written in JS end up being a lot fewer than originally anticipated. Unless you're building a product where the majority of the functionality relies on instant, realtime updates such as maybe a streaming site with chat, etc., building, maintaining and extending an SPA is a huge overhead that offers little benefit over "dumb", static views with small, isolated interactive components.
- diggan 2y ago> Unless you're building a product where the majority of the functionality relies on This is a huge problem in the ecosystem. People want a landing page, so they reach for some full-stack SPA backend+frontend framework that is hip today, which is absolutely bananas. Sure, if you're building web app with lots of dynamic and interactive elements, go crazy, because you'll probably need it, lord knows you'll get tangled up in state management no matter how clever you think you are. But for websites that aren't trying to became the new Google Maps/Figma/Whatever, simple and basic templating patterns won't just be faster to develop, but easier to maintain and a better experience for your visitors to use.
- zelphirkalt 2y agoMy experience exactly. Why one would do that anyway? Not listening to experienced engineers and being blinded by modern FE hype. Thinking just because many other businesses do it, one has to do it too. Then decision made by non-technical or not too technical management people. And sure enough, then came the self inflicted workload. "Oh we need to change the router.". A problem you do not have with any popular mature web framework on the backend. "We need to upgrade to NextJS version 149, for feature blablub." Which would come naturally with something like Django or other traditional web framework. "We need to upgrade NodeJS!" ... and so on and on. While all of what the FE actually did could have been just render static templates and a few lines of script. Companies choose their own downfall by following the FE hype trains. The result are the shitty web apps, that don't need to be "apps" in the first place, but could simply have been static pages. It is quite a comedy show and I would laugh, if it did not affect me negatively.