客户端渲染换为服务器端渲染_服务器与客户端渲染（AngularJS与服务器端MVC）

客户端渲染换为服务器端渲染

关于服务器与客户端应用程序渲染的讨论很多。 虽然没有“一刀切”的解决方案，但我将尝试从不同的角度主张客户端（特别是AngularJS）。 首先是建筑。

建筑

做得好的架构已经明确定义了关注点分离（SoS） 。 在大多数情况下，最少的高级配置为：

• 数据存储
• 服务
• API
• 介绍

这些层中的每一层都应仅具有上述知识的最少知识。 服务需要知道在哪里存储数据，API需要知道要调用哪些服务，并且表示层只能通过API与其余的服务进行通信。 这里要注意的重要一点是，关于以下层的知识应该不存在。 例如，API不应该知道谁或什么消费它。 它不应该具有表示层的知识。

对于这些层的每一层都应该说更多，“现实世界”中的情况要比这复杂得多。 但是，对于本文的其余部分，重要的要点是，表示层通过API与服务器进行通信，而API对“外界”一无所知。 随着越来越多的机器和设备类型（笔记本电脑，移动设备，平板电脑，台式机），这种分离变得越来越重要。 后端应仅提供业务逻辑和数据。

技能专长

考虑开发人员的技能是该体系结构的重要方面。 例如，如果开发人员习惯于使用Java工作，则除非设计有明显的优势，否则不应该设计基于C＃的系统。 这并不意味着不应使用新语言（谁说Scala和Clojure？）来提高技能。 只是必须考虑团队的生产力，并且编程语言的知识是重要的要素。

无论现有知识如何，应用程序的类型都需要一些技能。 例如，如果应用程序将网站作为表示层，则必须具备HTML，CSS和JavaScript知识。 有一些框架可以用来避免对该知识的需求（即Vaadin ）。 但是，使用这些框架只会推迟不可避免的事情：接受HTML，CSS和JS是浏览器可以理解的一种或多种语言。 问题仅在于您是直接采用它们还是使用其他方式（即Java或C＃）为您编写它们。 后一种情况可能会给人以更快的速度做事的印象，但是在许多情况下，当需要做那些“翻译”不支持的事情时，需要付出一些代价。

服务器端更容易应对。 对于每种技能，都有更多选择，并且有好的（即使不是很好的）解决方案。 我们可能会争论Scala是否比Java更好，但是两者都能提供足够好的结果，并且学习新语言的决定要困难得多（尽管我认为开发人员应该通过尝试新的语言和框架来不断扩展自己的知识）。 可以使用Java，Scala，C＃，Clojure，JavaScript / NodeJS等对后端进行编码。我们在浏览器中没有那么奢侈的地方。 Adobe Flash已死， Silverlight从未升空。 Vaadin之类的工具最初旨在缓解JavaScript所带来的痛苦，这是由于我们看到HTML和JavaScript的不断改进而逐渐失去了作用。 “浏览器”世界瞬息万变，情况与不久前大不相同。 欢迎来到HTML5的世界。

对于移动设备的开发可以说类似。 没有一种语言能适合所有人。 我们无法使用Java开发iPhone应用程序。 虽然HTML在某些情况下可以作为解决方案，但在另一些情况下，则需要进行“本机”开发。

唯一的常数是，无论是Web，移动，桌面还是Google Glass ，它们都应使用API​​与系统的其余部分进行通信。

我要提出的观点是，在完成工作所需的语言采用与每个新项目中切换到新语言之间必须保持平衡。 有些语言是必须的，有些是很好的（但不是强制性的）。 使用Web时，HTML，CSS和JavaScript是必须的。

服务器与客户端渲染

由于我们已经确定，在网站（谁说应用程序？）的情况下，必须使用CSS和JavaScriptHTML，而试图为我们创建HTML的工具是“邪恶的”，因此问题仍然在于谁呈现HTML。 对于浏览器的大多数历史记录，我们习惯于在服务器中呈现HTML并将其发送到浏览器。 有很强的理由。 前端技术和框架还很年轻且不成熟，浏览器存在严重的兼容性问题，并且通常来说，使用JavaScript会很痛苦。 那张照片不再有效。 Google向我们展示了在许多情况下浏览器与台式机一样好。 JQuery通过让我们以相对简单的方式来操作DOM，彻底改变了我们使用JavaScript的方式。 发布了许多其他的JS框架和库。 但是，直到最近，还没有什么可以替代旧的模型视图控制器（MVC）模式。

对于所有小型站点，服务器呈现都是必须的。 还是？ AngularJS改变了我们感知MVC的方式（实际上，它是模型视图的，但是我们不要被束之高阁）。 可以在客户端中完成，而不会牺牲生产力。 我认为，在许多情况下，随着AngularJS生产率的提高。 还有其他客户端MVC，例如BackboneJS和EmberJS 。 但是，就我的经验来看，AngularJS没有什么比这更好的了。

AngularJS并非没有问题。 让我们看一下客户端与服务器端页面渲染的优缺点。 在客户端，我假设使用AngularJS。 为了进行比较，服务器端可以是任何东西（Java，C＃等）。

AngularJS缺点

页面呈现速度较慢，因为浏览器需要执行DOM操作的额外工作，监视绑定数据的变化，向服务器执行其他REST请求等。第一次打开应用程序时，它需要下载所有JavaScript文件。 根据应用程序的复杂性，这可能是问题，也可能不是问题。 现代计算机完全有能力接管额外的工作。 移动设备比旧计算机功能更强大。 在大多数情况下，客户不会注意到浏览器需要做的工作量增加。

与旧版浏览器的兼容性很难实现。 需要在服务器上呈现其他页面。 该参数的重要性取决于您是否关心（非常）旧的浏览器。 罪魁祸首是Internet Explorer。 如果应用了其他指令，则版本8可以运行（以某种方式）。 不支持早期版本。 将来的AngularJS版本将放弃对Internet Explorer 8的支持。您可以决定是否对IE8及更早版本的支持很重要。 如果是这样，则需要提供替代页面，这将导致额外的开发时间。 根据应用程序的复杂性，非AngularJS开发中可能会存在相同的问题。

搜索引擎优化（SEO）可能是最大的问题。 目前，缓解此问题的最常用技术是在服务器上预渲染页面。 这是一个相对简单的过程，需要少量代码即可在任何屏幕上使用。 有关更多信息，请参见如何创建HTML快照？ 和Prerender.io 。 2014年5月，出现了一篇关于《了解网页》的更好的文章，这给我们带来了一个好消息，即Google能够执行JavaScript，从而为严重依赖JS的网站解决（或正在解决）SEO问题。

AngularJS专业人士

如果做得好（更好地使用JSON，客户端缓存等）， 服务器性能会提高。 客户端和服务器之间的通信量减少了。 服务器本身不需要在将页面发送给客户端之前创建页面。 它只需要提供静态文件并使用JSON响应API调用。 减少了流量和服务器工作量。

AngularJS的设计考虑了测试需求。 连同依赖注入，模拟对象，服务和函数，编写测试非常容易（比我所使用的大多数其他情况更容易）。 单元测试和端到端测试都可以编写并快速运行。

正如架构部分所建议的，前端（几乎）完全与后端分离 。 AngularJS需要了解REST API。 服务器仍然需要传递静态文件（HTML，CSS和JavaScript），并在爬网程序访问时预渲染屏幕。 但是，这两项工作不需要系统其余部分的任何内部知识，并且可以在同一或完全不同的服务器上完成。 简单的NodeJS HTTP服务器可以达到目的。 这种解耦使我们可以独立地开发后端和前端。 通过客户端渲染，浏览器是API使用者，就像Android，iPhone或桌面应用程序一样。

不需要服务器端编程语言的知识。 无论采用哪种方法（服务器或客户端渲染），都需要HTML / CSS / JavaScript。 不将服务器端混入此图中，将使前端开发人员的生活变得更加轻松。

Google对Angular的支持是一个加号。 像Google这样的支持者更有可能继续全力以赴地提供支持和未来的改进。

一旦习惯了AngularJS的工作方式， 开发速度就会提高。 代码量可以大大减少。 由于无需重新编译后端代码，因此我们几乎可以立即看到前端的更改。

摘要

客户端与服务器端渲染的这种视图应谨慎对待。 没有“一刀切”的解决方案。 根据使用的需求和解决方案，上面列出的许多优点和缺点都是无效的，或者也可以应用于服务器端渲染。

在许多情况下，选择服务器端渲染是为了避免陷入HTML，CSS和JavaScript。 它使习惯于使用服务器端编程语言（Java，C＃等）的开发人员更加轻松地认为无需学习“浏览器”语言。 而且，在许多情况下，它会与后端代码产生（通常是无意的）耦合。 两种情况都应避免。 我并不是说服务器端渲染不可避免地会导致这些情况，而是使它们更有可能发生。

这是一个勇敢的新世界。 客户端编程与以前完全不同。 至少有很多原因可以尝试一下。 无论做出何种决定，都应使用足够的信息，只有通过实践经验才能获得这些信息。 尝试一下，不要放弃第一个障碍（会有很多障碍）。 如果您选择不采用此路线，请做出明智的决定。

像AngularJS这样的客户端MVC远非完美。 他们还比较年轻，还有很长的路要走。 许多改进即将到来，我坚信Web的未来将朝着这个方向发展。

翻译自: https://www.javacodegeeks.com/2014/07/server-vs-client-side-rendering-angularjs-vs-server-side-mvc.html

客户端渲染换为服务器端渲染