前言：我是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），还有一大波生动有趣的干货等着你。