我们想要编写一个由HTML，Javascript（JQuery）和CSS组成的UI。虽然初始起点将由Web服务器提供，但不会有任何服务器端模板。浏览器将通过一个安静的界面与服务器交互并呈现其UI。
这种方法有哪些风险？
理想情况下，我想要一个漂亮，直截了当的javascript OO api，它在下面对服务器进行http调用以获取资源的JSON表示。关于如何构建这个的任何建议？
任何人都有浏览器端模板的经验吗？
是否有一个框架可以让这种开发方式更容易？
我们还将定义服务器端资源，我的想法是遵循ruby on rails约定。例如，如果在routes.rb中定义Users资源，则您有7个uri模板。有什么想法吗？
顺便说一句，服务器端功能将在java中开发。
答案 0 :(得分：2)
我对这种方法有很多经验。我可以向你保证它是有效的 - 从长远来看，我还不知道但是我对它非常满意（作为开发人员）。
你需要确保你已经掌握了Javascript。阅读最新技术，至少查看Douglas Crockford的作品，最重要的是JSLint。
至于框架，这就是你的愿景所在。我们从头开始构建一个，因为我们需要现有框架所不具备的工具组合，因为我们认为我们有远见和专业知识可以贯彻执行。你必须比较专业人士和骗子。如果使用现有框架，则几乎无法控制其方向或发现和修复错误的速度。如果你自己构建一个，你可能会冒着做出错误决定的风险，最终得到一个不太有效的框架。
我注意到在我们的应用程序中，自定义服务器端代码非常小。这意味着后端的重要性非常小（验证，健全，授权）。我们使用PHP，但仅仅因为我们有丰富的PHP经验。
肯定存在风险。在启动和早期过渡期间，我注意到“较小”的程序员难以追赶。对于不熟悉Javascript的人来说，有一个非常陡峭的学习曲线，这是很多的优点。
另一个风险是表现。我们建议客户使用谷歌浏览器，因为
然后有兼容性。框架的想法是它能够隐藏这种复杂性。幸运的是，浏览器根据标准增加了调整，但向后兼容（例如）IE6非常困难。
我建议不要使用jQuery。我发现jQuery更像是一个'插件'而不是一个实际的框架。当你有一个网站时，jQuery真的很闪耀，你想要有点夸张。它有一些非常好的通用工具（DOM操作和所有这些），但它在业务建模领域非常缺乏。
我也建议反对OO方法。对于一些非常少数的域，OO是完美的解决方案。对于大多数企业来说，事实并非如此。而且Javascript不仅仅是OO。
答案 1 :(得分：1)
＃1问题（也许是唯一的问题）是搜索引擎。它不确定您的内容将被识别/可用/可搜索的程度。底层的原因是搜索引擎不一定会理解你的内容（因为只有在Javascript被执行后才会显示）。
除此之外，这是一个很好的方法。我尝试了几次并且效果很好（假设您没有被Javascript吓倒）。由于服务器 - ＆gt;生成的网站通常比传统的网站响应更快。客户端流量非常小 - 只传输原始数据。所有UI内容都是由Javascript在客户端生成的。