永远不会完的开场白

长久以来，js 在服务端中只是配角。虽然从96年开始，浏览器鼻祖 Netscape 已经开始有意识地在服务端应用到出自自己之手的 JavaScript?，作为与前端语言配合在一起构成同一种语言，从而完成“一条龙”开发的目的，但是，结果却是，随着 JavaScript? 早期不完善和 Netscape 自身没落等诸多原因，Server Side JavaScript? 不仅没有业界所重视，而且几乎到底被人完全“遗忘”的阶段……

“昨天的新闻就是今天的历史。”

今天的 js 之所以能够摇身一变，蔚然成为 web 开发主流语言，想必列为看官都有各自认为它合理的原因。不过，在下这里仍想分析一下服务端使用 js 的好处：

首先，当然是如前面所说，客户端与服务端使用同一种语言开发，也就是我们 edk 库所提倡的“前后合一”。因为有不少部分特别是越底层的部分，也可能共性出来，作为 common 模板共享前、后端运行时。这一点特性不仅很“现实”，而且很“可行”，因为大家都是知道，前端为 js 的运行条件这个已经具有不可代替性，我意思说“首屈一指”的，首先先是支持了 js 再其他的 flash/swing 的等等。客户端的部署，说缺 flash/jre 说得过去，装一个不就是了，可是说缺 js 那就有点不太像话了吧！？咱们从“木桶最短那块”的原理去理解就很好理解了。这样说，前端 js 不能变，等于后端统一语言的话，只能是 js 了。

其次，JavaScript? 作为一门既陌生又老到的语言，本身就是一个“大宝矿”，学习 JavaScript? 可以学到许多新的东西。为什么说 js 是“大宝矿”？如果用一个简洁的等式去表达 js，那么可以说“js = c + lisp + Prototype OO”最贴切不过了。lisp 那是一门古老的语言，以独特的语法和函数式学问独领翘楚，早在上世纪六十年代已经有成熟的研究成果，但碍于许多硬伤的问题比如首当其冲的性能问题而没有被广泛使用，可以说，较多的时候只是“养在深闺无人识”，停留在实验室，或者研究者的论文中。甚幸的是，在业界充分学习、投入、实践 OO 等之后，仿佛把目光转向另一边厢的函数式编程，纷纷“如获至宝”。于是，这个乖张的 js 又再一次暴露了其充分其貌不扬的 fp 特性！闭包、高阶函数、list 处理……但凡属于 fp 特性的，大多都可以在 js 上不那么别扭（相比命令式的别扭）的语法实现，而且关键的是，那一切，都披上了 C Style 语法的外衣！必须提到的是，语言亲和力，也就是第一时间接触到的地方，如果已经是我们所熟悉、所习惯的语言，那么不言而喻，将是十分友好的讯息。而即使是 Scale 等的混合 oo 与 fp 的新语言，也是后来的事情。我们无声无息地写出 js 代码，但也可能处处充满着 fp 的气息。可以这么说，只要能把 fp 的思想领会在心，那么换到别的语言，也是可以透过某些途径来实现的。可是在 js 中，那的确是轻易以举办到的事情。我学习 fp 的程度不深，只知道 fp 很好很强大。既然 js 天然是 c + lisp，因此也希望在自己写的库中，多实践或运用 fp。对 fp 有兴趣的朋友可以从我这篇博文开始了解一下 js 的 fp 编程（http://blog.csdn.net/zhangxin09/article/details/5716697 ）。

最后说说 js 引擎的性能。旧有的 js 引擎固然很慢，包括当前 asp 的 Jscript.dll，但是对于学习和实验来说，已经足够。以 v8 为代表的新型的js引擎解释速度就很快，这一点足以让我们应用层面的开发者可以省心的了，起码把动态语言“慢”的包袱卸下不少。不仅如此，还要必须要指出的是，之所以基于 v8 的 node.js 如此之快，究其原因，与 js 剑走偏锋的设计是十分吻合的，其锋芒之处的亮点在于以浑然一体“单线程、事件驱动、非阻塞异步模型”之特性直接 PK 多线程编程模型，特别在应对长链接、高并发的场景中，效率相当抢眼给力。关于 nodejs 和 js 之间的相得益彰，不妨留意一下我早期写的一文《漫谈 nodejs（ http://blog.csdn.net/zhangxin09/article/details/5874632 ）》。

罗列以上的方方面面的好处，无非围绕开发效率、语言魅力、机器效率等的范畴去讨论，以此强调 edk.js 的开发初衷为何。——想必至此，大家已经有清晰的概念了。