首页 > 代码库 > 有点担心Node.js的未来了

有点担心Node.js的未来了

      原创文章转载请注明出处:@协思, http://zeeman.cnblogs.com

      首先本文的目的不是引发语言之争,纯属个人的一些思绪记录。

      因为工作原因,用Node.js做过几个项目,基本都是涉及REST方面的。有一个涉及消息转发的服务,分别部署到6台服务器,目前已经成功处理数亿的消息,没有发生消息丢失,总体运行稳定,说明Node用在产线环境是能经受考验的。

 

      今年Node社区发生了一件大事,那就是Express作者TJ大神转投Go的怀抱,理由是大神要做云端程序开发。作为悲催的偏后端码农,开始怀疑Node在后端的表现,有了以下偏见:

 

      1. Node是运行在V8之上的,虽然有的模块已经被改良,但基因没变,而V8是为桌面浏览器设计的,服务端毕竟要求会苛刻一些。

      2. Node作为Javascript运行环境,而Javascript的发展受限于ECMA规范,ECMA规范可能是双刃剑。

      3. 总感觉event loop比较脆弱, 可以充分利用IO, 但无法执行CPU密集性工作,多核运行需要require cluster,一直觉得这种做法有点山寨。

      4. Callback层次的问题,可以用async等库进行改善,但还是觉得山寨。业务逻辑在回调机制下支离破碎,凡人难以理解。

      5. 生态的问题,Javascript由于门槛低,github各种node库相当泛滥,质量参差不齐,好在有源代码,踩坑了再回来填坑。

      6. 一些第三方库或为了追求性能,或为了突破限制,需要结合Node源码进行编译,总觉得不够环保。特别是产线服务器不能访问外网的情况下,就要抓狂了。

      7. 我自己Javascript水平不怎么样,也就认为弱类型语言可维护性不如强类型语言,单元测试可以保证正确性,但难以重构。

 

      基于以上莫须有的理由,我不知道Node 1.0以后的路会怎么走? 往哪方面走?还能走多远? 目前1.0已经有些难产…

 

      建议:暂时不要将Node用于核心业务, 虽然paypal宣称已经这样干了。充分利用Node的优势,做和前端交互性的工作,并且是在规模不大的时候。如果把后端系统想象成一个鸡蛋的话,那蛋黄就不要用Node来做,一家之言。

有点担心Node.js的未来了