仅HTML / JavaScript网络应用程序的优缺点

我来自ASP.NET表单背景，过去发现服务器端编码非常强大。但是，最近，我一直想逐步淘汰前端的服务器端代码，并用纯HTML / JavaScript代替它，后者通过JSON Web服务访问数据。我对此没有任何实际经验，所以我想听听这是否是一个久经考验的模型。另外，围绕它的陷阱是什么？

我发现ASP.NET用户控件非常有用，因此我想通过将标记模板存储在服务器上单独的HTML文件中来保留其理论。这些将分别通过jQuery AJAX和jQuery HTML模板插件检索和使用。

任何输入将不胜感激。

PS：对不起，这个问题很抱歉，但是这种Web体系结构是Web-2.0吗？还是我完全偏离了轨道？

我专门针对正在开发的Web应用程序使用了此技术。我的后端使用Java SDK托管在Google App Engine上，而前端使用HTML，CSS和JavaScript（带有jQuery）。

这个项目是一个很小的项目，只有我自己和一名Web设计师，我们俩都认为这种方法可以帮助我们更快地工作并更快地将产品推向市场。

优势：与网页设计师合作

这种技术的主要优点是，知道一些PHP但不认为自己是程序员的Web设计人员可以在HTML和CSS中不受限制地工作，而不必费力地浏览JSP，taglib标签和其他服务器端的代码。标记，我们一直在说年内应该做前端开发人员的生活变得更轻松。

没有所有服务器端标记，我们变得更加敏捷。网页设计师直接换了3次或4次修改其原始设计，而我所做的更改很少。

他对我的评论是，他觉得HTML仍然存在，因为他可以对其进行编辑，然后立即通过动态数据查看其计算机上的更改。我们都从中受益，因为集成几乎是自动的。

服务器端代码和HTML / CSS切换

在过去的项目中，他不得不将HTML和CSS交给Java开发人员，然后Java开发人员将使用他的HTML和CSS并使用JSP技术完全重写它们。这将花费大量时间，并且通常会导致页面的实际呈现以及W3C验证程序中的验证方面存在细微但重要的差异。

总的来说，我们都对这项技术感到满意，而且我的HTML页面中仍然有零个JSP页面或服务器端代码。

REST / JSON技术的陷阱

也许最大的陷阱是我们尚未遇到的陷阱。我完全希望与经验丰富的Java开发人员有所不同，这些开发人员对Apache基金会和Spring团队告诉他们的标签库如何使前端开发人员更轻松地使用代码感到震惊。我完全希望随着这个项目的扩展会有一个学习曲线，而且我们将招募更多的开发人员，他们可能不得不学习这些过时的技术，以我的经验，这些技术使Web设计师的工作更加困难。

另一个陷阱是JavaScript代码变得非常庞大。这可能是一个更大的问题，可能是因为我是第一次使用此技术，并且因为在实现快速发布方面我们引入了一些技术上的欠缺。也许选择一个更好的框架将有助于减轻很多代码的负担。在我看来，这都不是最重要的事情，因此，我被鼓励继续使用这项技术并提高我在该领域的技能。

优势：可以在平台上构建其他应用程序

最后，我要提到一个隐藏的优势。因为后端RESTful Web服务和前端之间存在很好的分离度，所以我还创建了一个可以轻松扩展的平台。

我们的一个运维人员想在另一个应用程序中尝试概念验证，并且由于有了RESTful服务，我们能够为该应用程序创建一个完全不同的前端，以解决一个完全不同的问题。快速发展的概念证明使用了它自己的HTML，CSS和JavaScript，但它使用RESTful服务作为后端和数据源。

最后，另一位项目经理看到了我所做的一切，并且立即变得很清楚，该功能不仅需要概念验证，因此，他的团队实施了该功能。

无论是在应用程序级别还是在HTML / CSS / JavaScript级别，我都无法强调这种体系结构的可重用性，因此，我绝对鼓励您在下一个项目中尝试一下。

这当然是一个可行的策略，但不是万灵丹。

优点：

• 如果做得正确，以这种方式开发的应用程序将响应迅速
• 您将逻辑（在服务器上）和表示（在客户端上）清楚地分开了；服务器完全不必关心应用程序的呈现方面
• 可能更有效地利用网络带宽（您仅发送原始数据，没有演示样板）
• 由于您对请求/响应范式的依赖性降低，因此更易于开发类似于桌面的GUI

缺点：

• 您必须使用Javascript或可以编译为Javascript的语言编写客户端代码，因为这是浏览器中唯一可用的功能
• 客户端上的资源使用率可能更高，因此该应用程序可能无法在不合格的设备上正常运行（请考虑使用移动浏览器等）
• 禁用javascript根本无法工作；如果它有一个面向公众的网站，则您必须认真考虑是否愿意承担这种风险（特别是如果考虑SEO和可访问性-javascript繁重的方法通常会破坏这两个方面）
• 很多逻辑必须写两次：一次在客户端，一次在服务器（因为您永远无法信任客户端）
• 并发性可能很糟糕，因此您需要非常仔细地设计客户端代码，并为各种并发性问题做好准备

作为最佳实践，这绝对有可能，而且可能令人鼓舞。您建议的是将UI与业务逻辑分离，以便将关注点明确分离。真的很好

我们经常尝试将各种框架弄混在一起，最终得到一块整体的软件，其中UI，业务逻辑和数据相互交织。这使得维护和修改变得更加困难。

将应用程序分为两部分后，您可以将UI完全替换为其他内容-桌面程序或与桌面浏览器相比的其他移动版UI。

在执行此操作时，您会发现棘手的一点是，理论上应该放在服务器中的一点代码会更好地放在客户端上-例如，验证，它可以更快，更响应用户，将验证代码放置在客户端上。客户端上的表单比单击服务器进行检查，例如，文本字段仅包含字母数字字符。数据和业务层通常也是如此。您只需要对何时违反层之间的区别做出明智而实际的决定。

缺点之一是需要复制JavaScript和ASP.net中的某些逻辑。对于您来说，这可能不是一个大问题，具体取决于您的应用程序。它经常出现是因为您不想让服务器检查所有小事情（“在这种情况下是否允许用户按此按钮或选择此选项？”），但是您也不想依赖由于用户可以控制客户端，因此只能在客户端上进行验证。

如果您仍在使用ASP.NET WebForms并希望加快应用程序的速度，请执行以下操作：

• 设计应用程序时要牢记SOLID
• ViewState在所有页面和用户控件上禁用

• 不要使用服务器端控件

  <％：VeiwModel.Title％>代替<asp：Literal id =“ Title” runat =“ server”>

• 在后端，重写OnInit方法并在那里进行所有初始化：

  受保护的重写void OnInit（System.EventArgs e）{CreateViewModel（）; base.OnInit（e）; }

• 使用SquishIt将所有.css和.js文件压缩为1 个

• 延迟加载图像
• 缓存复杂对象

最后，请访问www.porsche.se。那不是该死的快速网站吗？