|
I am a primarily frontend learning fullstack guy. I've been working in this space for about 10 years. I used jQuery, Angular, Angular 2, React. I did JavaScript then TypeScript. I configured freakin Gulp, Grunt, Brunch, Webpack 1 to 5, and now Vite, idk maybe in the future Eggpancake or something. I even had the unfortunate stint on working on configuring Bazel to a frontend monorepo. So I get it, I get the pain. As someone who lives and breathes JS/TS, even I myself feel the pain. I can't tell how many times I looked at other languages like Go, Ruby, Python, or even newer ones like Elixir, to see if I can just simplify this whole madness with HTMX, Datastar, etc. To be honest. I still haven't found one that's even incrementally better than the current SPA stack (and no, I don't use NextJS or React Server Components). A bunch of the technologies above simply just mix and match with a lot of impedance mismatch. It all boils down to this fact. Modern web application is essentially 2 apps (frontend and backend) that lives in 2 different environment. Each with its own constraints. I accept this fact as the ground zero truth, and just surrender to the current way of building things. That is, you have to build 2 things: SPA frontend client and API backend server. Yes, you have to validate and secure both. Yes, you have to test for both. The end result is much more robust, in error handling, in user experience, in performance (yes), in malleability, in maintenance and extensibility, compared to the server rendered stack with bolt on jQuery/HTMX/etc. |
This doesn't have to be the case, though. We all use e.g. banking & telecom sites that worked fine before being rebuilt using "modern architectures" and now are memory hogs. There is no reason many/most sites cannot go back to simpler architectures (other than programmers have forgotten how to build those sites, which is in fact a real problem).
I do hear the argument that when you start building, you don't always know whether this simple brochureware site will evolve into a multimedia player platform, so just start with the assumption you will need the capabilities of a complex FE stack. But in the majority of cases this will end up being the wrong choice, and clients/employers will end up spending too much money managing too much complexity.