java - 所描述的 Web 应用程序开发方法有哪些风险？

Question

我们想要编写一个由 HTML、Javascript (JQuery) 和 CSS 组成的 UI。尽管初始起点将由 Web 服务器提供服务，但不会有任何服务器端模板。浏览器将通过静态接口(interface)与服务器交互并呈现其 UI。

这种方法有哪些风险？

理想情况下，我想要一个漂亮、简单的 javascript OO api，它在下面对服务器进行 http 调用以获取资源的 JSON 表示形式。关于如何构建它有什么建议吗？

有人有浏览器端模板的经验吗？

是否有一个框架可以使这种开发方式变得更容易？

我们还将定义服务器端资源，我的想法是遵循 Ruby on Rails 约定。例如，如果您在routes.rb 中定义一个Users 资源，则您有7 个uri 模板。有什么想法吗？

顺便说一句，服务器端功能将用java开发。

Answer 1

我对这种方法有丰富的经验。我可以向您保证它有效 - 从长远来看效果如何，我还不知道，但我对此非常满意(作为开发人员)。

您确实需要确保您已经掌握了 Javascript。了解最先进的技术，至少检查一下 Douglas Crockford 的工作，尤其是 JSLint。

至于框架，这就是您的愿景发挥作用的地方。我们从头开始构建了一个框架，因为我们需要现有框架所不需要的工具组合，并且因为我们认为我们拥有实现它的愿景和专业知识。你必须比较优点和缺点。如果您使用现有的框架，那么您几乎无法控制其发现和修复错误的方向或速度。如果您自己构建一个框架，您可能会面临做出错误决定并最终得到一个不太有效的框架的风险。

我注意到在我们的应用程序中，自定义服务器端代码非常小。这意味着后端的重要性非常小(验证、健全性、授权)。我们使用 PHP，只是因为我们拥有丰富的 PHP 经验。

肯定存在风险。在启动和早期过渡中，我注意到“较小的”程序员很难 catch 。对于不太熟悉 Javascript 的人来说，学习曲线非常陡峭，而且它有很多优点。

另一个风险是性能。我们建议客户使用 Google Chrome，因为

然后是兼容性。框架的想法是它能够隐藏这种复杂性。幸运的是，浏览器越来越符合标准，但向后兼容(例如)IE6 却非常困难。

我建议不要使用 jQuery。我发现 jQuery 更像是一个“插件”，而不是一个实际的框架。当您拥有一个网站并且想要添加一些花哨的内容时，jQuery 确实会大放异彩。它有一些非常好的通用工具(DOM 操作等)，但在业务建模领域非常缺乏。

我还建议不要采用面向对象的方法。对于一些非常少量的领域，OO 是完美的解决方案。对于大多数企业来说，事实并非如此。 Javascript 的能力远不止面向对象。