.png)
2 hours ago
2
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
