为什么现在n层开发中的代码库现在有相等数量（甚至更多）的JavaScript代码？

我已经从事Web编程很长时间了，在某个地方，我无法知道为什么我们现在正在做我们所做的事情（或者我们是如何以这种方式来做事情的）？

我从基本的ASP Web开发开始，很早就在页面上混合了显示和业务逻辑。客户端开发之间千差万别（VBScript，不同的JavaScript风格），并且我们对服务器端验证有很多警告（因此我远离客户端逻辑）。

然后我搬到了ColdFusion了一段时间。ColdFusion可能是第一个使用其标签将显示和业务逻辑分开的Web开发框架。对我来说似乎很清楚，但非常冗长，并且ColdFusion的市场需求不高，所以我继续前进。

然后，我跳上ASP.NET的旅行车，开始使用他们的MVC方法。我还意识到Java似乎是企业系统的象牙塔语言，并尝试了MVC方法。后来，ASP.NET开发了这种MVVM设计模式，而Java（准确地说是J2EE或JEE）也很挣扎，并提出了其MVC2方法。

但是今天，我发现，后端编程不再是令人兴奋和进步的地方。而且，基于服务器端的MVC做法似乎已经过时了（人们真的不再使用JSTL吗？）。今天，在我从事的大多数项目中，我发现JavaScript框架和客户端开发是所有令人激动和创新的进步的来源。

为什么要进行从服务器到客户端的开发？我对我的一个JEE项目进行了简单的行计数，并且JavaScript中的代码行比Java多（第三方库除外）。我发现使用Java或C＃等编程语言进行的大多数后端开发只是为了生成类似REST的界面，并且解决了显示，可视化，数据输入/输出，用户交互等所有艰苦的工作。通过诸如Angular，Backbone，Ember，Knockout等客户端框架...

在jQuery之前的时代，我看到了很多图，其中n层开发中的MVC中的M，V和C之间存在清晰的概念性界线。jQuery后，这些线在哪里绘制？看起来MVC和MVVM都可以在客户端的JavaScript代码中找到。

我想知道的是，为什么我们要进行这样的转换（从服务器端编程的重点到客户端的方方面面，从偏爱编译语言到脚本语言，从命令式到功能性编程，所有这些似乎都是同时发生的） ），此过渡/转移解决了哪些问题？

在服务器和客户端之间转移计算负载是一种周期性现象，并且已经有相当长的一段时间了。

当我在社区大学学习时，个人计算机才刚刚起步。但是以太网尚未得到广泛使用，并且没有人拥有局域网。当时，这所大学有一个大型机来处理学生记录，并作为编程课程的平台。行政部门的终端是在分时的基础上连接到大型机的，但是学生们必须打卡才能完成编程任务，这是一个艰巨的过程。最终，他们进入了一个实验室，学生可以在终端上签到时间，但仍然可能需要半小时左右的时间才能获得半英寸厚的错误打印输出。 所有处理工作均在大型机（服务器）上完成。

但是大型机非常昂贵，因此公司开始建立局域网，处理负载从服务器转移到各个客户端计算机，这些计算机功能强大，足以运行单个文字处理，电子表格和业务应用程序，但功能却不足以处理与他人分享他们的处理能力。该服务器是一台类似的机器，具有类似的功能（也许有更多的内存和硬盘空间），但主要用于共享文件。这称为客户端/服务器。 大多数处理已转移到客户端计算机。

在客户端计算机上执行所有处理的缺点之一是，您陷入了软件安装和升级的这种永久循环中，并且随之而来的所有麻烦事。这些机器的编程模型（基于事件的，位于代码背后的用户界面）鼓励创建混乱，难以维护的程序（泥泞不堪）。大多数最终用户不具备适当维护其硬件和软件的技能，因此需要大量IT维护人员。

随着计算机变得越来越强大，分工变得可能。现在您可以拥有文件服务器，数据库服务器，Web服务器，打印服务器等。每台机器都可以针对所提供的任务进行某种程度的优化，并由具有必要专业知识的人员进行维护。可以编写在Web浏览器中运行的程序，因此不再需要客户端安装。这称为多层或n层。与大型机时代一样，浏览器在本质上也用作哑终端，尽管与服务器通信的方法更为复杂，专有性较低，并且基于中断机制而不是分时和轮询。 处理已移回服务器。

但是，Web开发带来了一系列全新的麻烦。为浏览器编写的大多数业务应用程序都是静态表单和报表。用户界面中的交互性很少。Javascript还没有找到第二风向标，并且浏览器不兼容存在主要问题，这阻碍了Javascript的广泛采用。但是，情况已经好多了。HTML5和CSS3为浏览器编程模型提供了实质性的新功能，jQuery出现了，并帮助了一代又一代的程序员发现Javascript可能有用。新的前端UI框架应运而生。在浏览器中甚至是完整的游戏中编写高度交互的UI成为可能。 处理再次移回客户端。

如今，您可以在云中购买任意数量的处理能力，然后在服务器上运行程序。我要说的是，我们现在在一个地方，作为软件开发人员，您可以选择在客户端和服务器上执行处理能力的位置。

您似乎在混用两个非常不同的概念：

1. 分离表示和业务逻辑（MVC）=>提高可维护性
2. 将执行分配给节点=>提高效率

过去，客户端/服务器计算常常被混淆为暗示第一个，因为与服务器相比，客户端通常不提供很多计算能力。因此，将“繁重的”业务逻辑计算（M）移至服务器，同时又将“轻型”视图处理（V）保留给客户端，这似乎很自然。反过来，您必须实现某种仲裁程序（C）在两者之间进行转换。

客户现在可以轻松利用流程能力，该能力曾经暗示了一些昂贵的服务器硬件，因此在哪里执行业务逻辑（客户端或服务器端）的界限就变得模糊了。确实，答案取决于您的特定用例和权衡选择，例如：

• 客户端延迟与复杂性：服务器端处理使系统更简单，因为不需要将代码部署/下载到客户端，但是这是以计算期间客户端延迟的代价为代价的。

• 复杂性与服务器负载：客户端计算可能会增加系统复杂性，但也可能有助于减少服务器负载。

• 分散的应用程序弹性与集中执行能力：在移动应用程序的世界中，尽管网络断开，保持客户端正常工作也很重要。但是，这是以管理多个部署的业务逻辑版本为代价的。

这不是很多折衷的清单。

由于用户一直想要相同的功能，因此其Web应用程序（而不仅仅是网站）与台式机应用程序一样是一团糟。使这一切都在浏览器（实际上是多个浏览器）中运行不像以前那样，您可以用很少的代码将VB表单链接到数据库。当您不必返回服务器时，这更容易实现。

使用Java或C＃等编程语言进行的大多数后端开发仅是为了产生类似REST的界面，而所有显示，可视化，数据输入/输出，用户交互等方面的辛苦工作都是通过客户端-侧面框架，例如Angular，Backbone，Ember，Knockout等。

也许后端编程/服务似乎是一回事，但这是应用程序的核心。在这些领域中，编码实践可能更有效。工具，语言，浏览器和框架仍在不断发展，因此UI / UX难以开发。它们是旧ASP所没有的新东西。如果我们能够摆脱使用简单表单和html表的用户界面，那么在这些领域也不会有太大的兴趣/炒作，但是用户希望拖放，动画，过渡，弹出式窗口等。

今天，在我从事的大多数项目中，我发现JavaScript框架和客户端开发是所有令人激动和创新的进步的来源。

为什么要进行从服务器到客户端的开发？

实际上，这里有两个问题：

1. 为什么客户端编程会在其中取得进展？
2. 为什么将应用程序编写为在客户端而不是服务器上运行？

两者实际上是截然不同的。

为什么客户端编程会在其中取得进展？

由于运行时间，环境和生态系统在过去三年中已基本成熟，这为创新者等待开发的新领域打开了大门。

前端开发过去很难。您必须在没有现有技术或工具来构建胖客户端应用程序的生态系统中，使用ECMAScript 3的受限功能为浏览器编程-始终是一个恶劣的环境。没有模块加载器。您无法正确处理依赖关系。棉绒工具很少。框架不成熟，前端的低信誉使能够解决这些问题的创新者望而却步。

随着这些因素的变化，它们为快速开发富客户端应用程序并持续运行它们创造了一个关键的条件。

因此，在回答您的问题时，与其说新的前端技术推动了进步，还不如说它们释放了瓶颈并允许客户赶上用户的期望。

为什么将应用程序编写为在客户端而不是服务器上运行？

有许多直接原因，但近年来最明显的是智能手机的兴起。

智能手机使功能强大的计算变得便宜，普遍且有用。它们由全球数十亿人拥有，并已将计算带入了新兴经济体的中产阶级。但是，移动网络速度缓慢，不完整，并且受到地理，工程和政治难题的制约。在这种环境下，应用程序不可避免地要在本地存储状态，并且不情愿地在无状态操作中向上修补数据。

有什么不同吗？想象一下，如果您的智能手机只是一个哑终端。每个状态突变都必须是异步且容易出错的。每个内容加载将花费宝贵的美分。您将不得不投资五个小时正常运行时间的庞大服务器场。计算成本将直接由您承担，因此人气的突飞猛进实际上可能会打击您的业务。

客户端应用程序允许您以快速，同步的方式处理与单个用户有关的状态。它们使您可以将计算成本分摊给用户。他们让您摆脱了停机时间和糟糕的网络连接。它们使服务器代码变得愚蠢，以至于可以将其缓存在网络基础架构本身中-静态HTML和JS文件，或针对移动应用程序的固定响应。

概括地说：客户端开发利用了中功率个人计算的低成本，并避免了高功率集中计算的高成本。

您问了几个问题，其中一些已经有了很好的答案。一些还没有答案：

我想知道的是，为什么我们要进行这样的转换（从服务器端编程的重点到客户端的……所有这些似乎都是同时发生的），并且这种转换/转移解决了哪些问题？

罗伯特·哈维给出了一个很好的答案。

...从偏爱编译语言到脚本语言，

脚本语言提供了许多优势（也）在编译语言，如：

• 更容易学习和使用
• 消除编译时间（加快开发速度）
• 提供更多功能（高端应用程序控制）
• 允许快速更改正在运行的代码
• 等等

...从命令式编程到函数式编程，

这是一个很好的比较，但我可以总结一下，在分布式软件（例如云计算）中，管理状态更改（跨多个节点同步）可能是一个巨大的问题。在函数式编程中，处理状态更改的需求要低得多。