前言：我是 JavaScript，如果你还不认识我，不妨先看看《Web 技术的前世今生（一）》，以及《Web 技术的前世今生（二）》
前面我提过，我的大哥 HTML 有一个叫 PHP 的死党，这家伙有事没事经常上我们家串门。
这天，PHP 又来找我大哥闲扯。
“老哥，你知道一个叫 Ruby 的家伙吗？”PHP 问道。
“知道啊，最近我们合作过好几个项目呢。怎么想起问它了？”
“呀，你是不清楚，这小子最近在我们那可火了，听说是鼓捣了一个什么架子。”PHP 继续说道。
“喔，你是说 Rails 啊，”很明显，大哥对 PHP 口中的“架子”很熟悉，向 PHP 解释道：“那不是架子，是 Ruby 用来构建网站的框架。”
我在一旁听着，借机打趣道：“后端那帮家伙有一个算一个，谁敢说开发网站有比咱 PHP 老兄还火的？”
“Js，你可别小看了这个 Rails，”大哥作为一个老实人，听不出我在开玩笑，继续一本正经的说：“之前 PHP 老弟的平易近人对客户是挺有吸引力的，然而随着他们的网站规模越来越大，PHP 的亲和力对于他们而言反而成了一种难以驾驭的负担，似乎他们更需要寻求的是一种约束。”
“哎呀，老哥，你说的太对了，”PHP 突然从凳子上跳起来，“最近好几个老客户都从我这撤了，听说跑去找 Ruby 那小子了。老哥你说，那小子究竟是有什么魔力？”
“它搞的 Rails 框架就是用来规范网站的开发行为，明确你我之间的职责所在的。”大哥慢条斯理地说道。
“大哥，您就别卖关子了，赶紧给我们讲讲这个 Rails 吧？”对这事我也来了兴致。
“它对一个网站的架构划分了三个层次。比如我就归属于只负责页面展现的视图层（View）；有关业务逻辑的活从视图层剥离出来，由不同的模型（Model）去做；至于接受用户的输入交由恰当的 Model 去处理，处理完后再将数据传递给 View，这个由控制器（controller）完成。”
大哥看着我迷茫的眼神，又继续补充道：“对于一个动态网站而言，每一个页面应该长成什么样子是一件事，而究竟该呈现哪一个页面，以及页面上动态变化的数据该是什么又是另外一件事。按之前 PHP 的做法，一个文件中既有我们前端用来布局页面的代码，又混杂着它用来处理业务逻辑的代码，先不说设计上是否合理，首先这就得要求使用者既要熟悉我们前端，还要熟悉后端，”大哥一边解释着一边朝我诡秘的一笑：“Js，你有兴趣了解下 PHP 每次上工都是如何干活的吗？”
”别别别，”我赶紧摇头，“每次我连自己的活都干不完，哪有工夫搭理它啊。”
PHP 在一旁听着不乐意了，”去你的，我还烦你老在我眼前晃悠呢。“
“这就对了！Rails 的出现就解决了这个问题，我们前端的工作就只是套用所谓的模板引擎来做页面的展现，管它 Ruby 操作数据库也好、做逻辑运算也罢，都统统和咱们无关，我们只需要拿到它最终处理过的数据填充到模板引擎里，再给客户展示出来就行了。”
“呃⋯⋯老哥，你这说的是不是所谓的 MVC 模式啊？我听我的 Java 老大提起过。”PHP 问道。
“没错，就是 MVC，Java 很早以前就玩这个了，它有一个类似的框架叫 structs，只是之前这种开发模式还不流行，最近被 Rails 炒起来了。对了，我听 Java 说它的 structs 也要升级到二代了，估计出来也会火一把吧。“
“哈哈，PHP，看来你们后端的小伙伴们都在搞框架，就你落伍了哦⋯⋯”，我又开始拿 PHP 开涮，“诶？PHP 这家伙人呢？PHP⋯⋯”转过头才发现它已经跑出很远了，看来用不了多久关于 PHP 的 MVC 框架也会问世了。
（猿知原味注：随着 Ruby on Rails 的流行，2007 年之后的五年，进入到了 Web 后端发展史上一段框架横飞的年代。框架的作用除了上面提到的展现层和业务逻辑层的解耦，还提供了诸如通过对象操作数据库的 ORM 技术，以及 URI 路由、表单验证、国际化、安全防护等网站开发中的常用功能。在这期间也出现了一大批优秀的 Web 框架，譬如 SSH（Struts+Spring+Hibernate）、SpringMVC、Rails、ASP.NET MVC、Django、Flask、CodeIgniter、Yii、Lavarel、Beego⋯⋯而且还远远不止这些。）
时间来到了 2010 年，在那前后发生了两件事让我印象深刻。
一是我们的很多客户开始把原本在 Web 上提供的服务同时搬到智能手机上去，然而移动应用并不认识后端返回的 Web 页面（猿知原味注：关于这一点，不包括近几年兴起的 Web App 和 Hybrid App），这就迫使哪怕业务完全相同的应用，针对 Web 端和移动端也得去开发并维护两套后端代码。
二是贪婪的人类对在后端的 View 层渲染页面还是不满意，他们觉得我们前端就不该和后端掺和到一块去，希望将我们彻底分开。
之所以这两件事让我记忆犹新，是因为最终解决它们是我起了大作用。还记得我异步刷新网页的能力吗（Ajax）？既然人类讨厌在后端做页面渲染，那完全可以通过 Ajax 将数据拿到前端来渲染。这样一来，一方面做到了前后端分离，纠结的人类不必再为该由谁负责模板引擎而苦恼了；另一方面，我们前端和移动端一致决定让一个叫 JSON 的家伙当我们的联合运输大队长，由它来负责后端数据的传输工作，这样对于相同的业务，后端只需要维护一套代码就够了。
“With great power comes great responsibility”，彼得叔叔对蜘蛛侠说的一句话让我感同身受。自从我把页面渲染的活揽到前端来之后，后端那帮哥们算是解脱了，然而我肩上的担子迅速变沉了，每天忙的不可开交。
这种情况持续了一两年，直到有一天，我的好大哥提醒了我。
“Js，你看啊，很多年前我们前端的职责就只是做页面的展示，但 Web 发展到今天，我们也和数据打上了交道。你这边不仅要发数据、收数据，还要处理数据，最后还要通过操作 dom 将数据更新到页面上。”
HTML 大哥接着说：“你是不是加粗文字可以借鉴当初后端那帮小子搞的 MVC 框架，也鼓捣个什么框架出来，方便咱们前端将数据的活和视图的活分开来干？”
我一拍大腿，“对啊！现在的状况确实太凌乱了。我们也可以搞个 View 层只负责页面渲染，搞个 Model 层专门处理数据模型，”我想了想接着说：“再通过某种方式将这两层关联起来，Model 数据改变的时候同步到 View 显示出来，View 上的改变也能将数据同步回 Model。”
“你说的这不就是双向绑定嘛，”大哥给我的设想下了个定义，“还记得我们有个叫 Microsoft 的客户吗？它在数据绑定这一块很有经验，你可以去找它讨教讨教。”
（猿知原味注：MVVM 模式最早就是被微软的 WPF 和 Silverlight 的架构师 John Gossman 提出来的）
没过多久，像 AngularJS、KnockoutJS、EmberJs、VueJS 等一系列 MV* 模式的前端框架就相继出现了。自此，我又过上了轻松愉快的美好生活。
故事读完了，还是意犹未尽？没关系，关注“猿知原味”公众号（yz–yw），还有一大波生动有趣的干货等着你。