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