OurJS


OurJS-我们的JS, 我们的技术-IT文摘; 专注JS相关领域;
我们热爱编程, 我们热爱技术;我们是高大上, 有品味的码农;

欢迎您订阅我们的技术周刊


我们会向您分享我们精心收集整理的,最新的行业资讯,技术动态,外文翻译,热点文章;
我们使用第三方邮件列表向您推送,我们不保存您的任何个人资料,注重您的隐私,您可以随时退订,

欢迎分享您的观点,经验,技巧,心得

让我们一起找寻程序员的快乐,探索技术, 发现IT人生的乐趣;


本网站使用缓存技术每次加载仅需很小流量, 可在手机中流畅浏览;
如果您发现任何BUG,请即时告知我们: ourjs(at)ourjs.com

告别Node.js


分享到
分类 JS学习   关键字 Node.JS   发布 tyler  1404707496212
注意 转载须保留原文链接,译文链接,作者译者等信息。  

        首先这是一篇翻译自TJ 的Farewell Node.js ,我本人在看完这这篇文章之后确实是受到了一些冲击,但我并不认同作者的某些看法,比如我认为 Node.js 的package register 是其许多优势之一,反而 Go 在这方面却略显匮乏。 由于个人水平所限,在翻译的时候有许多不懂的地方,我也去作者博客、stackoverflow 上问了一些问题,获得了解答。翻译仍有许多不到位的地方,希望能获得指出意见。


        PS.  作为一位Node.js 的入门菜鸟,感谢TJ 的付出,一路走好。


正文:


告别Node.js


离开Node.js领域

        我一直与Node.js在生产中一起战斗了足够久的时间,很不幸的是,既然我已经不再喜欢从事这份工作,至少在此刻,这是我的正式告别。更重要的是,我需要维护者。


        Node在一些方面确实很棒,但对于最近我感兴趣的软件类型,它终究不是适合的工具。我仍然计划用Node做网站,但如果你对维护任何项目感兴趣,只需要留言写下你的Github 用户名 ,  npm 用户名,以及项目名称来让我知道。通常我所要求的只有你不彻底的改变已有的api,如果真要这么做的话,还是重新开一个新项目的好。


        Koa 是一个我会继续去维护的项目。(与Co 还有朋友们一块) 


圣杯的故事

        我一直深爱着C,但每一个从事C开发工作的人都知道它是有价值却又易于出错的。很难在日常工作中证明语言的选择,因为它不完全是最快的工作。简洁也是一直赞美它的原因,但是没有大量的模板你不会走得很远。


        随着越多的参与分布式系统的开发,Node性能高过可用性与健壮性的发展趋势让我越发沮丧。在过去的一个星期中,我已经用Go重写了一个相对大型的分布式系统,它的健壮性、性能更好,并且易于维护,由于同步代码普遍的更加优美并且更易于开发,它有着更好的可测试覆盖范围。


        我并不是说Go就是一个圣杯,它并不完美,但对于现今存在的多种语言来说,Go于我是一个极好的答案。随着越来越多的这些"次世代"语言如 Rust 和 Julia 找到他们自己的位置并成熟起来,我确定我们会有更多的伟大的解决方案。


        个人而言我对Go语言感到很兴奋是因为他的迭代速度,很激动的看到他们渴望去达到2.0版本,并且据我所听到的消息,他们并不害怕与打破原有的伟大事物。如果是真的话我很乐意,更多是因为我相信如果真的是有益于这门语言的,就应该快速的打破已有事物。但我也不是一个运行了大量系统的软件巨人。:D


        编著: 一定是我错误解读了一些提交的邮件列表,他们在任何时候都并不渴望于做出一些破坏性的改变。@enneff


为什么是Go? 

        如果Node对你有效并且你没有什么需要担心的,它仍然是一个很好的工具。但如果有些事情困扰着你,别忘了跳出你的盒子去看看在盒子外面有什么其他的--在最初的使用Go来构建产品的几个小时内,我已经被吸引住了。


        再次声明,我并不是在那里说Go绝对是最好的语言而且你必须去使用它。但对于它所处年纪来说,是非常成熟而健壮的。(大致与Node相同年纪的时候)。类型的重构是有趣而简单的,Go所提供的作业和调试工具是很棒的,同时社区具有非常强大的关于文档、格式、基准以及api设计方面的条例。


        在如此习惯于极度模块化的Node 和体验过 Ruby 腐烂的标准库的同时,当我第一次听到 Go,我认为它的标准库是糟糕的。在我深入这门语言之后,我意识到现阶段极大部分的标准库都是很有必要的,比如compression、json、IO、buffered IO、字符串操作等等。大部分的这些APIS 都被定义的很好并且很强大。很容易仅仅通过使用这些标准库来书写整个程序。


第三方Go packages 

        大部分的Go 库看上去都很相似,我到目前为止所使用过的大部分的第三方代码都是高质量的,而在Node中很难去找到这些因为JavaScript 吸引了不同技巧层次范围内的开发者。


        对于Go 的packages 来说,没有注册中心,所以你通常会同时看到5或6种相同的包。在有些时候,这会造成一定的困惑,但它却有一个有趣的副作用,你必须通过认真的审查每个包来决定哪一个是最佳方案。通过Node 通常有规范的包如 "redis","mongodb-native" 或者"zeromq",所以你会停在那里就推断出他们是最好的一个。


        如果你正在做一些分布式的工作,你会发现Go的令人印象深刻的并发基础数据类型是非常有帮助的。我们可以通过在Node 中的generators 来获得相似的东西,但在我看来,generators 仅仅是做到一半而已。没有独立的错误处理、报告栈即使最好也仍然是平凡的。当这些方案都能良好运行的时,我也不想等待社区三年去重整。

        在我看来,Go的错误处理是出众的。就你必须考虑每一个错误并且决定怎么做而言,Node是伟大的。然而Node 失败在:

  • 你或许会重复的进行回调
  • 你或许根本不会进行回调 迷失在不稳定状态中 (译注 比如忘记传递错误处理回调,错误时,Node 将吞掉这个错误而不会有任何反馈)
  • 你或许会得到外带的错误
  • emitters 或许会获得多个错误的事件
  • 忘记错误的事件的处理会毁掉一切
  • 经常不确定什么需要错误的处理
  • 错误的处理是非常冗余的
  • 回调烂透了


        在Go语言中,当我的代码结束的时候,它就结束了,你不能在语句中重新执行。在Node中这是不确定的。你会认为一个程序完全的执行完毕,直到一个库意外的多次调用一个回调,或者没有正确的清除handlers 然后引起代码的再次执行。实际的生产代码中找到这些原因是相当困难的,为什么要烦恼这些?其他语言不会让你经历这些痛苦。


未来的Node

        我仍然希望Node 做得很好,许多的人对他进行巨额的投资,它确实有这样的潜质。我认为Joyent 和团队需要关注在可用性—如果你的应用很脆弱并且很困难去调试、重构以及开发,性能是无意义的。


        在4-5年内我们仍然将有着这种模糊不清的错误 "Error: getaddrinfo EADDRINFO”,这个事实告诉我们Node 的发展优先级在哪里。可理解的是,当你专注于建立系统核心的时候,会很容易漏掉这些东西。单我认为用户已经对这类事物一次又一次的表达了意见却没看到任何的结果。对于声称说我们拥有的已经是完美的,我们通常获得少数的回应。在实践中,却并非如此。


        streams 是被中断的, 回调不容易使用,错误含糊不清,工具并不好用,社区条例是有,相对于Go而言却显得匮乏。尽管如此,一些特定的任务我仍可能继续去使用Node,比如创建网页,或者一些零散的API或者原型。如果Node可以修复一些它的基本问题,那么它有机会保持相关性,但当存在另一方案是更高的性能和更高的可用性的时候性能高于可用性的论证不会走的太远。


        如果Node社区决定去拥抱generators 并能在Node 非常核心的地方实现他们,去适当的传递错误,是有机会让这个是可参照的。这会彻底的提高Node 的可用性以及健壮性。


        好消息是,不久之前我跟在StrongLoop 里面的贡献核心代码的了不起并充满天赋的家伙聊过。他们正在明确的采用通过倾听开发者对这个平台的回复,并且计划找到修复这些问题去修复的正确方式让未来的Node更加易于工作。我不确定多家公司对核心部分同时开发的冲突会如何结束,但我希望开发者驱动方会胜出。


        这并不意味着这是一个对个人的攻击,很多真的有天赋的人们正在与Node或在Node之上工作,但这再也不是我感兴趣的地方了。我在Node社区中经历了一段伟大时光的同时也遇到了一些真的很有趣的人。


        故事的寓意在于,不要被你自己的圈子所限制住!看看其他地方有什么,你也许会再次享受编程。在这之外还有很多了不起的解决方案,我犯的错在于等了太久才去与他们一起游戏!


原文地址: 点此
社区评论 ( Beta版 )
  • #0 白日梦 1404714238000
    他就是Express之父?
  • #1 f2e 1404723651000
    @白日梦

    是的,还有koa
  • #2 Think2011s 1404798709000
    抱歉,我必须得说,翻译的实在难懂。:)
  • #3 Tyler 1404867217000
    @Think2011s

    不好意思,最近才开始涉及翻译这块。能问下哪些地方你阅读起来有困难吗~?
  • #4 OurJS 1404867946000
    @tyler 感谢分享
  • #5 Think2011s 1404893183000
    @Tyler

    我只能提个大概的意见,感觉直译的方式比较多,读起来不够流畅(就我个人而言),或许翻译跟编码画画一样需要不断积累和调整的过程。
  • #6 Tyler 1404914910000
    @OurJS

    纯粹当做学习 : )
  • #7 Tyler 1404952673000
    @Think2011s

    恩~! 还需要很长久的积累过程~! : )
  • #8 己删除 1405347902433
  • #9 己删除 1405348805238
  • #10 long_frost 1406172072811
    var a="";
    asdf 
    
  • #11 hidden_dust 1406340419338

    fdsfsdfsafasdfasdfsdaf

  • #12 delicate_meadow 1409657565674

    用google翻译的吧,简直让人不忍猝读,还是英文好读懂些。

  • #13 delicate_meadow 1409657704899

    “ 如果Node社区决定去拥抱generators 并能在Node 非常核心的地方实现他们,去适当的传递错误,是有机会让这个是可参照的。” 这句子压根就不通。更别说信达雅了。

  • #14 刘民女 1440067704059

    我觉得翻译得还不错,能看懂。

  • #15 连妈丈 1484320380576

    在这里输入代码

    1. 标题

      #

OnceDoc 您自己的企业内容管理系统——文档、流程、知识库、报表、网盘All In One

访问404页面,寻找丢失儿童
 热门文章 - 分享最多
  1. 皇帝的新衣:Node.js
  2. 如何兼职创业并避免风险
  3. PHP vs Node.js:真正的评测数据
  4. 沃尔玛为什么要采用Node.js
  5. 再见了,Heroku
  6. 失败的感觉:一个22岁女孩的创业故事
  7. Java的痛
  8. Swift的前世今身-创始人的自述
  9. Intel: Javascript将全面支持SIMD
  10. 在JavaScript数组中找到最小元素的位置
  11. AirJD-简单好用的免费建站工具

 相关阅读 - JS学习
  1. 告别Node.js
  2. Node.js手册:require是如何工作的
  3. JavaScript最大堆栈的数量
  4. 7个步骤:让JavaScript变得更好
  5. 在JavaScript数组中找到最小元素的位置
  6. 在JavaScript中创建命名空间的几种写法
  7. JavaScript中NaN的秘密
  8. jQuery:在一个回调中处理多个请求
  9. 使用集群(recluster)扩展多线程Node.JS
  10. 抛弃jQuery,深入原生的JavaScript

 关键字 - Node.JS
  1. Node.JS用Socket实现FTP Server服务器和Client客户端
  2. 皇帝的新衣:Node.js
  3. KoaHub全栈移动商城(微信端+pc端),node.js开发
  4. Express入门教程:一个简单的博客
  5. KoaHub全栈商城系统正式上线!
  6. 在nodejs中使用Redis缓存和查询数据及Session持久化(Express)
  7. nodejs下一代开源商城系统 立即下载
  8. Node.JS编码规范指南教程:教你优雅地写JavaScript代码
  9. 使用NodeJS将XML解析成JSON及性能比较
  10. 沃尔玛为什么要采用Node.js

 欢迎订阅 - 技术周刊

我们热爱编程, 我们热爱技术; 我们是高端, 大气, 上档次, 有品味, 时刻需要和国际接轨的码农; 欢迎您订阅我们的技术周刊; 您只需要在右上角输入您的邮箱即可; 我们注重您的隐私,您可以随时退订.
加入我们吧! 让我们一起找寻码农的快乐,探索技术, 发现IT人生的乐趣;


 关注我们

我们的微信公众号: ourjs-com
打开微信扫一扫即可关注我们:
IT文摘-程序员(码农)技术周刊

ourjs官方微信号