主题 : 重复创建多个node如何避免反复调用CSLoader::createNode
级别: 新手上路
可可豆: 198 CB
威望: 188 点
在线时间: 75(时)
发自: Web Page
重复创建多个node如何避免反复调用CSLoader::createNode&&&
我们现在设计了一个动画放在csb文件中，并且需要在游戏逻辑中需要进行大量的动态添加。现在每次添加重复的动画节点都需要调用一次CSLoader::createNode，而cocos目前的设计里面我们看到，每次CSLoader::createNode都需要文件io读取。这样性能太低了，有没有直接的复制函数可以复制已经创建过的node？
级别: 骑士
可可豆: 1440 CB
威望: 1576 点
在线时间: 990(时)
发自: Web Page
你说的是 Clone 方法吗? ...
&/br&  待续... etc. 微博 @小糊涂cnsoft
级别: 新手上路
可可豆: 198 CB
威望: 188 点
在线时间: 75(时)
发自: Web Page
对，找到了，直接调用clone方法就行么？
级别: 骑士
可可豆: 395 CB
威望: 386 点
在线时间: 857(时)
发自: Web Page
看看有没有文件缓存的方法&& 加载一次&&缓存文件内容到内存中， 下次从内存取&& 另外没用过你说的那些东西 只是提供思路
/ColaZhang/
级别: 新手上路
可可豆: 3 CB
威望: 3 点
在线时间: 17(时)
发自: Web Page
哪里有Clone的方法?
级别: 新手上路
可可豆: 14 CB
威望: 14 点
在线时间: 61(时)
发自: Web Page
Clone方法不适用与cocos原先的节点类型，比如Node、Sprite等，所以，我们直接使用的CSLoader的createNodeWithFlatBuffers方法，但是发现再一个for循环中的话内存会首先持续增高，然后再下来，但是如果实在太高的话就会造成程序闪退，不知道楼主找到原因了没有。
关注本帖(如果有新回复会站内信通知您)
苹果公司现任CEO是谁？2字 正确答案:库克
发帖、回帖都会得到可观的积分奖励。
按"Ctrl+Enter"直接提交
关注CocoaChina
关注微信 每日推荐
扫一扫 浏览移动版966,690 二月 独立访问用户
语言 & 开发
架构 & 设计
文化 & 方法
您目前处于：
我为什么反对用Node
我为什么反对用Node
日. 估计阅读时间:
欲知区块链、VR、TensorFlow等潮流技术和框架，请锁定
相关厂商内容
Node能够火起来最重要的原因还是它的确给我们的开发带来了很多好处：
基于事件驱动
Node还有其它一些优点如单线程，总体来说Node是为轻量级的分布式的实时数据服务这类应用提供运行容器而设计的，这类应用很容易想到微博、Facebook这类典型场景，需要非常实时化、个性化、高并发的数据服务。
为什么火了
今年由于无线终端的兴起，后端要提供基于JSON API的数据接口非常普遍。目前来看公司还存在两种形态：一个是无线作为新系统独立存在于传统PC系统；另外一种是将无线系统合并到老的PC系统，在一个系统里同时支持多端服务。长期来看无线和PC系统的合并是必然，业务上以无线为主，PC仅仅作为一个终端而已，不可能存在无线和PC两套业务逻辑。
那基于无线和PC业务合并，由一个系统提供多终端、多语言适配的角度来看，Node能否在其中扮演传统服务端 MVC中的V角色？
要回答这个问题，我们再设想一下，在多端情形下，需要怎样的交互：PC、手机端、Pad、TV、Car、Watch等其它移动终端。
是Native还是H5
当前移动端主要还是以Native实现为主，从用户体验角度来考虑Native的实现要比H5更流畅，同时Native还可以基于本地做很多在浏览器里不能做的优化，如大数据的存储、可以定制的通信协议、更方便的保持长连接以及更容易实现的实时消息推送。
当然H5也有其无法比拟的优势，客户端更轻量级，服务端发布更迅速，不需要用户升级版本等。长期来看移动端能否会向早期PC那样也从富客户端转向浏览器呢？
我的判断是未必，有几个因素，首先Native实现性能优势相比H5会好很多，当前移动端都在追求极致体验的时代，无疑APP会比H5有很多的优势；其次，移动端屏幕较小，基于网页的交互和APP相比还有很多限制。最重要的是不同的商家是主推带有品牌标识的APP还是向统一的浏览器靠拢，从目前的趋势看，APP 会是手机端上争夺的重点。所以推测直接基于手机端的浏览器的应用不会成为主流前端。
如何实现快速迭代
基于APP的Native如何解决客户端更新和服务端的快速迭代，这个问题是当前正在着力解决的，目前为止有两种思路：一种是客户端用同一种技术开发，然后通过工具编译技术把它编译成不同平台上能够执行的代码，如当前的React Native；另一种思路是将客户端中经常需要更新的模块做成动态推送的，用模板+数据的方式，在不同的客户端平台上实现一个小的解析引擎来实现快速个性化的定制，目前手淘主要采用后面一种实现方式，当然前一种也正在尝试。
那么再说回来，基于前面的这些推断，多终端和服务端交互主要是数据+模板的方式为主，那么服务端提供格式化的数据将成为必然选项。所以涉及到的问题就是服务端既要提供格式化的数据（Http JSON数据），又要支持传统的PC的方式：基于JSON数据渲染出HTML页面，所以很容易想到将渲染层独立出来用Node完成。
真的靠谱吗
既然Node可以带来这么多好处，那么我们不妨就继续向下推演，看是否真的很靠谱？下面看下Node在我们的实际的开发环境中如何使用，在引入Node之前我们有必要先介绍下当前Web服务端架构：
(点击放大图像)
图1. 传统的web架构
在当前这种架构下Node怎么融入进去呢？最保守的一种方案是将当前的Java Web中的VIEW层从MVC中独立出来，交给Node来完成，Java Web只提供基于JSON数据接口给Node调用，架构图变成了如下的形式：
(点击放大图像)
图2. Node作为渲染层加入到传统架构中
很明显的差别是在我们当前的访问路径上多增加了一个Web代理层，而这一层和当前的Web服务器层怎么看都有点别扭，两者同时存在始终觉得有一个是多余的，那么Node能否替代掉Nginx成为Web代理服务器呢？理论上是完全没问题的，就像我们用PHP来代替Java Web开发一样，不过你放到具体的公司运维体系中，你会发现目前在Nginx上的防攻击、限流、数据埋点、热点cache等模块都要在Node上重新开发一遍，最重要的是用Node取代Nginx并不能带来额外的好处，如果你说Node可以渲染页面，那么Nginx的开发会和你讨论Nginx lua模块和Node哪个更合适，所以用Node取代Nginx作为代理服务器也不太现实。
那么Node能否取代前端台的Web系统，成为主流的MVC框架呢？
Node和Java Web一样可以提供MVC管理功能，一个系统中同时存在两套MVC框架显然不合理，那么如果用Node 来替换Java Web的话，服务端的架构变成如下的：
(点击放大图像)
图3. Node替代Java Web
从技术实现上这种架构没什么大问题，就是用Node上的MVC框架如express来替代Java Web中Webx，也就是用JavaScript替换Java，以及整个运行容器和中间件都要替换，那么是否真的带来那么大的好处呢？
我们从语言特性、开发效率和成本因素三个方面来看，Node作为后来者能否比我们现在的Java更优秀。
JavaScript作为Node上运行的语言和Java相比，优缺点很明显。JavaScript语法简单，很容易编写基于事件的驱动的实现。但是JavaScript基于面向对象的描述能力偏弱，不像Java是真正的面向对象语言 ，同时JavaScript的对数据类型定义也比较单一，要么是数值类型要么是字符类型。很明显Java更擅长构建复杂逻辑的大型应用程序，在这一点上JavaScript明显落于下风。
在语言运行效率上，JavaScript本来是解释执行，而Java是编译执行，但是由于Node做了优化，所以运行效率差别不大。
开发效率可以从语言的复杂度、程序员培养、开发工具包的丰富性以及编码效率几个方面比较。
语言的复杂度。Java和JavaScript从开发角度都不需要关心内存的管理，都是基于虚拟机来管理内存，从并发角度来看：JavaScript是基于事件触发的，而Java是基于线程的，JavaScript更占优势。另外JavaScript是无阻塞 I/O的，在I/O效率上JavaScript也更占优势，虽然Java8也将更好的支持异步I/O。
程序员培养。目前Java语言仍然是仅次于c语言的第二大编程语言，而JavaScript排查第10位，Java程序员队伍要比JavaScript大很多，很显然Java程序员招聘要比JavaScript更容易一点。
开发工具包。一个语言的开发效率很多时候要这个语言的支持工具包和组件的丰富性，Java经过这么多年的发展，工具类库已经非常丰富，几乎你想要的工具类库都能在网上找到。JavaScript虽然也发展很长时间，但是基于JavaScript的工具类库主要集中在前端，能够直接用于Node上的仍然很少，当然Node的社区非常活跃，可以预见Node的工具类库增长也会非常迅速。但是短时间内要达到Java的规模尚需时日。
编码效率。Java语言的运行基于JVM，但是Java的部署效率稍差，而JavaScript使测试更加简单，容器重启更快，但是debug机制仍然不完善，所以很难做debug测试。
前面主要是从技术角度考虑，但是如果往Node迁移的话，成本也是一个考虑因素。
首先是学习成本。公司大部分是Java程序员要往Node迁移很明显这个学习成本会非常巨大，即使这个迁移是逐渐的，长期来看仍然是要将一部分Java程序员替换成JavaScript程序员，不管这个程序员是公司内培养的还是从外部招聘的，我们可以算一下帐，公司招聘一个程序员的成本有多大：一个普通的工程师的年薪假定有10w以上，猎头费一般是年薪的20%以上，也就是2w，再加上一个月的实习成本1w，加在一起约3w，对于一个有1w以上开发的大公司成本可想而知，即使是招聘应届生，由于应届生的培养周期更长，所以学习成本会更高。
其次是环境成本。公司的基础服务产品，如中间件都是基于Java开发的，如果要替换成JavaScript 必然要再开发一套，还有配套的运维工具等，这个成本也可想而知。
最后是维护成本。Java和JavaScript都是基于容器运行，JVM和v8引擎相比，程序员显然对JVM更熟悉。另外从排查问题的难易程度来看针对JVM的工具显然更完善。
从上面几个方面来看，当前在阿里要让JavaScript完全取代Java作为后端开发语言，基于Node用JavaScript 实现整个服务层逻辑显然成本会比较高。
我们再换一种角度推演一下，假如我们现在的Web系统都用Node实现，那必然有很多Java工程师会做Node的开发，因为我们现有的前端工程师人数肯定是支撑不了现有的业务发展的。我们假定一部分Java工程师愿意学习JavaScript成为全栈工程师，但是是否同一个人愿意用两种不同的语言完成同一个任务呢，正常来说，如果我能用同一个方式完成全部工作，我为什么要把一个任务分成两种不同的方式来完成，这显然也不太合理。
基于前面的分析，Node不管是在现有基础上单独增加一层还是要整个替换Java Web层都不太合理，那是否意味着这种前后端分离的思路有没有合理之处？有没有更好的实现呢？
传统的MVC Web软件架构将渲染层独立出来交由前端同学控制有其合理性，在当前的多终端开发模式下，将业务逻辑层和前端渲染层分离有利于提升后端的开发效率，后端只需要关注后端的业务逻辑和数据的输出，因为在Native开发下服务端只需要输出JSON数据，客户端的页面渲染有客户端同学完成。H5和PC需要的HTML渲染统一交给前端同学完成有利于前端更好的开发模板，从以往的先画好模板（HTML）,给后端同学转化成相应的模板（如Velocity或JSP），然后再基于复杂的Java Web工程下调试页面（前端要独立的运行整个Java Web工程还是相当的困难）。而渲染层全部交给前端的话，前端同学和后端只需要约定好数据后，页面完全由前端同学完成，减少了不少交流成本（不过从淘宝的基于Node实践来看，整个效率提升还不是那么明显，大部分是把原本是后端的开发工作量转嫁给前端了）。
还有一个重要的理由是前端有了渲染层的控制权，前端的开发体验有了不小的提升，说白了就是前端从以往的配合角色转变成一个Web渲染层的Owner，更加有了主人翁角色，如果再维护Node的话，和以往的后端Java开发几乎一样了，而这种前端职责的提升恰恰是从后端削弱过来的，所以第一个出来反对的肯定是后端同学，当前在阿里Node发展比较缓慢我想也有一点关系吧。
再说回来，我们一直讨论的基于Node实现的前端分离方案，可以把他分解一下Node技术和前后端分离。很明显前后端分离在当前多终端背景下有其合理性，但是是否一定要用Node来实现呢？答案是不一定。当前还有两种方案：
将Node层代码抛到Java体系上，如下图：
(点击放大图像)
图4. Node嵌入到Java中
当前的Java8（Nashorn）已经可以支持JavaScript的解析，而Avatar.JS可以将Node无缝迁移过来，但是经过测试，Nashorn+Avatar.JS的执行效率太差，有4到10倍的性能下降，最好也有一半的下降，这样很难达到工程级别的使用。
另外一种就是仍然在基于Java Web体系下，而是将渲染层独立出来，渲染层和业务逻辑层仍然通过JSON（或者大对象）数据交互，使得渲染层既可以在Java上渲染也可以在Node上执行。如下图所示：
(点击放大图像)
图5. Java Web兼容Node的模板层
这种方式与前一种的区别是只做渲染引擎的适配，即模板在Node和Java上都可以解析，而不是把Node的整个MVC都搬过来，由于Node和Java Web上都有控制逻辑（即MVC中的C），所以如果Node和Java中逻辑不一致会导致两边渲染出来的HTML不一致，所以需要把URL改造成满足RESTFULL的格式，尽量把C的逻辑简单化。
上图的架构正是目前我们在详情系统上做的一个实践，成功的关键是将XTPL的模板从Node上无缝迁移到Java上，另外就是保持页面的路由尽量简单，这样前端在Node上开发的重点只是XTPL模板。这种解决方案达到几个目的：
我们的后端系统完成的组件化改造，PC和无线逻辑统一起来了；
将渲染层独立，渲染层后业务量逻辑层通过JSON数据对象交互；
前端开发同学完全掌握了XTPL+JS逻辑，有更多的掌控力；
前端开发页面不需要依赖后端的Java系统，调试页面可以在Node中完成；
系统的架构并没有增加一层，运维上也没有引入新的Node系统。
没有无往不能的神器
前面介绍了在现有Java体系下，要将Node替换Java Web其实是比较困难的，所以没有一个技术是无往不能的神器，但是是否意味着Node就没有应用场景了呢？肯定不是，下面这些情况下Node很有用武之地。
创业公司很合适，尤其当创始人之一是熟悉前端的同学的话，用Node实现Web系统很合适，Node和PHP一样具备快速发布的优势，代码copy上去就生效，甚至不需要重启服务器，这一点相比Java有很大的优势。当业务逻辑还没有非常复杂时，JavaScript语言的弱点也没有暴露的那么明显，从系统的维护角度来说，不需要一个工作有两个角色的工程师完成，可以提升开发效率。
重页面交互轻业务逻辑的系统也适合Node来开发，说白了如果Web系统如有一半以上的 工作量都是需要前端同学来完成的话，那还不如把整个系统都交给前端同学来维护。
如果公司的工程师都是全栈工程师能在不同语言之间自由切换，那么也就没有所为的成本一说了。当然这个仍然要受到公司基础环境的约束，如运维和中间件产品仍然不会同时开发两套。
随着技术的不断进步我们的开发模式也在一直发生着变化，早期的页面渲染和业务逻辑全部集中在一起，如ASP、PHP、JSP技术，后来由于业务逻辑不断变得复杂，出现了MVC的开发框架，前后端工程师分工也越发清楚。中间也有过前端工程师负责整个渲染层和控制层的实现如Extjs+Ajax的开发模式，但是由于整个渲染是在浏览器端完成的受制于客户端渲染性能和搜索引擎的收录页面的硬缺陷很难成为主流。一直到今天前后端开发模式仍然是后端工程师管理M和C，而由前端来实现V，开发环境和运行环境是一套，所以开发上的耦合导致沟通和调试成本增加。直到Node的出现缓解了前后端开发上的耦合，但是这种分离仍然是以增加运行时的维护成本来换取开发时的便利，所以我觉得还不是最佳实践。
本文给出的解决方案也是想兼顾开发时的便利而同时也不增加运行时的维护成本为出发点，当然每种方案都不是完美的，找到适合才是最重要的，随着Java中执行JS技术的不断成熟，我想开发环境和运行环境的分离肯定不久就将实现，前后端开发的耦合度也就最终解决。
许令波，2009年毕业加入淘宝，目前负责商品详情业务和稳定性相关工作，长期关注性能优化领域，参与了淘宝高访问量Web系统主要的优化项目，著有《深入分析Java Web技术内幕》一书。 @淘宝君山、、可以联系到我。
感谢对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至。也欢迎大家通过新浪微博（，），微信（微信号：）关注我们，并与我们的编辑和其他读者朋友交流（欢迎加入InfoQ读者交流群）。
Author Contacted
告诉我们您的想法
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
Re: 一点观点
Li Jinggang
图中内容改进
Re: 二点观点
Re: 二点观点
Re: 一点观点
Jane simon
没有无往不能的神器
这篇文章解决的问题没踩到点上
吴敏琦 七念
Re: 这篇文章解决的问题没踩到点上
吴敏琦 七念
感覺就是java碼農對js的發自內心的抵制
建议楼主回到web根本重新学习一遍
感觉看起来很乱，跑题了
web的事web做主
赞同，不反对
前端开发就应该用node.js, 就应该都会node.js
错误还是挺多的
liu daniel
Re: 错误还是挺多的
Re: 错误还是挺多的
Tian Jackson
Dear Nazimi
不要误人子弟
shoyer shoyer
你的反对并不能阻止Node.js继续火
yangweij weijie
Re: 二点观点
Ding Alice
不存在语言之争, 作者只是站在后端的角度看待node取代view层的可行性问题
Re: 不存在语言之争, 作者只是站在后端的角度看待node取代view层的可行性问题
shoyer shoyer
该用还得用
写这篇文章就要做好被喷的准备
chen jinfa
大前端本来就不该有Java什么事
ＩＮＦＯＱ什么时候也开始收水文了？
Chen YuGuo
Java fanboy
Chuck King
Re: 感觉看起来很乱，跑题了
Re: 错误还是挺多的
Re: 不存在语言之争, 作者只是站在后端的角度看待node取代view层的可行性问题
我也是醉了
我现在很有理由怀疑阿里的服务器并发能力
nodejs并不是一无是处的
果然写 Java 的人认为什么语言都应该和 Java 一样
Carter Jim
重要的是成本，而非技术
Re: 我也是醉了
java拯救世界,java拯救全宇宙了?
Re: Java fanboy
Huang Jason
Re: 不存在语言之争, 作者只是站在后端的角度看待node取代view层的可行性问题
sun shumin
还能好好聊天么..
will cheng
题目偏题了
Baoorng Li
Re: 不要误人子弟
作者的标题是“我为什么反对用Node”
Re: 作者的标题是“我为什么反对用Node”
标题有误导
Node有它使用的场景
天猫前端已经全部用node.js代替java了，只能说楼主预测完全错误。、
不错的文章
不错的文章
node必将崛起
误人子弟的文章
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p
当有人回复此评论时请E-mail通知我
赞助商链接
InfoQ每周精要
通过个性化定制的新闻邮件、RSS Feeds和InfoQ业界邮件通知，保持您对感兴趣的社区内容的时刻关注。
架构 & 设计
文化 & 方法
<及所有内容，版权所有 &#169;
C4Media Inc.
服务器由 提供, 我们最信赖的ISP伙伴。
北京创新网媒广告有限公司
京ICP备号-7
注意：如果要修改您的邮箱，我们将会发送确认邮件到您原来的邮箱。
使用现有的公司名称
修改公司名称为：
公司性质：
使用现有的公司性质
修改公司性质为:
使用现有的公司规模
修改公司规模为：
使用现在的国家
使用现在的省份
Subscribe to our newsletter?
Subscribe to our industry email notices?
我们发现您在使用ad blocker。
我们理解您使用ad blocker的初衷，但为了保证InfoQ能够继续以免费方式为您服务，我们需要您的支持。InfoQ绝不会在未经您许可的情况下将您的数据提供给第三方。我们仅将其用于向读者发送相关广告内容。请您将InfoQ添加至白名单，感谢您的理解与支持。如何看待 TJ 宣布退出 Node.js 开发，转向 Go？
| Go语言中文网 | Golang中文社区 | Golang中国
<meta name="author" content="polaris ">
如何看待 TJ 宣布退出 Node.js 开发，转向 Go？
如何看待 TJ 宣布退出 Node.js 开发，转向 Go？
TJ何许人也？
他medium自我介绍：，程序员兼艺术家，Koa、Co、Express、jade、mocha、node-canvas、commander.js等知名开源项目的创建和贡献者。
社区影响：
第一页出现次数最多的那个少年
—高产到令人发指，Quora上甚至有人猜测TJ不是一个人，而事实上他就是一个人。
npm社区代码贡献截止目前占到整个社区的3.04%
tjholowaychuk
samuraijack
creationix
TooTallNate
个人对他的印象：TJ大神、visionmedia、潮男、酷炫、杀马特
TJ绝对是这一两年node社区的“弄潮儿”+“精神领袖”。
引用一个知友的话说，
任何一个做node.js开发的人, 一定都直接或间接引用过他写的库。这里说的是任何, everyone!
他写一个co, 立马就会有无数叫co-*的项目出现。
他写一个koa, 立马就会有无数叫koa-*的项目出现。
他从npm社区诞生之初就开发了commander.js、node-canvas等著名模块。
随后他又开发了Express.js、jade、EJS等web开发系列框架和库。
最近一段时间，他把精力放在了运用ES6特性解决javascript回调金字塔的问题的Co库和下一代node web开发框架koa，而这两个模块虽然目前知名度不如express.js，但未来会是红得发紫的技术。
他创建并参与的开源项目实在是太多，以至于随便在他github上找个仓库, 就有上千上万的stars。
最近随着我在工作中无意得知并使用了co和koa来进行开发web后端开发，越发觉得这位TJ大神真是node社区的明灯，这一两年他在我心目中的地位逐渐上升甚至超过了node核心开发团队，相信很多人内心都有相同的感受。
他在博客上的告别文章，并不意味着他当即完全告别node开发，co和koa这俩大有前途的框架仍会继续维护，其他的项目会转交给别人维护（言外之意要将其他烂摊子全部丢掉？）。
在他的文中，他提到node不再适合当下他开发的软件了，并且他选择了Go：
If you’re doing distributed work then you’ll find Go’s expressive concurrency primitives very helpful. We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there. Without separate stacks error
handling & reporting will be mediocre at best. I also don’t want to wait 3 years for the community to defragment, when we have solutions that work now, and work well.
Go有表现力的原生并发特性对开发分布式任务非常有效，即便是ES6引入的generator也只能满足他一半的需求，node并没有独立的错误处理栈。TJ接下来因为工作需要，要从事分布式软件的开发，显然Go是更合适的选择。
错误处理一直是是JS遗留的比较深的坑了，需要一些时间来填。TJ不愿意花3年的时间等待node社区将坑全部填了，或许还表达出他对node社区和核心开发团队的些许“不满”。
个人认为，稳定、高性能、分布式的纯后台开发，例如交易系统，Go、Java和C++是更佳选择，尤其是专为分布式设计的Go，只是当下人才还比较少；
对于主要处理前台展现的web工程，node是不错的选择，毕竟性能也尚可，前端工程师可以“前后通吃”，还是看好node在将来会是前后端分工的分界线。
反对，不会显示你的姓名
我本来自己写了个基于lua协程调度的并发库levent（），后来用go越来越顺手，感觉levent的价值不太大，就慢慢停更了。这哥们会不会和我一样想法？
再放个大招。nodejs用异步回调并发，比协程丑陋不是一星半点。可能存在的唯一理由就是v8引擎的强大了。。。
反对，不会显示你的姓名
我是从强类型静态语言（15年）转到 Node.js + JS 这种动态语言的(3年)。而 TJ 是从动态语言（Flash 的 ActionScript 起步）转到 Go的。可以说两个世界各有自己的优缺点。
Node.js + JS 可以说是用来包容各种可能性的。我用的时候是从照搬之前的OO概念，到后来的函数式编程，流编程（应该算一种特殊的函数式编程），发现世界上的问题真的是没有最优解。每年都能在 node.js 社区发现全新的颠覆思维惯性的新可能。例如，编写真正前后端复用的代码，然后通过 Browserify 在客户端复用；通过 Stream 来连接各个应用组件；基于 LevelDB 构建自己的数据库。
Callback Hell 我通过以下几个方面克服：
1. CoffeeScript：从视觉上减少嵌套干扰。
2. npm 哲学，将你的代码抽象出尽量小的重用部分，单元测试覆盖，分而治之。
3. 新的连接架构，例如: stream，或者类似 express 的插件机制
大约1年后，我就不觉得这是一个困扰了，而收获却是性能。目前，回调逻辑比任何其他方法都能确保并发性能。这一点 TJ 提到了，你是要“performance” 还是&#34;usability&#34;，他的选择是“usability”，毕竟他是从 JS 走向强类型，而不是反过来的。
但是不得不说，越多的可能性对开发者的素质要求越高。如果团队成员中缺少那些“真正的老兵”，那么我会选择类似于 Go、Java 或者 .NET 这种强类型系统，毕竟可以有紧密的编程范式来约束大家，省得犯低级错误。
谁都没想到，JS的成就其实来自于自身的缺陷（非常松散的语法），各种软件方法学都在这里碰撞。这和 Go 是完全不同的。
另外, Go 包管理由于不支持 Side-by-side 的包引用(算是静态语言的一种限制吧)，因此很难让 Go Package 社区（无论是否有集中存储） 形成像 npm module 这样的生产力井喷效果。
反对，不会显示你的姓名
TJ是个理性的工程师，语言只是工具，什么工具干什么事情，他在告别node的文章中也说了，如果web开发他还是会用node，只不过现在他要转向分布式系统的开发了，所以选择了更加适合的工具golang，这没有什么好奇怪的啊，如果你老板现在突然让你做嵌入式开发你能不转c和汇编吗？
反对，不会显示你的姓名
仔细看看他的博客，写的很清楚了。他的兴趣是在分布式计算上，这个领域用Go当然是最合适不过，他还会继续维护koajs，其他项目则在找人接手。
提到了一些nodejs的缺点，易用性，工具、debug、错误信息，这些都是nodejs客观存在的问题，JS语言的先天不足在服务端语境中被放大了。
当年mogorel的作者Zed Shaw谩骂式地宣布脱离ruby圈子转投python，这兄弟表现得够理智了，纯粹是由于技术选择，而不是出于厌恶社区的自满（当然也有一些对joyent团队不聚焦到易用性上的不满）。
我觉得不必过于放大事情的影响，但可以让nodejs粉丝们更加客观一点，给nodejs做出更准确的定位，那就是好事。
反对，不会显示你的姓名
谢不愿意透露姓名的UC前端号称第二强的 人肉邀请……
虽然语言只是工具，但是对于做的事而言，正确的“工具”往往会达到事半功倍的效果。在这一点上我一直认为，前后端统一也就是个笑话。
即便不说JS语言层面上的天生弊端，比如过于灵活以至于混乱的语法带来的工程上维护成本的巨大，V8本身的稳定性对于后端而言就是个巨大的挑战。Google V8起源于Chome，追求速度，以空间换时间的做法在当前大内存时代并不那么硬伤，稳定性稍差也不是什么很致命的事。但是在服务器上，一寸内存一寸血，谁都不像OOM以至于Crash。速度快慢也没那么重要，服务端追求扩展性，在数百数千甚至数万这个量级上单台服务器极致性能往往没那么重要。在这个基础上，稳定性和可用性最终决定了你服务质量，而这些，都是目前V8或者说node的短板。
同时，服务端要求对所用的技术有足够的可控性，node或者说js大量的black magic削弱了系统工程师在这方面对其的信任，出了问题没办法调，找不出bug，downtime上升，谁负责？
为何Java被人喷死板依旧占据了那么大的份额？为何C那么老依旧是服务端程序猿的基础？为何Python慢成狗还是有很多公司青睐？无他，只是因为他们经过了大量的考验，证明是可靠的并且可控的罢了。况且即便是Python，最新一系列技术加持之后，对比Node还真不慢……
至于为何转向Go？我个人认为Go抓牢了服务端开发的几个大需求，首先是抹平服务器差异，俗称跨平台。然后是标准库做得很相对而言很强大，系统细节屏蔽得很不错。再者是语言层面即满足了脚本小子们所需要的动态性和开发效率，也满足了系统工程师的静态需求来维持项目的有序性和最终输出结果的效率。同时对于未来服务端开发趋势的迎合，比如原生Coroutine并且极力的优化其内存消耗等特性，对于服务端开发而言是极大的提高了生产力的同时也让代码逻辑和可读性大大的提升。基于以上几点，Go确实是当下作为性能型服务端开发语言中比较好的选择。
而Node的核心V8，作为一个桌面项目，在这些方面缺陷太过于明显。做demo不错，上到工程级别就WTF了，至少对于我来说，lua/python/go，甚至是未来的rust，都是更好的选择。
反对，不会显示你的姓名
TJ文章开头说了，他在nodejs方面做很久了，没激情了，并且最近在做的分布式系统让他觉得Go更合适，所以他发一遍文章正式告别nodejs社区，顺便找有兴趣维护他原先项目的人。
我跑他主页逛了逛（），照片拍得很棒，另外头像很杀马特。。。从哪个角度看，这个小伙子都是个比较感性，比较完美主义的人。会因为激情和审美的原因换语言再正常不过了吧。
小伙子不止长得帅，技术还那么牛，摄影也那么棒，不得不感叹：这人和人的差距咋就那么大哩？
反对，不会显示你的姓名
我就纳闷了为什么同样Python twisted也是异步处理就没有大多数技术人员推。好了么，诚如我之前面试时候回答的那样，node.js的callback巨坑而且非coroutine方式处理。我如果需要并行处理的话直接会选择golang连python gevent都不会考虑。
反对，不会显示你的姓名
现在是动态语言一生黑，js缺点前面各位也说了，调试困难调试困难调试困难调试困难调试困难！！！
前后端统一语言没看到什么优点和必要性，在大公司有各种语言实现的基础设施，单node玩不转。甚至go也不好用，现在干活都是在写业务逻辑，用node/go节省不了什么时间，而且那么多周边设施:db proxy /cache service/其他部门外部接口，挨个移植到node、go直至好用实在不容易.
异步callback太难用啦，想想要为每个业务写回调函数就觉得累，逻辑被拆得支离破碎导致阅读困难，代码量更大，RPC才是王道哟。
反对，不会显示你的姓名
Node 是 JavaScript the good parts，Go 是着眼设计一门替代性的编程语言，坑多没办法。
对前端和 Web 来说 Node 极好，Node 流行主要因此。而这不代表 JavaScript 就是很好的。
Go 对于动态语言用户来说相当友好。
不了解 TJ, 作为一个不会 Java 的前端, 我学习编程过程中用了大量 TJ 写的工具,
比如 Stylus, Debug, Jade, Express, EJS, 相信很多人也是
TJ 据传有超高的生产力, 这种东西是我们非常向往的, 我个人也很渴望有那样能力,
当然我有同样的追求工具高效的想法, 不代表能了解 TJ 其他的想法...
我很早就想摆脱 JS 动态语言, 用静态类型编程, 却一直不成, 直到 Go 进入视野
Go 语言有 Slice 类型, 操作近似 Array, 有 Map 类型, 形似 JavaScript 中 Object 的使用,
另外 Go 也支持函数式的闭包, 自动垃圾回收等等, 这对于开发效率来说很好
我渐渐有想, 动态语言究竟为何流行起来的, 出来易学, 有那样多的缺陷,
首先是随意被人吐槽的性能问题, 到了 JavaScript 特别又指出弱类型的调试问题,
甚至 JavaScript 语法当中大量的设计糟糕的语法也常常被作为嘲笑的对象,
Google 设想替代 JavaScript 的 Dart, 采用的是可选的静态类型, 还有无视了原型继承
我想 JavaScript 除了意外的成功, 也因为支持函数式特性, 以及灵活的 JSON 结构
而这并不是因为 JavaScript 设计得足够好, 这些特性在 Go 里面依然能做到支持
实际中的 JavaScript 编程, 会有大量的学习时间消耗在学会避免写出低质量的代码
比如随意定义全局变量或者类型构造器属性, 处理分号, 采用恰当的类的实现等等
甚至有将比如从 CoffeeScript 语言编译到 JavaScript 来保证采用的是好的编程风格
当我们写 Node 程序, 依然少不了手动避开语言差的部分, 尽量保持代码清晰
但这样我们仍然受到 JavaScript 弱类型等特性的影响, 而没有强大的类型检查工具
JavaScript 社区, 有大量的水平参差不一的前端后端工程师, 观念上也大量不能统一
后端的开发语言要跟着前端浏览器的实现走, 语法上的问题也不能够随意剔除
我个人觉得存在上述问题, JavaScript 社区的未来已经够令人担忧了
相比之下, Go 语言设计当中对语法, 对性能, 对开发调试的考虑, 都显得周到得多
当存在这样一门语言时, 怎样选择来提高开发的效率, 显得比较清晰了
反对，不会显示你的姓名
技术选择，一定不能“哪个牛逼用哪个”，也不能“哪个时髦用哪个”，更不能“牛人用哪个我就用哪个”。
技术选择，要根据自身团队的特点，加所要开发产品的特点来做判断。
我现在的团地使用的是Node.js，之前用的是PHP前端+Python后端，那时候一个大问题就是团队没几个人，还有好几个语言在使用，当Python部分出问题的时候，其他不擅长Python的队员也帮不上啥忙，当PHP任务比较吃紧时，Python队员又不能雪中送炭，所以那时候就计划把使用的语言和使用的存储方式缩小到尽量小的范围，所以有意训练组员的JavaScript能力，因为JavaScript怎么着大家都要会一点。
当新的产品要开发的时候，发现这个产品明确需要有Server Push的功能，用PHP那一套肯定搞不定了，所以就趁着一个新的开始，全转到Node.js上，这样大家都能专心做一门技术，互相之间也能够有照应。
事实证明，这个选择是正确的。
虽然Node.js有这样那样的缺陷，其他同志所得Callback Hell之类的问题，只要有async、Seq之类工具的辅助，借助良好的单元测试习惯大面积覆盖代码测试，最后写出来的代码质量很高。
还是那句话：会写代码的人，用什么语言都能写好；不会写代码的人，才会纠结于用什么语言更好。
反对，不会显示你的姓名
--------------------------------------日更新--------------------------------------------------------------
前后统一，当时提出来的时候我就非常讶异。难道用JavaScript来写后端，就解决现在后端开发的问题了？难道让JavaScript程序员涉及后端，就能降低开发成本？事实是JavaScript并没有什么优势，而且JavaScript程序员的整体水平是比较低的，他们大部分人并不胜任。能用JavaScript在前后端游刃有余的都是牛人，而牛人用其它语言也能干得一样甚至更好，比如投奔Go的这位。
反对，不会显示你的姓名
一大批Node粉要转Go了
反对，不会显示你的姓名
node.js 最大的优势是并发处理能力，不过这个是通过异步方式来达到的，异步方式非常不适合大脑思考，同步模式下简单的逻辑用异步模式来写也要很复杂的代码。go 提供了相同并发性能的同时却可以让程序员以同步方式编写代码。除了遗留系统和学习成本以外实在想不到还继续用 node.js 的理由。
反对，不会显示你的姓名
我只在一个项目中用NodeJS做过服务器，异步编程有的时候真的让人抓心挠肝，TJ向Joyent提出的建议其实每个Node开发者都有感触。
NodeJS开发的易用性上有两点让人特别痛苦：
1. 各种回调方法使得代码非常难以调试；
2. 如果没有一个比较良好的设计，代码乱得一塌糊涂。
但是从目前的发展状况来看，Go语言比较只是Google一家做出贡献，跟Swift、Object C差不多，真正想要像JavaScript一样得到各家公司的认可还需要更多的努力。
微软、Intel还有几家互联网巨头，明显向JavaScript已经抛出了橄榄枝。所以我的观点是：NodeJS只可能越来越好，易用性上社区会注意到，也会不断改善。
more progressive一点的话，Node最好的情形能够像Java一样运行于各类服务器中，最差的可能也就是像python一样，成为在某个方向上的利器。
反对，不会显示你的姓名
虽然,我想写代码写到万万岁,
但是,我觉得我也不会干一辈子程序员的.
反对，不会显示你的姓名
说真的，TJ没有考虑Scala嘛?
他纯粹是想玩一下新鲜玩意吧，用不着上纲上线。
同步异步这个问题纯粹是个人习惯。你从C++开始学的那么不习惯回调函数异步处理，我就是从Javascript起步的(window.setTimeout是我第一个接触的需要回调函数的地方），然后学C++花了好长时间才明白线程是什么东东。现在仍然喜欢异步回调。
反对，不会显示你的姓名
TJ 说“I also don’t want to wait 3 years for the community to defragment, when we have solutions that work now, and work well.”
结果现在 Node 社区不但没有 &#34;defragment&#34; 反而 fork 出来了 io.js 。。。
希望大神在 Go 社区能继续贡献优质代码和库~
支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
支持 @ 本站用户；支持表情（输入 : 提示），见
TJ何许人也？
他medium自我介绍：，程序员兼艺术家，Koa、Co、Express、jade、mocha、node-canvas、commander.js等知名开源项目的创建和贡献者。
社区影响：
第一页出现次数最多的那个少年
—高产到令人发指，Quora上甚至有人猜测TJ不是一个人，而事实上他就是一个人。
npm社区代码贡献截止目前占到整个社区的3.04%
tjholowaychuk
samuraijack
creationix
TooTallNate
个人对他的印象：TJ大神、visionmedia、潮男、酷炫、杀马特
TJ绝对是这一两年node社区的“弄潮儿”+“精神领袖”。
引用一个知友的话说，
任何一个做node.js开发的人, 一定都直接或间接引用过他写的库。这里说的是任何, everyone!
他写一个co, 立马就会有无数叫co-*的项目出现。
他写一个koa, 立马就会有无数叫koa-*的项目出现。
他从npm社区诞生之初就开发了commander.js、node-canvas等著名模块。
随后他又开发了Express.js、jade、EJS等web开发系列框架和库。
最近一段时间，他把精力放在了运用ES6特性解决javascript回调金字塔的问题的Co库和下一代node web开发框架koa，而这两个模块虽然目前知名度不如express.js，但未来会是红得发紫的技术。
他创建并参与的开源项目实在是太多，以至于随便在他github上找个仓库, 就有上千上万的stars。
最近随着我在工作中无意得知并使用了co和koa来进行开发web后端开发，越发觉得这位TJ大神真是node社区的明灯，这一两年他在我心目中的地位逐渐上升甚至超过了node核心开发团队，相信很多人内心都有相同的感受。
他在博客上的告别文章，并不意味着他当即完全告别node开发，co和koa这俩大有前途的框架仍会继续维护，其他的项目会转交给别人维护（言外之意要将其他烂摊子全部丢掉？）。
在他的文中，他提到node不再适合当下他开发的软件了，并且他选择了Go：
If you’re doing distributed work then you’ll find Go’s expressive concurrency primitives very helpful. We could achieve similar things in Node with generators, but in my opinion generators will only ever get us half way there. Without separate stacks error
handling & reporting will be mediocre at best. I also don’t want to wait 3 years for the community to defragment, when we have solutions that work now, and work well.
Go有表现力的原生并发特性对开发分布式任务非常有效，即便是ES6引入的generator也只能满足他一半的需求，node并没有独立的错误处理栈。TJ接下来因为工作需要，要从事分布式软件的开发，显然Go是更合适的选择。
错误处理一直是是JS遗留的比较深的坑了，需要一些时间来填。TJ不愿意花3年的时间等待node社区将坑全部填了，或许还表达出他对node社区和核心开发团队的些许“不满”。
个人认为，稳定、高性能、分布式的纯后台开发，例如交易系统，Go、Java和C++是更佳选择，尤其是专为分布式设计的Go，只是当下人才还比较少；
对于主要处理前台展现的web工程，node是不错的选择，毕竟性能也尚可，前端工程师可以“前后通吃”，还是看好node在将来会是前后端分工的分界线。
反对，不会显示你的姓名
我本来自己写了个基于lua协程调度的并发库levent（），后来用go越来越顺手，感觉levent的价值不太大，就慢慢停更了。这哥们会不会和我一样想法？
再放个大招。nodejs用异步回调并发，比协程丑陋不是一星半点。可能存在的唯一理由就是v8引擎的强大了。。。
反对，不会显示你的姓名
我是从强类型静态语言（15年）转到 Node.js + JS 这种动态语言的(3年)。而 TJ 是从动态语言（Flash 的 ActionScript 起步）转到 Go的。可以说两个世界各有自己的优缺点。
Node.js + JS 可以说是用来包容各种可能性的。我用的时候是从照搬之前的OO概念，到后来的函数式编程，流编程（应该算一种特殊的函数式编程），发现世界上的问题真的是没有最优解。每年都能在 node.js 社区发现全新的颠覆思维惯性的新可能。例如，编写真正前后端复用的代码，然后通过 Browserify 在客户端复用；通过 Stream 来连接各个应用组件；基于 LevelDB 构建自己的数据库。
Callback Hell 我通过以下几个方面克服：
1. CoffeeScript：从视觉上减少嵌套干扰。
2. npm 哲学，将你的代码抽象出尽量小的重用部分，单元测试覆盖，分而治之。
3. 新的连接架构，例如: stream，或者类似 express 的插件机制
大约1年后，我就不觉得这是一个困扰了，而收获却是性能。目前，回调逻辑比任何其他方法都能确保并发性能。这一点 TJ 提到了，你是要“performance” 还是&#34;usability&#34;，他的选择是“usability”，毕竟他是从 JS 走向强类型，而不是反过来的。
但是不得不说，越多的可能性对开发者的素质要求越高。如果团队成员中缺少那些“真正的老兵”，那么我会选择类似于 Go、Java 或者 .NET 这种强类型系统，毕竟可以有紧密的编程范式来约束大家，省得犯低级错误。
谁都没想到，JS的成就其实来自于自身的缺陷（非常松散的语法），各种软件方法学都在这里碰撞。这和 Go 是完全不同的。
另外, Go 包管理由于不支持 Side-by-side 的包引用(算是静态语言的一种限制吧)，因此很难让 Go Package 社区（无论是否有集中存储） 形成像 npm module 这样的生产力井喷效果。
反对，不会显示你的姓名
TJ是个理性的工程师，语言只是工具，什么工具干什么事情，他在告别node的文章中也说了，如果web开发他还是会用node，只不过现在他要转向分布式系统的开发了，所以选择了更加适合的工具golang，这没有什么好奇怪的啊，如果你老板现在突然让你做嵌入式开发你能不转c和汇编吗？
反对，不会显示你的姓名
仔细看看他的博客，写的很清楚了。他的兴趣是在分布式计算上，这个领域用Go当然是最合适不过，他还会继续维护koajs，其他项目则在找人接手。
提到了一些nodejs的缺点，易用性，工具、debug、错误信息，这些都是nodejs客观存在的问题，JS语言的先天不足在服务端语境中被放大了。
当年mogorel的作者Zed Shaw谩骂式地宣布脱离ruby圈子转投python，这兄弟表现得够理智了，纯粹是由于技术选择，而不是出于厌恶社区的自满（当然也有一些对joyent团队不聚焦到易用性上的不满）。
我觉得不必过于放大事情的影响，但可以让nodejs粉丝们更加客观一点，给nodejs做出更准确的定位，那就是好事。
反对，不会显示你的姓名
谢不愿意透露姓名的UC前端号称第二强的 人肉邀请……
虽然语言只是工具，但是对于做的事而言，正确的“工具”往往会达到事半功倍的效果。在这一点上我一直认为，前后端统一也就是个笑话。
即便不说JS语言层面上的天生弊端，比如过于灵活以至于混乱的语法带来的工程上维护成本的巨大，V8本身的稳定性对于后端而言就是个巨大的挑战。Google V8起源于Chome，追求速度，以空间换时间的做法在当前大内存时代并不那么硬伤，稳定性稍差也不是什么很致命的事。但是在服务器上，一寸内存一寸血，谁都不像OOM以至于Crash。速度快慢也没那么重要，服务端追求扩展性，在数百数千甚至数万这个量级上单台服务器极致性能往往没那么重要。在这个基础上，稳定性和可用性最终决定了你服务质量，而这些，都是目前V8或者说node的短板。
同时，服务端要求对所用的技术有足够的可控性，node或者说js大量的black magic削弱了系统工程师在这方面对其的信任，出了问题没办法调，找不出bug，downtime上升，谁负责？
为何Java被人喷死板依旧占据了那么大的份额？为何C那么老依旧是服务端程序猿的基础？为何Python慢成狗还是有很多公司青睐？无他，只是因为他们经过了大量的考验，证明是可靠的并且可控的罢了。况且即便是Python，最新一系列技术加持之后，对比Node还真不慢……
至于为何转向Go？我个人认为Go抓牢了服务端开发的几个大需求，首先是抹平服务器差异，俗称跨平台。然后是标准库做得很相对而言很强大，系统细节屏蔽得很不错。再者是语言层面即满足了脚本小子们所需要的动态性和开发效率，也满足了系统工程师的静态需求来维持项目的有序性和最终输出结果的效率。同时对于未来服务端开发趋势的迎合，比如原生Coroutine并且极力的优化其内存消耗等特性，对于服务端开发而言是极大的提高了生产力的同时也让代码逻辑和可读性大大的提升。基于以上几点，Go确实是当下作为性能型服务端开发语言中比较好的选择。
而Node的核心V8，作为一个桌面项目，在这些方面缺陷太过于明显。做demo不错，上到工程级别就WTF了，至少对于我来说，lua/python/go，甚至是未来的rust，都是更好的选择。
反对，不会显示你的姓名
TJ文章开头说了，他在nodejs方面做很久了，没激情了，并且最近在做的分布式系统让他觉得Go更合适，所以他发一遍文章正式告别nodejs社区，顺便找有兴趣维护他原先项目的人。
我跑他主页逛了逛（），照片拍得很棒，另外头像很杀马特。。。从哪个角度看，这个小伙子都是个比较感性，比较完美主义的人。会因为激情和审美的原因换语言再正常不过了吧。
小伙子不止长得帅，技术还那么牛，摄影也那么棒，不得不感叹：这人和人的差距咋就那么大哩？
反对，不会显示你的姓名
我就纳闷了为什么同样Python twisted也是异步处理就没有大多数技术人员推。好了么，诚如我之前面试时候回答的那样，node.js的callback巨坑而且非coroutine方式处理。我如果需要并行处理的话直接会选择golang连python gevent都不会考虑。
反对，不会显示你的姓名
现在是动态语言一生黑，js缺点前面各位也说了，调试困难调试困难调试困难调试困难调试困难！！！
前后端统一语言没看到什么优点和必要性，在大公司有各种语言实现的基础设施，单node玩不转。甚至go也不好用，现在干活都是在写业务逻辑，用node/go节省不了什么时间，而且那么多周边设施:db proxy /cache service/其他部门外部接口，挨个移植到node、go直至好用实在不容易.
异步callback太难用啦，想想要为每个业务写回调函数就觉得累，逻辑被拆得支离破碎导致阅读困难，代码量更大，RPC才是王道哟。
反对，不会显示你的姓名
Node 是 JavaScript the good parts，Go 是着眼设计一门替代性的编程语言，坑多没办法。
对前端和 Web 来说 Node 极好，Node 流行主要因此。而这不代表 JavaScript 就是很好的。
Go 对于动态语言用户来说相当友好。
不了解 TJ, 作为一个不会 Java 的前端, 我学习编程过程中用了大量 TJ 写的工具,
比如 Stylus, Debug, Jade, Express, EJS, 相信很多人也是
TJ 据传有超高的生产力, 这种东西是我们非常向往的, 我个人也很渴望有那样能力,
当然我有同样的追求工具高效的想法, 不代表能了解 TJ 其他的想法...
我很早就想摆脱 JS 动态语言, 用静态类型编程, 却一直不成, 直到 Go 进入视野
Go 语言有 Slice 类型, 操作近似 Array, 有 Map 类型, 形似 JavaScript 中 Object 的使用,
另外 Go 也支持函数式的闭包, 自动垃圾回收等等, 这对于开发效率来说很好
我渐渐有想, 动态语言究竟为何流行起来的, 出来易学, 有那样多的缺陷,
首先是随意被人吐槽的性能问题, 到了 JavaScript 特别又指出弱类型的调试问题,
甚至 JavaScript 语法当中大量的设计糟糕的语法也常常被作为嘲笑的对象,
Google 设想替代 JavaScript 的 Dart, 采用的是可选的静态类型, 还有无视了原型继承
我想 JavaScript 除了意外的成功, 也因为支持函数式特性, 以及灵活的 JSON 结构
而这并不是因为 JavaScript 设计得足够好, 这些特性在 Go 里面依然能做到支持
实际中的 JavaScript 编程, 会有大量的学习时间消耗在学会避免写出低质量的代码
比如随意定义全局变量或者类型构造器属性, 处理分号, 采用恰当的类的实现等等
甚至有将比如从 CoffeeScript 语言编译到 JavaScript 来保证采用的是好的编程风格
当我们写 Node 程序, 依然少不了手动避开语言差的部分, 尽量保持代码清晰
但这样我们仍然受到 JavaScript 弱类型等特性的影响, 而没有强大的类型检查工具
JavaScript 社区, 有大量的水平参差不一的前端后端工程师, 观念上也大量不能统一
后端的开发语言要跟着前端浏览器的实现走, 语法上的问题也不能够随意剔除
我个人觉得存在上述问题, JavaScript 社区的未来已经够令人担忧了
相比之下, Go 语言设计当中对语法, 对性能, 对开发调试的考虑, 都显得周到得多
当存在这样一门语言时, 怎样选择来提高开发的效率, 显得比较清晰了
反对，不会显示你的姓名
技术选择，一定不能“哪个牛逼用哪个”，也不能“哪个时髦用哪个”，更不能“牛人用哪个我就用哪个”。
技术选择，要根据自身团队的特点，加所要开发产品的特点来做判断。
我现在的团地使用的是Node.js，之前用的是PHP前端+Python后端，那时候一个大问题就是团队没几个人，还有好几个语言在使用，当Python部分出问题的时候，其他不擅长Python的队员也帮不上啥忙，当PHP任务比较吃紧时，Python队员又不能雪中送炭，所以那时候就计划把使用的语言和使用的存储方式缩小到尽量小的范围，所以有意训练组员的JavaScript能力，因为JavaScript怎么着大家都要会一点。
当新的产品要开发的时候，发现这个产品明确需要有Server Push的功能，用PHP那一套肯定搞不定了，所以就趁着一个新的开始，全转到Node.js上，这样大家都能专心做一门技术，互相之间也能够有照应。
事实证明，这个选择是正确的。
虽然Node.js有这样那样的缺陷，其他同志所得Callback Hell之类的问题，只要有async、Seq之类工具的辅助，借助良好的单元测试习惯大面积覆盖代码测试，最后写出来的代码质量很高。
还是那句话：会写代码的人，用什么语言都能写好；不会写代码的人，才会纠结于用什么语言更好。
反对，不会显示你的姓名
--------------------------------------日更新--------------------------------------------------------------
前后统一，当时提出来的时候我就非常讶异。难道用JavaScript来写后端，就解决现在后端开发的问题了？难道让JavaScript程序员涉及后端，就能降低开发成本？事实是JavaScript并没有什么优势，而且JavaScript程序员的整体水平是比较低的，他们大部分人并不胜任。能用JavaScript在前后端游刃有余的都是牛人，而牛人用其它语言也能干得一样甚至更好，比如投奔Go的这位。
反对，不会显示你的姓名
一大批Node粉要转Go了
反对，不会显示你的姓名
node.js 最大的优势是并发处理能力，不过这个是通过异步方式来达到的，异步方式非常不适合大脑思考，同步模式下简单的逻辑用异步模式来写也要很复杂的代码。go 提供了相同并发性能的同时却可以让程序员以同步方式编写代码。除了遗留系统和学习成本以外实在想不到还继续用 node.js 的理由。
反对，不会显示你的姓名
我只在一个项目中用NodeJS做过服务器，异步编程有的时候真的让人抓心挠肝，TJ向Joyent提出的建议其实每个Node开发者都有感触。
NodeJS开发的易用性上有两点让人特别痛苦：
1. 各种回调方法使得代码非常难以调试；
2. 如果没有一个比较良好的设计，代码乱得一塌糊涂。
但是从目前的发展状况来看，Go语言比较只是Google一家做出贡献，跟Swift、Object C差不多，真正想要像JavaScript一样得到各家公司的认可还需要更多的努力。
微软、Intel还有几家互联网巨头，明显向JavaScript已经抛出了橄榄枝。所以我的观点是：NodeJS只可能越来越好，易用性上社区会注意到，也会不断改善。
more progressive一点的话，Node最好的情形能够像Java一样运行于各类服务器中，最差的可能也就是像python一样，成为在某个方向上的利器。
反对，不会显示你的姓名
虽然,我想写代码写到万万岁,
但是,我觉得我也不会干一辈子程序员的.
反对，不会显示你的姓名
说真的，TJ没有考虑Scala嘛?
他纯粹是想玩一下新鲜玩意吧，用不着上纲上线。
同步异步这个问题纯粹是个人习惯。你从C++开始学的那么不习惯回调函数异步处理，我就是从Javascript起步的(window.setTimeout是我第一个接触的需要回调函数的地方），然后学C++花了好长时间才明白线程是什么东东。现在仍然喜欢异步回调。
反对，不会显示你的姓名
TJ 说“I also don’t want to wait 3 years for the community to defragment, when we have solutions that work now, and work well.”
结果现在 Node 社区不但没有 &#34;defragment&#34; 反而 fork 出来了 io.js 。。。
希望大神在 Go 社区能继续贡献优质代码和库~
记住登录状态
还不是会员