JavaScript服务端编程现状
除了枯燥的看看题解,做做题外,偶尔还做做实例,放松放松心情.前段时间也摆弄过Google Engine App(下简称GEA),以前依次在上面部署过Python,Java的应用,不过还真没怎么做真正的开发,一来环境不熟悉,二来功底不够.忽闻AppengineJS发布马上部署了一个,欣喜若狂的打算做个JavaScript(下简称JS)应用,不过静下心来,发现很多问题.
为什么不做JavaScript服务端开发
- 没有合适的JavaScript Runtime(JSR ?)
现在JS之所以能够流行,很大程度上取决于浏览器的普及.浏览网页的时候需要计算一道简单的四则混合运算,你会怎么做?心算?打开计算器然后点几个按钮?我的方法是在浏览器地址栏输入"javascrit:alert(1+2+4*5);".很方便不是么.
但是服务端的情况就不容乐观,除了少数几个解析器能够勉强运行单薄的JS语法,似乎很难让他在服务端大展拳脚.V8?嗯,确实很快,不过还只是个跑在客户端的小伙子.Node.js?嗯,的确提出了很多特性,不过就拿这些特性想征服服务端的开发还是不容乐观.RingoJS?JVM的庞大,让JS无法灵巧的伸展.IronJS?无案例,无图,无真相. - 没有成熟的类库
你愿意在一片荒芜的土地上开荒,还是在肥沃的农田挥锄?
JS在客户端确实意气风发,jQuery,Prototype,YUI,Ext,Dojo等等.无数的框架,为我们的网页动态化提出了解决方案之道.在这百家争鸣的日子里,众多特性,理念,被提出来,链式操作,函数式编程....一片繁华.
反观JS在服务端的表现,集合操作停留在增删改,没有filter,没有order.字符串只能拼接,没有格式化.文件读写就一个CommonJS标准.数据交互的确得益于JSON的流行,很方便,但是数据存储似乎又回到了ASP/VBScript时代. - 标准
就像客户端浏览器对JS的支持参差不齐,服务端对于CommonJS标准也是有待加强.所幸服务端JS没有跨"浏览器"之忧. - 效率
开发效率顶呱呱的JS在服务端由于缺少类库的支持,使得服务端开发相比现存的几个平台(JVM,.NetFX),慢了不止几个档次.客户端就备受诟病的执行效率放到服务端仍旧是一个不可忽视的问题.
为什么要看好JavaScript服务端开发
- 灵巧
没人否认JS本身强大的灵活性,强大的自解析,原型链和弱类型衍生出的种样繁多的开发方式.实在是让人爱不释手. - 普及
JSON确实有XML不可比拟的潜质,体积瘦小,方便传输.众多语言中都有支持.客户端无需插件就能原生解析.还有什么比这更棒的么? - 活跃的社区
一个篱笆三个桩,一个好汉三个帮.活跃的JS社区不会甘心JS止步与客户端,必然会向服务端虎视眈眈.
AppengineJS使用一段时间后有感而发.