为什么选择 Angular/Ember/Backbone 而不是常规的 Web 框架？答案

【问题标题】：Why Angular/Ember/Backbone and not a regular web framework?为什么选择 Angular/Ember/Backbone 而不是常规的 Web 框架？
【发布时间】：2014-04-18 22:05:58
【问题描述】：

所以我担心我可能在这里遗漏了一些非常基本的东西，但我真的无法理解这一点 - 为什么？为什么我们要使用那些 JS MVC 框架，而不是坚持使用 Rails、Django、PHP 等？

这些 JS 框架给了我们什么是旧的 web 框架无法实现的？我阅读了有关 SPA 的信息，并且没有什么是我无法使用 ASP.NET MVC 做的，对吧？

听到所有工作人员想要离开我们当前的框架来使用这些新框架，我真的很困惑，而这不仅仅是为了学习新东西。我完全支持这一点，而且我一直在尝试使用其他框架来看看我缺少什么，但也许这些新技术可以提供一些我根本看不到的真正重要的东西？

【问题讨论】：

您通常会同时使用服务器端和客户端框架。它们有不同的用途，不能相互替代。

标签： javascript single-page-application web-frameworks

【解决方案1】：

单页应用程序通过无缝切换所有页面来提供更好的体验。这意味着除了一些其他用户体验改进之外，您永远不会在用户操作之间看到“page flash”。

前端框架通常还提供与 API 交互的通用方式。因此，无需为站点中的每个页面编写 AJAX 包装器，您只需说“此页面具有此路由（路径），将来自该 API 端点的数据与此架构挂钩，并使用这些模板和帮助程序呈现它。” API 的支持者有很多，因为从服务的角度编写应用程序有很多很好的理由。 This talk 总结了很多支持 API 的观点。总结一下：

将您的 Web 产品编排为服务使它们在本质上是解耦的。这意味着它们很容易更换。强大的面向对象设计原则背后的所有原因同样适用于应用程序的较大部分。把每一块都当成一个独立的部分，就像一辆车一样，整个平台更加健壮和健康。这样一来，前灯的缺陷不会导致电机爆炸。

这与 SOAP WSDL 的工作方式非常相似，只是您拥有开箱即用的自动创建工具。
为应用程序的每个部分定义明确的接触点可以让其他人更容易与之交互。这可能永远不会影响您的特定业务，但许多非常成功的网络公司（谷歌/雅虎、亚马逊 AWS）已经根据这一原则创造了非常有利可图的市场。通过这种方式，您可以让多个产品由相同的接触点支持，从而减少产品开发的大量工作。
正如其他指出的那样，前端框架不能替代后端服务器技术。怎么会这样？虽然这看起来像是一个障碍（“太好了，现在我们有两种产品需要支持！”），但它实际上是一个很大的好处。现在您的前端和后端可以更改和版本，而不必担心无意中破坏其中一个。只要您遵守合同，事情就会“正常工作^TM”。

要在评论中回答您的其他问题，那是完全正确的。您使用前端框架来处理所有客户交互，并使用完全独立的后端技术堆栈来支持它。

我忘记了一些好的...

【讨论】：

所以这不是可以独立使用的东西吗？它只与rails、django、node等服务器端框架结合，简单地让模型与视图分离更容易、更正确？

【解决方案2】：

Angular、Ember 和 Backbone 是客户端 JavaScript 框架。它们可以与 Rails、Django 或 PHP 后端互换使用。这些 JavaScript MVC 只负责在浏览器中组织 JavaScript 代码，并不真正关心它们的数据是如何在服务器端处理或持久化的。

【讨论】：

但这是我无法理解的——我可以用我的 django 模板完成客户端，我仍然有我的 JS 代码，几乎可以做任何我想做的事情。为我的客户端使用另一个 JS 框架有什么好处？
@PatrickM 的上述回答在这一点上非常出色。当您必须单独加载每个页面时，页面闪烁会创建一个 janky 用户体验，因为您可以通过 AJAX 无缝请求新信息并将其放入 DOM，而无需用户请求新页面并等待它呈现。更重要的是，当您可以将渲染 HTML 和 JS 的资源委托给用户的计算机时，为什么还要浪费宝贵的服务器资源呢？例如，我的 MacBook Pro 比运行我的 AWS 托管网站的 EC2 服务器实例更强大。

【解决方案3】：

Django/Rails 等是服务器端 MVC 框架。 Angular/Backbone 等是客户端 Javascript MVC 框架。 Django/Rails 和 Angular/Backbone 一起工作 - 在单页应用程序中，通常服务器端 MVC 将提供初始 HTML/JS/静态资产一次，然后一旦完成，客户端路由器将接管并处理与您的应用程序的所有后续导航/交互。

这里的区别在于“单页应用程序”的概念。想想“常规”网络 Django/Rails 网站是如何工作的。用户进入您的应用程序，后端获取数据并提供页面。用户点击一个链接，这会触发服务器提供一个新页面，这会导致整个页面重新加载。这些传统类型的网站基本上是无状态的，除了 cookie/会话等。

相比之下，单页应用程序是一个有状态 Javascript 应用程序，它在浏览器中运行，看起来就像一个传统的 web 应用程序，您可以像往常一样点击和浏览，但是页面永远不会重新加载，相反，特定的 DOM 节点会根据应用程序的逻辑刷新其内容。要以可维护的方式实现像这样的纯 Javascript 客户端体验，确实需要您开始组织 Javascript 代码，原因与在服务器上所做的相同 - 您有一个路由器，它采用 URL 路径并与经常与控制器交互的控制器包含用于显示/隐藏特定 URL 的视图的逻辑，您有一个模型来封装您的视图所使用的数据（将模型视为数据库结果的大致“行”）。并且因为它是 Javascript，所以会发生事件，因此您可以让视图监听其关联模型的变化，并在数据更新时自动重新呈现自身。

另外请记住，您不仅在客户端拥有一个视图，通常还有许多单独的视图组成一个页面，并且这些视图通常是嵌套的，这不仅是为了组织目的，而且因为我们想要这种能力只刷新 UI 中需要刷新的部分。

Backbone 简介可能是该主题的良好开端：http://backbonejs.org/#introduction

【讨论】：

【解决方案4】：

查看this 文章，很好地解释了现代 Web 应用程序在客户端、服务器端的外观以及它们之间的通信。

顺便说一句：

客户端 -> Ember、Angular、Backbone、Knockout。

服务器端 -> Django、Node、Rails

【讨论】：