|
Back in "my days" we would get an in-house web designer to create assets, styles, and a demo HTML document demonstrating all necessary components to implement the planned content. We would then break down the demo HTML into templates, which we would render in the backend, and work from there. There would be JS for interactive components - first Knockout (viewmodels, terrible idea), then React (which would let you separate the state from presentation). Backend templates + React frontend components was IMO the optimum, as long as your POST handling logic was sensible and data-oriented rather than some OO nightmare (https://wtforms.readthedocs.io/en/3.2.x/fields/#the-field-base-class). You didn't have to implement the API separately from the frontend to later discover that your frontend developer worked really... fast. And implemented their own understanding of the problem domain. These days, if you're super unlucky, you discover that your frontend has been blessed with some non-standard component wrappers, which wrap components, which wrap components, which wrap... And somehow types in TS docs still have no links, so good luck finding what they mean by TData, especially if TData comes from a different codebase. tl;dr: The tldr is in the title. I want sanity back :D |
Decoupling back-end logic from front-end logic has just too much positivise and advantages that doing SSR is just so 2000s. JS brought dynamicity into web page rendering a long time ago. With SPA, or maybe even PWA(who really uses these?), you get also decoupling from the server - a data dynamicity, so to speak.
In short, SPA turns a dumb web page into a dynamic and responsive application that can have the look and feel of a desktop program. Web is no longer static and slow but fast and lively.
Nowadays, static HTML is a niche use case for serving web pages. Like a personal blog or corporate website that is static in nature(information there change sparsely) and can be manually typed or compiled via static website builder, like Hugo.