HackerNews中文版

在“我那个时代”，我们会请一位内部网页设计师来创建资产、样式，以及一个演示HTML文档，展示实现计划内容所需的所有组件。然后，我们会将演示HTML拆分成模板，在后端进行渲染，然后从那里开始工作。交互组件会使用JavaScript - 最初是Knockout（视图模型，真是个糟糕的主意），后来转向React（这让你可以将状态与表现分离）。我认为，后端模板加上React前端组件是最佳组合，只要你的POST处理逻辑合理且以数据为导向，而不是某种面向对象的噩梦（https://wtforms.readthedocs.io/en/3.2.x/fields/#the-field-base-class）。你不必单独实现API，然后才发现你的前端开发者工作得非常……快，并且实现了他们自己对问题领域的理解。如今，如果你运气不好，你会发现你的前端被一些非标准的组件包装器所“祝福”，这些包装器层层嵌套……而且，TS文档中的类型仍然没有链接，所以祝你好运去查找TData的含义，尤其是当TData来自不同的代码库时。总结：总结在标题中。我想要回理智 :D

查看原文

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

问HN：还有非单页面应用（SPA）的前端开发者吗？