【问题标题】:What are the risks of described approach to developing web application?所描述的开发 Web 应用程序的方法有哪些风险?
【发布时间】:2011-04-27 22:58:59
【问题描述】:

我们想编写一个由 HTML、Javascript (JQuery) 和 CSS 组成的 UI。虽然最初的起点将由 Web 服务器提供,但不会有任何服务器端模板。浏览器将通过 Restful 界面与服务器交互并呈现其 UI。

这种方法有什么风险?

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

谁有浏览器端模板的经验?

有没有一个框架可以让这种风格的开发变得更容易?

我们还将定义服务器端资源,我的想法是遵循 ruby​​ on rails 约定。例如,如果您在 routes.rb 中定义了一个用户资源,那么您就有 7 个 uri 模板。有什么想法吗?

顺便说一下,服务器端的功能将用java开发。

【问题讨论】:

    标签: java javascript jquery


    【解决方案1】:

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

    您确实需要确保您已经掌握了 Javascript。阅读最新技术,至少查看 Douglas Crockford 的工作,尤其是 JSLint。

    至于框架,这正是您的愿景所在。我们从头开始构建了一个框架,因为我们需要现有框架不需要的工具组合,并且因为我们认为我们拥有实现它的愿景和专业知识。你必须比较赞成和反对的。如果您使用现有框架,您几乎无法控制它的方向或发现和修复错误的速度。如果您自己构建一个,您可能会冒做出错误决定并最终得到一个无法正常工作的框架的风险。

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

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

    另一个风险是性能。我们建议我们的客户使用谷歌浏览器,仅仅是因为

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

    我建议不要使用 jQuery。我发现 jQuery 更像是一个“插件”而不是一个实际的框架。当你有一个网站并且你想要一些花哨的东西时,jQuery 真的会发光。它有一些非常好的通用工具(DOM 操作等),但在业务建模领域非常缺乏。

    我还建议不要使用 OO 方法。对于极少数领域,OO 是完美的解决方案。对于大多数企业来说,事实并非如此。 Javascript 的能力远不止 OO。

    【讨论】:

      【解决方案2】:

      排名第一的问题(也许是唯一的问题)是搜索引擎。不确定您的内容将如何被识别/抓取/搜索。根本原因是搜索引擎不一定会理解您的内容(因为只有在执行 Javascript 后才会显示)。

      除此之外,这是一个很好的方法。我试了几次,效果很好(假设你没有被 Javascript 吓倒)。生成的网站通常比传统网站响应速度更快,因为服务器 -> 客户端流量非常小 - 仅传输原始数据。所有的 UI 内容都是由 Javascript 在客户端生成的。

      【讨论】:

      • 我不建议将这种方法用于常见的“网站”。然而,对于复杂的、数据驱动的、特定领域的 Web 应用程序来说,它是圣杯。
      猜你喜欢
      • 2020-07-19
      • 1970-01-01
      • 1970-01-01
      • 2011-04-23
      • 2015-04-13
      • 1970-01-01
      • 2019-12-30
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多