Sent at 3:21 PM on Friday
me: 对nodejs正式地关注了下,gmail有比较有用的资源给你。我的看法是,nodejs还不到成熟的时候,你可看看0.8的roadmap:
Sent at 10:44 PM on Friday
me: 其中提及的c++extensions支撑的改进可能是必须的一个环境,这个部位不成熟的话,没有足够的价值:js即使用v8驱动,也不是足够native的策略。
Sent at 10:46 PM on Friday
me: 此外,nodejs和js本质上都有一样的短板:难以模块化,从多个方面来讲难以模块化,那种写出很多prototype和按模块分建文件夹和文件名的方式,依靠的是猪程序员的开发经验来完成的模块化约定,远远达不到实作工程需求,此外,模块管理的效率、策略都还有商榷的余地。
Sent at 10:48 PM on Friday
me: nodejs目前我想到的,用来做快速测试用例的驱动引擎和书写测试用例,似乎面向web开发会比较有用。
Sent at 10:50 PM on Friday
me: 上面的讨论告一段落,现在针对nodejs的创意说说:nodejs的策略是,提升解释语言的效率后令其达到实用价值,从而使得快速迭代开发变得更敏捷更有效率,因为这样你就可以快速试验快速认可快速否决,这和git对代码版本的管理理念很相同,且这一套理念已经在网络上流传了十来年和经受了多层面的考验,google的各个项目运作都是这个样子的。
Sent at 10:54 PM on Friday
me: nodejs的短处在于,js语言的演变历史一直以来是太过随意的编程风格,你固然可以严谨地写代码,但这不是强约束,此外也不太可能强约束。nodejs试图用框架的约定来达到强约束的效果,不过在js上这难度太高。
Sent at 10:56 PM on Friday
me: 另一方面再来讨论:nodejs被号称面向多核、并行计算、无阻塞,然而,本质上说nodejs其实是个单线程的核心,你看看helloworld server的代码就知道了,你需要处理request请求的细节,将长时间的处理用闭包和回调抛出以一边后才能保证request handler足够及时地交出控制流权利,令客户端得到回应。这套模型能运作,但很丑陋。
Sent at 11:02 PM on Friday
me: 任何用过闭包的人,任何写过匿名函数的人,都会有一种冲动,巴不得任何地方都closure起来。
Sent at 11:04 PM on Friday
me: 可惜closure不是万能的,例如相似的逻辑,你必须将闭包抽出成公用函数才是正确的代码风范,否则就不得不拷贝复制类似代码到N处。
Sent at 11:05 PM on Friday
me: 而闭包对于多线程计算或并行计算的作用也是有限的,这需要完备的编译器支持才可以解决多个闭包/线程相互作用时的调度问题,这个方面的问题,恐怕不是v8和nodejs的层面能解决的问题。
Sent at 11:07 PM on Friday
me: 最后一个方面,说说重复造轮子:nodejs要想达到实作目的,还有赖于大量的modules被成熟开发出来,很糟糕的一点是,在nodejs中,你需要处理http协议的细节,cookie的细节,session的细节,mvc架构的细节,……直到某个成熟module搞定这些事情,而用grails/java没有这类问题,底层已经被处理,甚至连mvc也不用重来,有一打以上的框架随你挑选,像springframework作为中间层已经是绝对的标配了,经受住了考验。
Sent at 11:11 PM on Friday
me: 如果要想颠覆性,或许google提出的那个新协议spdy加上一个完全并行计算核心的驱动引擎,才可以达到颠覆性。
nodejs还不行
nodejs更像颠覆快要到来前的一次改革试验田。
Sent at 11:13 PM on Friday