【干货】和谐统一的Universal Javascript
天下大势，合久必分，分久必合。
我们的技术体系每天都在更新换代。90年代初（像早期的新浪搜狐都是这样）很多网页是由C/Java语言写的，根据请求输出一坨HTML/CSS/JS。90年代末出现了JSP/PHP等网页脚本，网页开发者终于不需要做很底层的开发了。但2000年左右有人认为Server代码混着Client代码很难受，于是让他们分家了。模板语言的出现彻底改变了格局，于是各种MVC框架雨后春笋一般兴起。
(前面废话铺垫有点多，不耐烦可以从第一张图片看~)
至此，我们的开发技术看起来已经很不错了，开发者可以各司其职。Server端的开发和Client端的开发各自分道扬镳走过了十几个岁月。
其间，Server端进入五花八门的世界，Python/Ruby等和各种框架各种MVC MVVM MVP模型五花八门，引领***。中华大地唯独喜欢PHP，也是在世界范围内的奇观。Client端也是风生水起，Javascript引擎不断优化，加上Client的硬件越来越牛逼，框架越来越丰富，各种新标准（HTML5 Javascript ECMA）层出不穷。
多说一句，Web前端不仅仅是HTML/CSS/Javascript体系，还有刚刚被Adobe放弃的Flash/Action Script体系，和微软做了没多久就放弃的Silverlight体系。也许还有，不想考究。反正现在没得选了。
但想上手学Web技术的人总是会疑惑，我要做Server端还是Client端？我也疑惑。选了Server端我要用什么语言？PHP,Java,Python,Ruby,Perl。这种问题，我也很疑惑。
就像人类社会各种方言各种书面语言一样，计算机世界的语言越来越多。也越来越多的人，陷入了这种选择危机。有个笑话就是，如果你想和一个程序员吵架，就和他分辨他擅长的语言不比某个语言好。
(文章正式开始………………)
================分割线==================
年中时，美国版乐视Netflix公布彻底完成重构了他们的系统
，用来Universal Javascript技术，一度是个热门新闻。咦！这个词看着新鲜有趣！简单意思是，让Javascript来完成整套Web开发。
但其中的细节，耐人寻味。
去查了下来由
，这个新词出现还经历一番波折。起初有个挺牛逼的歪果仁架构师起名“Isomorphic
Javascipt”，被无数人吐槽。后来有个人说，要不叫“Universal Javascript”吧，大家称好。他说：
“It’s true that there are two hard problems in computer science and one of them is naming things. Why? Because good names are important. A good name teaches about purpose and responsibility, so you have to spend some time thinking about it.”
这个“技术”，就是指，用Javascript实现Web的全套开发，包括Client和Server端，实现大一统！
如图：
这个好处想想还挺多：
-
有段Server端的代码，比如说某个算法，想突然在Client端用，发现要重写，无比蛋疼。反过来亦然。 统一以后，虽然不一定是能直接函数调用，至少拷贝过来用还是可以的。 如果文件管理得当，不需要拷贝，只需要放在一个文件，当做shared public code就好。 美妙！
-
开发团队更加简单，不再像中国公司那样去刻意区分前端后端工程师。流量大的时候还是需要，但早期就不用了（根据99% startup都要死掉的规律，还是很有意义）
-
前面我们的纠结也没了。别选前端后端了，一招鲜吃遍天下~~
然而故事还没结束。
你以为就这几句话，就能说服老板，让公司放弃老技术，采用新技术吗？你说你方便简单，但我老招用惯了不需要学更简单呢！
新技术靠忽悠人不行，还得看实力——解决运行效率问题。Netflix重构的首要原因不是维护难，而是并发太差。据文章说的，在加载请求某一页面的时候，会初始化大量的数据，导致服务器压力很大。但是很多数据只有在往下拉或者点击的时候才会展示。所以这次重构，就是要做这样逻辑的优化——只有真正要展示的时候或者快要展示的时候再去加载数据。
如图下：
这想法不错啊！但 认真想想，这可不是要放弃老技术的理由。。
我只要重构重构代码就行了。就像作者见过的百度知道、百度百科、百度贴吧的技术重构一样。这些问题的原因并不是采用的技术不好，而是由于历史原因，开发的时候太急躁留下的各种问题罢了。
前面说了，现在Client端机器性能越来越好，如果能把一大块业务逻辑放到Client去执行，那对Server端真是舒一口气！
然而用和谐统一的Universal Javascript还真非常有助于做这样的事情！
然而用和谐统一的Universal Javascript还真非常有助于做这样的事情！
因为如果这个逻辑不是保密的，我就让他道Client端执行就好了？反正现在浏览器牛逼的不得了。
从另一个角度说，MVC中大部分，可能就要大部分迁移到Client端来实现了，如图：
原来是这样：
现在是
：
（PS，具体怎么做，请参考最近火爆的ReactJS,和Angular JS）
然而如果你以为故事结束了？
把这些逻辑迁移到Client可不是Universal Javascript的专利！多少年前的ExtJs就这么做了好吧——当然要承认人家前后端统一语言后是会方便这么搞很多。
Universal Javascript背后支持的Node.js，在Server端还有一些闪闪发光的“新”技术！ （打引号是因为不是他的专利）
也许Node.js还不至于引发技术***产品***（像安卓系统出世那样），毕竟也有点不足之处（源于不少人对Javascript的“歧视”，比如我）。
Node.js 引入的编程模型(函数式编程)，高性能Web流程模型(特化处理线程)。那些新的光芒在Node.js上也许无法引发***，那是迟早的事。
函数式编程
能和函数式编程媲美的就是面向对象编程思想了。这不是什么具体的技术，你可以用任何语言实现。
好处是会让代码1. 更容易看懂，一目了然，2.某些情况下执行效率更高（尾递归，或者Erlang那种并发执行）
PS，虽然都是思想，但不冲突。就像面向过程和面向对象要共存一样，函数式编程往往也是和面向对象编程共存
这样的好处：
-
效率。很多外部IO都需要各种初始化，比如数据库需要建立连接等，如此一来，就不用重复建立这些连接。
-
安全。IO子线程的异常不会影响正常HTTP处理线程的稳定。
前面说，这种方式并不是Node.js的专利。Java的SSH体系就有线程池，可以避免重复建立连接。PHP体系里面虽然没有线程池，但是有DB proxy来保证连接复用，本质上都在解决同一个问题。
然而伟大的是，Node.js强制了这一做法，并且统一化到所有的IO。何况很多小公司小团队，自己维护DB proxy是非常蛋疼的。
曾经看到百度的一个分析统计，IO处理占执行时间的80%以上。所以，可见这一问题之重要。
对比图如下，正常情况的HTTP Server执行流程
：
Node的执行流程：
最后，并不见得Universal Javascript会真的***世界，技术体系背后还有公司的较量。(Node.js是谷歌体系, Java PHP C#等体系背后一样有各种大公司) 但这套技术背后的先进思想，是挡不住的。
拥抱变化，期待和谐统一的世界！
盒马工作强度 25人发布
