11-28 更新：&br&&br&最近把项目放到了vps上，虽然之后就没更新过。。但是还是无耻得放一下吧，哈哈。&br&&br&&a href=&///?target=http%3A//goh5.luoye.pw& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&goh5.luoye.pw&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&=========更新分割线========&br&&br&新鲜出炉，先放地址：&a href=&///?target=https%3A///luoye-fe/goh5& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - luoye-fe/goh5: visual h5 edit&i class=&icon-external&&&/i&&/a&&br&个人开源H5 CMS，类似易企秀、初页，虽然没人家那么牛。。\(￣▽￣)/&br&&br&数据库：MongoDB&br&后台：NodeJS&br&前台：Vue、Vue-Router、Vuex ..&br&&br&数据库MongoDB，后台全部restful_api，路由由前端控制，Vuex管理应用数据，Gulp+Webpack构建。&br&后台部分自己也是刚起步，代码可能有点粗糙，谅解。&br&NodeJS作后台已经是很多新项目的选择了，简单快捷，并且社区很活跃，大多刚起步时遇到的开发难题，前辈们都踩过，擅用搜索可以很快的用起来。不过大型网站的话。。。还有很远的路啊&br&前台Vue部分，应该还好，而且Vue的文档和API都很友好，学起来主要是思想的转变。&br&项目起步的时候双向绑定用的真心爽，后来越写越复杂，数据哪都能改，一不小心就埋坑，中途上了Vuex，世界清净了。&br&列表页，编辑页，设置页，全部组件化，每个组件对数据的修改必须走Vuex，cms做完的作品落地展示用的Swiper，ejs渲染到页面，没有用前端渲染，也省了很多事。&br&当然，刚完成最基本最基本的功能，比如元素的拖拽，属性编辑，动画等，其它的比如，元素事件，表单，视频，音乐，还有一些操作上体验的优化，键盘控制，也会一步步补。&br&放几张截图。（自己拼的UI...丑勿怪！）&br&&img src=&/4c97afccbfa3d_b.png& data-rawwidth=&1917& data-rawheight=&1099& class=&origin_image zh-lightbox-thumb& width=&1917& data-original=&/4c97afccbfa3d_r.png&&&img src=&/cf7ef259b435_b.png& data-rawwidth=&1919& data-rawheight=&1095& class=&origin_image zh-lightbox-thumb& width=&1919& data-original=&/cf7ef259b435_r.png&&&p&&a href=&///?target=http%3A//%3A3030/show/56eff8ee02926a8afab9c72e& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&:3030/sho&/span&&span class=&invisible&&w/56eff8ee02926a8afab9c72e&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a& (二维码自动识别)&/p&有兴趣的小伙伴可以一起来。。。还想RN移植到pad上耍呢。。哈哈，想的有点远
11-28 更新： 最近把项目放到了vps上，虽然之后就没更新过。。但是还是无耻得放一下吧，哈哈。
=========更新分割线======== 新鲜出炉，先放地址： 个人开源H5 CMS，类似易企秀、初页，虽然没…
以下三条是Chrome开源社区原则，目前看来只有360极速浏览器做到了：&br&&b&一、积极参与Chromium社区工作，回馈社区。&/b&&br&360极速浏览器官方说法如下：&br&360极速浏览器负责人任寰介绍，360极速浏览器团队一直以来积极参与Chromium社区工作，帮助检测和优化内核代码，并在第一时间向社区反馈优化结果。如解决了内核代码的bug，并第一时间向社区提交补丁。目前已有多个内核补丁被社区采纳，这也是对开源社区最好的回报。&br&&br&&b&二、与Chromium同步更新。&/b&&br&如题。在国内基于Chromium的比较常见的浏览器中，360极速浏览器的内核更新的速度是最快的。&br&&br&&b&三、务必保留Chromium沙箱防护。 &/b&&br&同上。在国内基于Chromium的比较常见的浏览器中，只有360极速浏览器保留了Chromium的沙箱防护。&br&&br&&b&另外，就是一些其他的贡献了，如翻译了一些文档、网页：&/b&&br&Chrome的扩展开发文档：&a href=&///?target=http%3A//open./html/dev_doc.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&open./html&/span&&span class=&invisible&&/dev_doc.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&Google的V8速度测试：&a href=&///?target=http%3A///test/v8/run.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/test/v8/r&/span&&span class=&invisible&&un.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&HTML5TEST：&a href=&///?target=http%3A///test/html5/index.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&/test/html&/span&&span class=&invisible&&5/index.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&br&&b&其实，360作为国内最大的浏览器厂商，愿意力推基于Chromium的浏览器就是对Chromium开源社区的最大贡献了。&/b&&br&&b&从360极速浏览器作为唯一一家受Google邀请参加谷歌开发者日大会的厂商来看，也能看出Google对此持支持的态度。&/b&&br&&br&&b&相关参考文章：&/b&&br&&a href=&///?target=http%3A//.cn/h//c8947510.html& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&.cn/h/2011&/span&&span class=&invisible&&/-.html&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&&a href=&///?target=http%3A//tv.cn/135.shtml& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&tv.cn/&/span&&span class=&invisible&&16135.shtml&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
以下三条是Chrome开源社区原则，目前看来只有360极速浏览器做到了： 一、积极参与Chromium社区工作，回馈社区。 360极速浏览器官方说法如下： 360极速浏览器负责人任寰介绍，360极速浏览器团队一直以来积极参与Chromium社区工作，帮助检测和优化内核代码，…
明显没抓住问题的本质。要么就是想混淆视听。36X干的坏事多了去了，误导用户、恶意攻击竞争对手什么的你都不提，偏偏找了最无关紧要的说出来跟chrome做对比。说好听点你不了解36X，无意间为其了洗地，说难听点你是数字的水军吗？
明显没抓住问题的本质。要么就是想混淆视听。36X干的坏事多了去了，误导用户、恶意攻击竞争对手什么的你都不提，偏偏找了最无关紧要的说出来跟chrome做对比。说好听点你不了解36X，无意间为其了洗地，说难听点你是数字的水军吗？
先声明一个基本假设：人的思维是线性的。程序员也是人，思维当然也是线性的。线性这里指的是事件发生顺序的前因后果关系。如果你不认同这个假设，下面讨论的几种风格的区别意义不是很大。&br&&br&基于回调的异步 I/O 风格（如 Node.js 和 Python Twisted）会导致控制流倒置（inverse of control flow），使得事件发生的先后顺序不清晰明了，从而造成代码的理解和调试困难。在 Node.js 出现之前，广泛使用的 Python Twisted 库大量使用了这样的风格。一般认为这样的代码可维护性很低。基于回调的异步 I/O 的优势在于其开销小、效率高。单线程的架构也避免的多线程修改可变状态的锁的问题（当然单线程也是个限制，能够有效利用多核的方式局限于多进程）。&br&&br&基于线程的同步 I/O 风格则没有这个问题：每个线程相对独立，且线程内部的控制流是线性的。理解和维护基于线程式的代码相对容易（先不谈锁的问题，不是这里讨论的重点，这里只考虑用于 I/O 的场景）。基于线程的同步 I/O 的问题是它的可扩展性很低，因为每个线程的内存开销大，在线程间切换的开销也大。对于需要处理成千上万连接的网页服务器而言，这样的开销无法接受。&br&&br&很多人于是尝试保留回调和线程风格的好处（低开销、线性控制流），但同时避免他们的缺点（高开销、倒置控制流）。协程（Coroutine）[1] 可以比较好的解决这个问题。协程允许将某个子程（Subroutine）的运行状态保留下来以便将来重入（re-entry）。也就是说，协程可以随时暂停运行，将控制返回给调用者，等条件成熟时再从暂停点继续运行。基于协程的异步 I/O 和基于回调的异步 I/O 在性能上相当，但因为协程的内部逻辑顺序是线性的，不会导致控制流倒置。主流语言中，Python 的 Generator 和 Ruby 的 Fiber 都是协程的例子。在异步 I/O 的语境下，可以将协程理解为回调模式的语法糖（当然协程还有其他的好处）。基于协程的异步 I/O 风格主要难点在于要自己写调度器（scheduler）在多个协程间切换，而且每个协程要记得频繁让出控制避免其他协程僵死。这和回调风格一样。协程现在还不那么流行，被广泛理解和接受可能还需要一些时间。&br&&br&单一进程下，单纯基于回调或者协程都无法有效利用多核处理器。条件允许的情况下，一般采用运行多进程进行负载分流。基于线程的方式理论上可以利用多核，但在 Python 和 Ruby 这样有全局解释器锁（Global Interpreter Lock）的官方实现里，通常只能同时运行一个线程，多线程的优势也就局限在线性控制流，负载分流还是得通过运行多进程实现。Python 和 Ruby 的 JVM 实现由于没有全局解释器锁，不存在这个问题，多个线程可以同时运行。&br&&br&线程当然不是一无是处。问题描述中引用的文献认为线程不好，是在特定的情景下（系统瓶颈主要是 I/O），且当时（2005年以前）多核处理器并非主流、内存相对有限。自从 Linux 2.6 内核开始搭载 NPTL [2] 后，线程的开销（内存、切换）其实已经降低很多了。此外，现在的服务器多核已然是普遍现象，10GB 以上内存也很常见，上万个线程的开销已经不是问题。线程模式可以不用对程序进行特别修改就能利用越来越多的处理器核心（另外一种形式的性能『免费午餐』）。为了优化使用事件驱动的模式而必须进行的状态切换等协调操作进化到最后会成为另外一种形式的线程调度器，某些场合下还不如直接用系统的更加成熟的线程调度器。&br&&br&像 Erlang [3] 这样采用定制化调度器+轻量级线程的模式也很有意思：Erlang 的线程并非系统线程，而是 Erlang 自己管理的、类似协程的机制。和 Python、Ruby 的协程不同，Erlang 的轻量级线程切换不需要手工管理让出控制。Erlang 的调度器会在某个线程执行一定步骤（Erlang 的语境下称为『缩减』，reduction）后自动切换。这一点更加类似系统线程：内部逻辑是连续的，可以使用同步 I/O，同时又没有系统线程高开销的弊病，可谓一石三鸟。唯一问题是，这个太小众了……&br&&br&另外值得一题的还有通过多个进程/事件循环提高事件驱动 I/O 性能。比如 Nginx 的工人进程（worker process）。每个工人是单独的事件循环，和其他工人独立。每个工人使用轮询机制（如 poll/epoll）时只需要处理自己手上的套接字，效率相对要高些。多核处理器上，通常为每个核心分配一个工人，这样互相之间不会为抢系统资源打架。&br&&br&[1]: &a href=&///?target=http%3A//en.wikipedia.org/wiki/Coroutine& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&en.wikipedia.org/wiki/C&/span&&span class=&invisible&&oroutine&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&[2]: &a href=&///?target=http%3A//en.wikipedia.org/wiki/Native_POSIX_Thread_Library& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&en.wikipedia.org/wiki/N&/span&&span class=&invisible&&ative_POSIX_Thread_Library&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&&br&[3]: &a href=&///?target=http%3A//en.wikipedia.org/wiki/Erlang_%28programming_language%29& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&en.wikipedia.org/wiki/E&/span&&span class=&invisible&&rlang_(programming_language)&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&
先声明一个基本假设：人的思维是线性的。程序员也是人，思维当然也是线性的。线性这里指的是事件发生顺序的前因后果关系。如果你不认同这个假设，下面讨论的几种风格的区别意义不是很大。 基于回调的异步 I/O 风格（如 Node.js 和 Python Twisted）会导致控…
&p&----------------------------------------------------补充分割线-------------------------------------------------&/p&&ul&&li&&a href=&///?target=http%3A//taobaofed.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Taobao FED | 淘宝前端团队&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=https%3A//gold.xitu.io/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&掘金&i class=&icon-external&&&/i&&/a&&/li&&/ul&&p&----------------------------------------------------补充分割线-------------------------------------------------&/p&&ul&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&echojs，英文&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A//div.io/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&div.io&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&w3cplus&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&伯乐在线：WEB前端 - 伯乐在线&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A//www./& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&前端乱炖&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&stackoverflow&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=https%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&SegmentFault&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A//www.csdn.net/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&CSDN&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&腾讯AlloyTeam Blog，腾讯全端 AlloyTeam 团队 Blog&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&百度：首页 - FEX&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A///about& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&360团队，奇舞团博客&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=https%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&奇舞团：奇舞团博客&i class=&icon-external&&&/i&&/a&&/li&&li&&a href=&///?target=http%3A///blog/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&大搜车：大搜车前端团队博客&i class=&icon-external&&&/i&&/a&&/li&&/ul&&br&&br&&p&答得另一个问题 直接贴过来的 &a href=&/question//answer/& class=&internal&&求国内最火热的前端论坛或技术交流社区？ - Shelley Lee 的回答 - 知乎&/a&&/p&
----------------------------------------------------补充分割线-----------------------------------------------------------------------------------------------------补充分割线------------------------------------…
@梁海 说的很好，但是对于&u&在意字体效果，暂时只能用 Windows，而且又愿意折腾&/u&的同学可能还是不够。&br&&br&首先，从 Chrome 21 开始，会根据 HTML 的 lang 属性值来应用不同的默认字体（也就是那四个字体）（&a href=&/question/& class=&internal&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/question/2042&/span&&span class=&invisible&&0500&/span&&span class=&ellipsis&&&/span&&/a&）。而你在设置界面设置的那四个字体，应该是英文的。如果 HTML 元素的 lang 属性是「zh-CN」之类的网站（如知乎），那四个字体设置是不工作的。有几种解决方法：&ul&&li&安装这个拓展：&a href=&///?target=https%3A///webstore/detail/caclkomlalccbpcdllchkeecicepbmbm& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/webst&/span&&span class=&invisible&&ore/detail/caclkomlalccbpcdllchkeecicepbmbm&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&。它可以设置所有语言对应的「四个字体」。&/li&&li&安装这个拓展：&a href=&///?target=https%3A///webstore/detail/lndmkajeoopejggihiomoaepinlhblmm& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/webst&/span&&span class=&invisible&&ore/detail/lndmkajeoopejggihiomoaepinlhblmm&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&。直接禁用中文情况下浏览器自作聪明，永远使用设置界面的那四个字体。&/li&&li&自己注入一个脚本，把所有的 lang 属性都改成 en 或空。&/li&&/ul&&br&第二步，就是用什么字体的问题。&ul&&li&如果不用 MacType，那就只有宋体和微软雅黑两个中文字体。因为中易宋体是系统级的默认字体，因此不用体现在设置里。如果你不偏爱微软雅黑，那么「Arial、Georgia、Arial、Consolas」或「Verdana、Georgia、Verdana、Consolas」就很好。如果偏爱微软雅黑，可以设置（甚至可以安装相应的拓展强制微软雅黑（或其他任何字体），选择这个方案甚至可以可以略去前面所有步骤）；但是这样做的坏处的是西文部分也会用微软雅黑来显示，效果不是很好。&br&&/li&&li&如果安了MacType，中文字体的选择范围就大了很多，这个时候实在没必要使用中易宋体或微软雅黑了。由于大多数网页都会自己指定西文字体，因此设置里面四个字体的西文部分用得上的机会不多，因此设置喜欢的中文字体即可。如「微软雅黑、华文宋体、微软雅黑、Consolas」这个设置，用的都是系统自带字体（华文宋体是 Office 自带），第四项等宽字体由于一般都是显示代码，很少牵扯中文所以选择 Windows 下效果最好的等宽字体 Consolas。&/li&&li&但是，大多数中文字体的西文部分都不理想，如果不小心用到了它们的西文部分怎么办。我的方法是去极限论坛上找一些「合成字体」。比较推荐的是 XHei 系列，基本把几种常见的高质量中西文黑体都包括了，自己选一种喜欢的吧。&/li&&li&当然，你还可以通过某种方法把宋体系统级地替换成另一个字体，这样四个字体仍然设置为西文字体。这是下策，这样做的人我相信你都知道自己在做什么。&/li&&/ul&&br&补充&ul&&li&上面的两个拓展并不能所有网站下都正常工作，比如知乎为了解决 Chrome 下标点显示不全的问题（&a href=&/question/& class=&internal&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/question/2006&/span&&span class=&invisible&&6573&/span&&span class=&ellipsis&&&/span&&/a&），使用了 @font-face 给中文标点专门指定了一个字体（&a href=&/question/& class=&internal&&&span class=&invisible&&http://www.&/span&&span class=&visible&&/question/2052&/span&&span class=&invisible&&5863&/span&&span class=&ellipsis&&&/span&&/a&），导致情况很复杂。对于这种网站，最好的办法是用 Stylish、Stylebot 等拓展自定义 CSS。&/li&&li&部分脑残网站会把宋体写在 font-family 里，对于这样的网站可以亦可以自定义 CSS；也可以下载一个拓展把 CSS 中所有的「宋体」替换成你喜欢的字体或大便。但是，Chrome Web Store 里面没有能精确实现这个功能的拓展，倒是有个系列拓展（&a href=&///?target=https%3A///webstore/detail/enpkigfhoabjjjonanmddidnnahopmcn& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/webst&/span&&span class=&invisible&&ore/detail/enpkigfhoabjjjonanmddidnnahopmcn&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&）分别把宋体替换成微软雅黑/正黑/正黑粗体，可以考虑。当然也可以自己改代码替换成任意字体（我不想干第二次了，太折腾了）。&/li&&li&合成字体并不是完美的。很多合成字体的弯引号/撇号是按中文习惯一字宽的，会显得比较别扭，需要注意。&/li&&/ul&&ul&&li&写这个答案时候看到了这个拓展「Mac OSX Font Rendering」（&a href=&///?target=https%3A///webstore/detail/gbokdhnlldmknaijpgikegjffnlpaamk& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&https://&/span&&span class=&visible&&/webst&/span&&span class=&invisible&&ore/detail/gbokdhnlldmknaijpgikegjffnlpaamk&/span&&span class=&ellipsis&&&/span&&i class=&icon-external&&&/i&&/a&），没试，不知道是什么效果，感兴趣的可以试试。&/li&&/ul&
@梁海 说的很好，但是对于在意字体效果，暂时只能用 Windows，而且又愿意折腾的同学可能还是不够。 首先，从 Chrome 21 开始，会根据 HTML 的 lang 属性值来应用不同的默认字体（也就是那四个字体）（）。而你在设置界面设置的那四个字…
这得看你们团队自身实力。&br&&br&如果两边都不熟悉的话，用 Golang，理由如下：&br&0. 编译的时候就能找到的错误放到 Node.js 里大概要浪费 10 倍的 debug 时间！！！&br&&ol&&li&语言能玩的花头少，没有什么坑&/li&&li&标准库自带的网络代码已经相当好&/li&&li&能招到的人不会是从前端过来的&/li&&/ol&这几条能保证你拿到的代码比用 Js 拉团队拿到的好几个数量级。
这得看你们团队自身实力。 如果两边都不熟悉的话，用 Golang，理由如下： 0. 编译的时候就能找到的错误放到 Node.js 里大概要浪费 10 倍的 debug 时间！！！ 语言能玩的花头少，没有什么坑标准库自带的网络代码已经相当好能招到的人不会是从前端过来的这几…
主要看你定义的“爬虫”干什么用。&br&&br&&b&1、如果是定向爬取几个页面，做一些简单的页面解析，&/b&&b&&b&爬取效率不是核心要求，&/b&那么用什么语言差异不大。&/b&&br&
当然要是页面结构复杂，正则表达式写得巨复杂，尤其是用过那些支持xpath的类库/爬虫库后，就会发现此种方式虽然入门门槛低，但扩展性、可维护性等都奇差。因此此种情况下还是推荐采用一些现成的爬虫库，诸如xpath、多线程支持还是必须考虑的因素。&br&&br&&b&2、如果是定向爬取，且主要目标是解析js动态生成的内容&/b&&br&
此时候，页面内容是有js/ajax动态生成的，用普通的请求页面-&解析的方法就不管用了，需要借助一个类似firefox、chrome浏览器的js引擎来对页面的js代码做动态解析。&br&
此种情况下，推荐考虑casperJS+phantomjs或slimerJS+phantomjs ，当然诸如selenium之类的也可以考虑。&br&&br&&b&3、如果爬虫是涉及大规模网站爬取，效率、扩展性、可维护性等是必须考虑的因素时候&/b&&br&
大规模爬虫爬取涉及诸多问题：多线程并发、I/O机制、分布式爬取、消息通讯、判重机制、任务调度等等，此时候语言和所用框架的选取就具有极大意义了。&br&
PHP对多线程、异步支持较差，不建议采用。&br&
NodeJS：对一些垂直网站爬取倒可以，但由于分布式爬取、消息通讯等支持较弱，根据自己情况判断。&br&
Python：强烈建议，对以上问题都有较好支持。尤其是Scrapy框架值得作为第一选择。优点诸多：支持xpath；基于twisted，性能不错；有较好的调试工具；&br&
此种情况下，如果还需要做js动态内容的解析，casperjs就不适合了，只有基于诸如chrome V8引擎之类自己做js引擎。&br&
至于C、C++虽然性能不错，但不推荐，尤其是考虑到成本等诸多因素；对于大部分公司还是建议基于一些开源的框架来做，不要自己发明轮子，做一个简单的爬虫容易，但要做一个完备的爬虫挺难的。&br&&br&
像我搭建的微信公众号内容聚合的网站&a href=&///?target=http%3A//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a&就是基于Scrapy做的，当然还涉及消息队列等。可以参考下图：&br&&br&&img data-rawheight=&480& data-rawwidth=&562& src=&/23b58ecfcd42d2f0bede44f_b.jpg& class=&origin_image zh-lightbox-thumb& width=&562& data-original=&/23b58ecfcd42d2f0bede44f_r.jpg&&&br&具体内容可以参考 &a href=&///?target=http%3A///post/1210& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&一个任务调度分发服务的架构&i class=&icon-external&&&/i&&/a&
主要看你定义的“爬虫”干什么用。 1、如果是定向爬取几个页面，做一些简单的页面解析，爬取效率不是核心要求，那么用什么语言差异不大。 当然要是页面结构复杂，正则表达式写得巨复杂，尤其是用过那些支持xpath的类库/爬虫库后，就会发现此种方式虽然入门…
首先反对推荐读 jQuery 源码的，里面奇技淫巧太多，代码工程角度上来看不太适合实际产品的前端项目。有些代码在工程里面实际上是非常糟糕的写法，容易被带偏。&br&&br&推荐 backbone.js 的源码，非常适合新手。&br&&br&首先是代码结构清楚，几大模块，View/Model/Collection 像一本书一样简单清楚的介绍了现代前端 MVC 架构的组织方式，Events 的代码对于理解 Pub/Sub 模式也很有帮助。其次是奇技淫巧少，代码规矩。还有一个优点是 Annotated Source，有一份详细注释的代码文档，阅读起来非常舒服。当然最大大大的优点是代码量少啊，足够简单。&br&&br&可以先上手一下简单的 Demo，比如 Backbone 的 TODO。然后看 Annotated Source，看下 TODO 里面所涉及的一些方法的原理。或者单独研究几个模块的实现，可以从 Events。或者研究一些核心方法，比如 Model.prototype.set。&br&&br&# 1月22日补充&br&下面提到的 underscore.js 也是很不错的项目，可以先看下文档，然后尝试自己实现里面提到的 API，然后对比下 underscore 的实现，对于了解 JS 语言特性很有帮助。&br&&br&如果对 node.js 感兴趣，可以看 express 和 connect 的代码，可以了解到 HTTP 服务端的工作方式，服务端 MVC 模型，路由分发等等很有价值的工程知识。
首先反对推荐读 jQuery 源码的，里面奇技淫巧太多，代码工程角度上来看不太适合实际产品的前端项目。有些代码在工程里面实际上是非常糟糕的写法，容易被带偏。 推荐 backbone.js 的源码，非常适合新手。 首先是代码结构清楚，几大模块，View/Model/Collecti…
怎么还没人说Java？&br&那我来说说Java。&br&&br&写过挺多语言的，Java、C、Js、Node、Python、Scala 可是写的最多的还是Java。&br&&br&&b&1.静态类型&/b&&br&Java的类型是静态类型的，因此如果定义一个变量不能像js、py等这样定义动态类型：&br&&div class=&highlight&&&pre&&code class=&language-text&&int a = 10;
String b = &hello world&;
&/code&&/pre&&/div&&br&而换成Js&br&&div class=&highlight&&&pre&&code class=&language-text&&var a = 10;
var b = &hello world&;
&/code&&/pre&&/div&&br&看似这显得很啰嗦，可是当你工作了你们好几个人一起写了快一年的代码的时候，你会发现Java虽然啰嗦，但是&b&语法简单，严谨，这可以让你们这个big project避免很多不必要的bug。&/b&特别是当突然出现了一个bug排查起来也是方便很多的。&br&以上这种静态类型能让你的IDE在编译期间更好的发现问题并且提示你错误，而不是在运行的时候才抛出异常。&br&&br&&b&2.上手简单&/b&&br&学过C以后来学Java真会觉得很容易上手，做大项目的时候多个人合作，大家写出来的大部分（非核心）代码差距不会过大，这也是为什么那么多企业选Java做为主要的开发语言吧。而其他语言团队中的差距可能会被拉大，python大神可以写的很飘逸，新手写30行到大神手里写可能只要1行，这个时候如果出bug了，教给别人去排查代码问题可真是头疼。&br&&br&&b&3.第三方丰富&/b&&br&Java第三方真是丰富。各种完善的框架，想要做大数据，离线计算上Spark、实时计算上Storm、搞个分布式协调直接上ZK或etcd、分布式队列有kafka …… 至于J2EE方面，有Hibernate、Mybatis、Spring，多线程又有各种现成的多线程框架。&br&&br&而相比node等语言，不是说其他语言不好，但是在搭建这么大一个系统的时候选择真的是比较有限的。自己的小程序还可以随便写点脚本简单实现，但是公司的大项目呢？公司请你来是要你来解决问题而不是创造问题的。如果没有完善的框架，依赖于一个框架然而那个框架出现了bug，那么遭殃的可是整个公司啊。&br&&br&&b&4.资料多&/b&&br&Java这几年的热门程度这里不必多说了，要找学习资料，从视频到书籍到博客一搜一大堆，有点问题，随便一搜Stackoverflow也很容易找到。&br&&br&&b&5.垃圾回收&br&&/b&在大学的时候写过C++，记得那时候总是要自己分配内存，然后free掉。真是一项繁琐的工作，而Java 的GC算法部分做的真是完善。对于一般的工作使用者几乎可以不用去理会垃圾的回收，GC算法会自动回收那些不被使用的对象，释放内存，这个是透明的存在。（当然，你得防止内存泄漏）&br&&br&&br&我喜欢把编程语言比喻成各种武器，例如Java是把沉重的大剑，Python是一把锋利的匕首。我可以用大剑来砍杀一只战斗力只有5的小兵，但是拿着却那么重，移动速度都降低了，而用匕首则可以快速解决简单优雅。但是遇到大boss倘若没有大剑，匕首当然可以只不过显得更累。所以编程语言是不同的工具，没有最好的，只有最合适的，具体情况具体分析。&br&&br&---&br&&br&写Java写了一两年了，发现这是个可靠的语言，写着写着虽然啰唆，但是有IDEA这样神一样的IDE啊！当然Java还有非常多的优点，这里就不展开说了。对于Java还有其他语言特别是其他语言还有非常多不熟悉的地方了，如果上文有不正确的地方，请指正哈。&br&&br& 补充&br&发现很多人对Java到底是不是一门好语言争议挺大的。个人经验所说的也确实不一定是正确的，还是那句话没有最好的语言只有最适合的。每个人的逻辑方式不一样，所喜欢所欣赏的自然不可能完全一致。完全可以去诟病一门语言，但是当你把它如何的贬低之时可能要顾及下你当前的文字有多少的初学者在阅读，他们正在犹豫选择着他们人生的第一门语言。而他们有的仅仅只是刚入学的学生，但是更有的是马上面临工作想要努力学会一门语言先找个工作，毕竟没有经济来源兴趣难以支撑。&br&我这里只想说说自己的经历，也当做给刚要面临找工作人做参考：&br&我今年刚毕业于沿海某211大学，去年的这个时候也是经历了校招，我们学校虽然不算省里最好的但是还算是过得去吧。然而招聘的岗位很多，但多的是Android、IOS、Java、PHP、前端。而被网上炒的很热的python、go、scala在我们的校招提供的岗位几乎等于0。当然区域、学校不同情况可能截然相反，这里权当给个真实案例，不想特别强调什么。
怎么还没人说Java？ 那我来说说Java。 写过挺多语言的，Java、C、Js、Node、Python、Scala 可是写的最多的还是Java。 1.静态类型 Java的类型是静态类型的，因此如果定义一个变量不能像js、py等这样定义动态类型： int a = 10;
String b = "hello world";
这种纯介绍个人经历的文章，哪有什么“专业”不“专业”可言的？我用过，我自然就有资格和大家说我的使用感受。你要是也用过，你当然可以有和我不一样的感受，你可以说你的个人感受，但你不能认为我的个人感受就是错误的。Chromebook 不是我造的，也不是你造的，说几句个人感受还怎么还能和“专业”扯上关系了？我评价鸡蛋好不好吃总不需要先学会下蛋吧？更何况你自己也同样不会下蛋对吧？&br&&br&最早写下这个答案的时候是 2011 年 5 月，现在转眼就快到 2014 年了。在这两年多的时间里，文中提到的很多情况都发生了很大变化：Chrome 早就支持了多窗口，不再只能以最大化模式运行；能够比较流畅地运行的云输入法也早已出现；系统内置中文输入法和某些网页应用之间的兼容性问题也早就得到了解决。CR-48 之后，很多不同的电脑厂商都推出过很多不同型号的 Chromebook，有更轻更薄更便携性能更差的，有更重更贵更高端电池更不耐用的。因此，很显然，这篇文章里提到的很多内容很多都已经失效了。但你总不能因为今天的情况和当时不一样了，就说我当时的个人感受是错误的吧？&br&&br&另外，价格、便携、性能、续航时间，这几个参数之间本来就是互相矛盾的，提升某个参数必然要损失另外几个参数，就看你怎么权衡了。不同的使用场景对于不同的参数要求不一样，总是会有一部分用户会愿意为了某个参数牺牲其它几个参数。宝马各方面性能全面胜过奥拓，也不代表奥拓就完全没有用了。我就只是列举一下奥拓的优点和不足之处，再评论一下我用奥拓的感受，犯得着一个个反复和我强调“宝马各方面都比奥拓好多了”么？我当然知道宝马各方面都比奥拓好，我在之前的原始答案里也从来没否认过这一点对吧？&br&&br&还有，拿 Macbook Air 和 Chromebook 对比，这多少还有那么一点点道理，毕竟两者之间的定位还有一些共通之处。但你要是拿 Macbook Pro 和 Chromebook 对比，那就完全是无理取闹了，定位完全不一样的两个东西，怎么放在一起去比？难道你要责怪奥拓发动机功率远远比不上十八轮么？&br&&br&从 CR-48 开始，我前后一共用过 5 款不同型号的 Chromebook（我指的是大规模的日常使用，而不是简单花个三五分钟时间短暂体验一下），我相信这个数量应该比阅读这篇文章的大部分人都要多，对于 Chromebook 这些年来的发展和变化我是非常清楚的。但问题是现在面对着一群光是听说过 Chromebook 这个名字都没亲手摸过就能光凭想象就断言我“不专业”的人，我实在没有任何动力去更新这个答案补充更多内容给他们看。如果对于 Chromebook 某个具体细节感兴趣的想作更多了解的，可以在评论中提问，我会简要回答。但如果就是单纯想无理取闹刷存在感的，恕不回复。以上。&br&&br&———————————————— 原始答案的分隔线 ————————————————&br&&br& 作为一个 CR-48 的普通测试用户，我说几点看法。&br&&br&Chromebook 是什么，这个问题在知乎的“Chromebook”话题下已经有了非常简明扼要的回答：“Google 的 Chrome OS 对应的硬件，于 2011 年 5 月正式发布，6 月在北美和欧洲上市销售”。&br&&br&从功能上说，Chromebook 其实就是相当于你在电脑上开一个或多个 Chrome 浏览器窗口并都最大化后 (ChromeOS 目前还不支持窗口模式的浏览器，只能最大化)，再开一个 Gtalk 运行在后台之后的效果。虽然 Google 目前正在积极地开发本地客户端技术，以便能在 Chromebook 上运行本地应用程序[1]，但就目前而言，Chromebook 还是只能浏览网页的。&br&&br&从功能上看，Chromebook 似乎太过于简陋了，但作为一个硬件设备，系统本身的功能只是其中一方面，还有很多其它方面的因素在决定它的用户体验。Steve Jobs 可以捧着 iPad 说：“这个 iPad 能浏览网页，全世界都在你的手掌中了，它真是不可思议！”但你要是捧着一台台式机说：“看，它能上网，真是难以置信啊！”那别人一定会认为你精神出问题了。&br&&br&Chromebook 主要的优点有：&br&&br&1. 启动时间。Chromebook 冷启动一次只需要不到 8 秒钟，在实际使用中，除了升级系统之外，我们一般不会需要每次用都冷启动，用完之后直接合上盖子待机，下次用的时候直接掀开盖子唤醒就行。从待机状态下唤醒只需要一秒左右，和你开一次文曲星差不多。因此，当你突然有事或者突然没事想短时间上一小会儿网的时候，你会更愿意打开 Chromebook 而不是你的笔记本电脑。&br&&br&2. 续航时间。CR-48 充一次电可以连续使用 8 个小时，非常适合逛咖啡馆、在机场候机等场合的使用，不用满世界找插座。&br&&br&3. 小巧轻便。12 寸的小尺寸，1.7 公斤的重量，和一本书差不多，出门的时候随手拎上夹胳膊底下就行。&br&&br&4. 触摸板体验不错。轻击触摸板点击，双指轻击右键，双指拖放滚动，轻击一下后移动拖放，这些方便的小功能使得触摸板真正能做到可用，不需要再像普通笔记本那样，非得外接一个鼠标才能用得舒服。&br&&br&5. 标准尺寸的键盘。这点对于闲暇时间上知乎等网站逛片刻尤其有用，相信不会有人很享受在手机屏幕上长篇大论，相比之下在 Chromebook 上敲字就舒服多了。而且由于它快速唤醒和超长续航的优势，闲暇时间的浏览上 Chromebook 会比笔记本有更高的利用率。&br&&br&在使用之前对于 Chromebook 的主要怀疑是，一个只能上网的本能用来干什么？其实如果你愿意统计一下你闲暇时用电脑的时间就会发现，浏览器的利用率是非常高的。因此，如果你不把 Chromebook 看作一台正经的电脑，而是当作一个电脑之外的辅助的一个玩具，考虑上面提到的 5 点因素，它还是有很高的使用价值的。&br&&br&还有一个对于 Chromebook 的主要怀疑是联网，毕竟一个离开了网络就什么都不能做的设备，使用上会有很多限制。在实际使用中我发现，任何一个可以让你比较舒服地坐下来打算上会儿网的地方，都是会提供 WiFi 接入的，因此这个的确不是什么大问题。而且 Chromebook 内置了每个月 100MB 的 3G 流量，应付一些应急情况也是够用的。实在不行还可以把 Android 手机 tether 上去用手机的流量。Chromebook 的 tether 体验非常好，把手机插上去，在手机上启用 USB tether 就可以使用，不需要在 Chromebook 上做任何设置，真正的傻瓜级操作。&br&&br&下面说说 Chromebook 的缺点。&br&&br&1. 中文输入法非常不给力。首先是输入的时候延迟很大，敲完字母之后需要等一会儿汉字才能出来，这也许和 CPU 速度太慢有一定关系。输入法的功能很弱，是直接内置在系统里的本地应用，并不是基于网页的“云”输入法，由于目前还不能安装软件，所以还不太可能靠第三方软件来改善输入体验。输入法的 bugs 也很多，切换页面之后再切换回来常常会打不出汉字，需要用鼠标点击任务栏按钮开关几次输入法才能好。还有一个很致命的问题是输入法和 Google Docs 冲突，在使用 Google Docs 的时候几乎不能正常使用中文。&br&&br&2. Flash 运行效率非常低。测试过几个简单的 Flash 小游戏，速度慢得难以忍受，比在手机上运行 Flash 还要慢。不过值得一提的是，运行 HTML5 小游戏的流畅度远远超过 Flash 小游戏。从这点上看 Steve Jobs 在 iPhone 和 iPad 上禁止 Flash 插件开发也许是有道理的。问题在于，国内主要门户网站上 Flash 满天飞，一打开连拖动页面都卡得要死，会给 Chromebook 的使用带来非常大的麻烦。虽然 Chrome 有 Flash 屏蔽插件，但要求最终用户靠安装插件来解决日常使用的问题，毕竟不是一个好的体验。&br&&br&3. 娱乐性太差。和 iPad 上大量优质游戏相比，你能在 Chromebook 上玩的东西实在是有限，再加上慢到要死的 Flash 运行效率，想用它来玩点简单的 Flash 小游戏打发一下时间都是不行的。一般说来，如果有比较长的一段休闲时间并且供电不是问题的话，我会选择开电脑而不是打开 Chromebook。&br&&br&4. 外观不炫。待在咖啡馆里的时候，端一台 iPad 啥的可以很有时尚气息，如果需要做比较多的录入工作的，端一台 Macbook Air 也会很拉风。相比而言，端一台 Chromebook 就显得很山寨了。&br&&br&总而言之，对于 Chromebook，不要把它定位成笔记本电脑的替代品，那样的话你会很失望，比华硕 EEEPC 还要高的售价，简陋到极致的功能，使得它完全无法和低成本笔记本电脑相比。但是如果你就把它当作一个外出时、休闲时短时间上网的一个玩具的话，它还是很有价值的。&br&&br&[1] &a href=&///?target=http%3A///p/nativeclient/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&nativeclient -
Native code for web apps&i class=&icon-external&&&/i&&/a&
这种纯介绍个人经历的文章，哪有什么“专业”不“专业”可言的？我用过，我自然就有资格和大家说我的使用感受。你要是也用过，你当然可以有和我不一样的感受，你可以说你的个人感受，但你不能认为我的个人感受就是错误的。Chromebook 不是我造的，也不是你…
恰好你所列举的每一个都会，最少的语言也写过超过万行代码，多的就实在太多了……自己的体会的话大致由易至难如下：&br&&br&C：0.8，最简单也最纯粹。&br&&br&单说语言，C真的足够简单纯粹，最容易根据代码彻底地清楚每个语句的执行细节，你写了什么就一定会做，语言细节上的例外很少（当然这里是说语言层面，未谈及库）。&br&&br&不过自带轮子比较少，三方轮子偏基础，想要快速做个什么东西这个是比不过其它的。此外原生不具备OO语法，如果希望实现面向对象无疑需要自行发挥或借助三方库。&br&&br&Python：0.9，可能是与PHP最相似的。&br&&br&各种轮子异常丰富，语言逻辑极端简单，完全遵循一切都是对象以及凡事都是引用的原则。&br&&br&表面的简单隐藏了许多比较不简单的细节，于是坑就出现了。&br&&br&由于标准很详细，社区对于遵循标准的意愿很高，三方包大都能够很好地统一设计，相比PHP更少出现命名、参数混乱的情况。&br&&br&以往的最大学习阻碍在于2与3的巨大差异带来的社区割裂。近年有所好转。&br&&br&&br&Java：2，规范化的标杆&br&&br&Java的语言规范足够严格，使得写东西的时候会有更多的束缚。但是语言抽象其实并不复杂。&br&&br&与Java密不可分的是设计模式，而其中大部分所谓设计模式恰是由Java的严格规范和相对不灵活的特点带来的最优实践。&br&&br&至于JVM调优一类的东西，暂且不放到对语言的考查范围里吧……&br&&br&此外Java的轮子也十分丰富。但是正因为轮子过于丰富，特别对于J2EE，轮子间的组合选择往往特别多，很难说上用哪些才是最优实践。&br&&br&浏览器解释端的JS：3，欢迎踩坑。&br&&br&最原始的JS并不好用，也不好学，很容易出现觉得自己弄懂了没弄错但是就他娘的出问题了的情况。尽管语法超级简单，但是语言层面的坑就多得数不胜数。况且各家浏览器一家一个js解释器，差异较大而通用性大打折扣（这里还不说那些个浏览器API的事）。&br&&br&完整版的JS，ECMAScript：1.5&br&&br&感谢node和babel，JS所遵循的规则ECMA262终于给JS改名回了自己的名字。随着最近几年的规范化，JS，或者按照官方名称ECMAScript无论从语法规范还是社区扩展来看都越来越靠谱合理，踩坑概率大大下降（然而还是有），工程性规范性越来越可靠。其变种如TypeScript等甚至加上了类静态类型分析，大大降低了学习成本和开发成本。&br&&br&不过这一年一圈新标准新特性等节奏有时候实在是太快了……&br&&br&C++之C with STL：1.5&br&这种风格大抵是竞赛党的自然选择结果。总体来说不会难，因为几乎还是在用C风格写代码，配合STL用来解决一些基本的容器和通用算法需求。&br&&br&因为STL的存在，势必要多学一些相关知识。&br&&br&C++11以前标准的OO风格C++：3&br&&br&老派C++其实不太好学，C++11起提供的那些个新特性如果要用之前标准去写其实挺麻烦的。嗯…学习成本方面，除去必要的OO知识，对比Java，需要同时操心顶层逻辑实现和底层内存实现，负荷不小。&br&&br&大量使用C++11、14、17特性和库的现代C++：2&br&&br&利用这些个库，很大程度上C++可以像Java那样做甩手掌柜光写逻辑，而把底层细节交给库来实现。仅以此为目标的话可以很大程度上降低认知负担，减轻学习压力：用它们，可以在不牵扯C++的90%功能与特性的前提下写出一个像模像样的OO程序。&br&&br&光以自己写而言，足够简单了。不过谁也没法保证你所用的库都是这个套路来的，以及你手头的东西没有前辈遗留的老代码。所以最终还是得学那些个东西。&br&&br&以精通为目标的C++：100&br&&br&理论上没人能精通C++，标准委员会的那帮人也不行。&br&&br&君不见C++依靠宏和模板可以把事情折腾到什么程度……
恰好你所列举的每一个都会，最少的语言也写过超过万行代码，多的就实在太多了……自己的体会的话大致由易至难如下： C：0.8，最简单也最纯粹。 单说语言，C真的足够简单纯粹，最容易根据代码彻底地清楚每个语句的执行细节，你写了什么就一定会做，语言细节…
&p&苹果一向来都是将某个指标上的领先, 有意无意地表达为整体上的领先. 这不是第一次, 基本每次发布会涉及性能上的提升, 都是这个套路. 所以不可全信. 理解为比上一代 safari 有所进步, 更合理点.&/p&&p&js 虚拟机发展到今天, 提升几个百分比就比较厉害了. 提升 80%, 这更像是广告词.&/p&
苹果一向来都是将某个指标上的领先, 有意无意地表达为整体上的领先. 这不是第一次, 基本每次发布会涉及性能上的提升, 都是这个套路. 所以不可全信. 理解为比上一代 safari 有所进步, 更合理点.js 虚拟机发展到今天, 提升几个百分比就比较厉害了. 提升 80%, …
&p&就在昨天（2016 年 10 月 11 日），facebook 公开了新的 javascript 包管理工具 yarn, 用来替代目前被广泛使用的 npm (nodejs 自带的包管理工具)&br&&/p&&br&&p&github 项目地址：&/p&&p&&a href=&///?target=https%3A///yarnpkg/yarn& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&GitHub - yarnpkg/yarn:
Fast, reliable, and secure dependency management for JavaScript.&i class=&icon-external&&&/i&&/a&&/p&&br&&p&仅仅一天的时间，github 上的这个项目已经得到了 200+ 的 watch 以及 8000+ 的 star. (还在急速增加中……人们到底是有多讨厌 npm)&/p&&br&&br&&img src=&/v2-35ec8d1690e4acffec22b_b.png& data-rawwidth=&395& data-rawheight=&111& class=&content_image& width=&395&&&br&&br&&b&yarn 有什么优点？&/b&&br&&br&&p&yarn 和 npm 做的是完全一样的事情：作为 nodejs 的包管理工具。既然是一样的事情，那么 yarn 必须有一些优点，才能说服大家去用。&/p&&br&&p&根据官方网站的介绍，yarn 有以下六项特点：&/p&&br&&p&&strong&& 离线模式（重要）&/strong&&/p&&p&如果之前已经安装过一个软件包，再次安装时就不用再从网络下载了。&/p&&br&&p&这一点很重要，npm 饱受诟病的一点就是，每次安装依赖，都需要从网络下载一大堆东西，而且是全部重新下载。工程多的时候比较烦人。这下子可以节约大量时间了。&/p&&br&&p&&strong&& 依赖关系确定性（重要）&/strong&&/p&&p&在每一台机器上针对同一个工程安装依赖时，生成的依赖关系顺序和版本是一致的。&/p&&br&&br&&img src=&/v2-e37ac1e2686bff8f9e1c_b.png& data-rawwidth=&539& data-rawheight=&208& class=&origin_image zh-lightbox-thumb& width=&539& data-original=&/v2-e37ac1e2686bff8f9e1c_r.png&&&br&&br&&p&之前 npm 在这里有一个处理得不好的地方。举例来说，我写的工程依赖 A, B, C 三个库，我在编写 package.json 的时候，给 A, B, C 都指定了版本号。但是 A 库可能又依赖 D, E, F 库，D 库又依赖 G, H 库。这么多关联依赖关系中，很可能某个库在指定依赖时，没有指定版本号。&br&&/p&&br&&p&于是，这就导致了一个问题。如果我在另一台机器上对同样的工程安装依赖，或者把这台机器工程下的 node_modules 目录删除来重新安装依赖。&strong&由于关联依赖中，没有指定版本号的库，发生了版本更新，就会导致再次安装的依赖，其中具体某些软件包的版本是不一致的&/strong&。&/p&&br&&p&在这种情况下，你会发现原来能够正常运行的程序，忽然变得不能工作或一堆 BUG. 我在最近使用 react-native 编写手机应用时，就遭遇过这样的问题。只能采取一些很曲折的方式来解决。&/p&&br&&p&yarn 采用的解决方式是，引入了一个 yarn.lock 文件来应对这个问题。lock 机制在很多包管理中都有用到。例如 ruby 的 rubygems 就会生成 Gemfile.lock.&/p&&br&&p&yarn.lock 会记录你安装的所有大大小小的软件包的具体版本号。只要你不删除 yarn.lock 文件，再次运行 yarn install 时，会根据其中记录的版本号获取所有依赖包。你可以把 yarn.lock 提交到版本库里，这样其他同事签出代码并运行 yarn install 时，可以保证大家安装的依赖都是完全一致的。&/p&&br&&p&这就特别适合大型项目的多人协作开发和部署。&/p&&br&&p&&strong&& 更好的网络性能&/strong&&/p&&p&下载软件包时，会进行更好的排序，避免“请求瀑布”，最大限度提高网络利用率。&/p&&br&&p&&strong&& 多注册来源处理&/strong&&/p&&p&所有的依赖包，不管他被不同的库间接关联引用多少次，安装这个包时，只会从一个注册来源去装，要么是 npm 要么是 bower, 防止出现混乱不一致。&/p&&br&&p&&strong&& 网络弹性处理&/strong&&br&&/p&&p&安装依赖的过程中，不会因为某个单次网络请求的失败导致整个安装挂掉（这里又要黑一下 npm）。当请求失败时会进行自动重试。&/p&&br&&p&&strong&& 扁平模式（重要）&/strong&&/p&&p&当关联依赖中包括对某个软件包的重复引用，在实际安装时将尽量避免重复的创建。&br&&/p&&br&&p&为了说明这个问题，我们假设目前工程依赖 A, B, C 三个库，而他们对某个库 somelib 存在这样的依赖关系：&/p&&br&&div class=&highlight&&&pre&&code class=&language-text&&A - somelib 1.4.x
B - somelib 1.6.x
C - somelib 1.6.x
&/code&&/pre&&/div&&br&&p&如果要安装 ABC 三个库，那么 somelib 会存在版本冲突。npm 会在实际安装时，给三个库分别下载各自依赖的 somelib 版本。假设 npm 先安装了 A, 由于 A 依赖 somelib 1.4.x 版本，那么 1.4.x 会变成主版本。&/p&&p&再安装 B, C 时，由于 B, C 依赖的都不是 1.4.x, 于是安装完之后，关系就变成这个样子了：&/p&&br&&div class=&highlight&&&pre&&code class=&language-text&&node_modules
├── somelib 1.4.x
└── node_modules
└── somelib 1.6.x
└── node_modules
└── somelib 1.6.x
&/code&&/pre&&/div&&br&&p&明明 B, C 都依赖 1.6.x 版本，实际上 npm 却要把这个版本保存两次，这样明显是对磁盘空间的浪费。我们把这种情况就称为“不扁平的”。尽管 npm 也提供了诸如 flat 等指令去支持“扁平化”处理，yarn 明显试图在这方面做得更好。&/p&&br&&p&总之来说，yarn 要做到的就是三点：&strong&快速，安全，可靠&/strong&&/p&&p&&b&LOGO 是猫咪（这也算优点？）&/b&&/p&&br&&br&&img src=&/v2-3ecb82bd90de_b.png& data-rawwidth=&1000& data-rawheight=&600& class=&origin_image zh-lightbox-thumb& width=&1000& data-original=&/v2-3ecb82bd90de_r.png&&&br&&br&&b&实际的使用体会&/b&&br&&br&&p&我把自己手头的几个用到 npm 安装 js 依赖的 rails 工程还有静态 web 工程下的 node_modules 子目录删除，然后用 yarn install 重新安装依赖。&/p&&br&&p&实际体验是速度要比 npm 快上不少，基本上可以令人满意。原来 npm install 需要 8 - 10 分钟的一个工程，改用 yarn install 后，只需 72 秒完成。&/p&&br&&p&&strong&而且更令人欣喜的是&/strong&：如果某个 js 库的某个版本在这个系统里被安装过一次，那么另一个工程再次需要安装这个库时，就完全不用再次下载。会直接从当前系统里获取这个库。大大节约了网络传输量和下载安装时间。&/p&&br&&p&可以做一个简单的测试，对某个工程执行过 yarn install 后，删除 node_modules 目录，再次 yarn install. 会看到完全不用进行网络下载，几秒内就能再次生成 node_modules 目录。&/p&&br&&p&这其中 lock 机制起到了很大的作用。对于经常要同时编写维护很多依赖 nodejs 的工程师而言，这是一个非常好的消息。&/p&&br&&p&建议大家马上开始尝试使用 yarn.&/p&&br&&p&--------------------&/p&&br&&p&&b& 补充：&/b&&/p&&br&&p&如果觉得安装速度慢，安装源和原来 npm 是一样的，可以通用，修改方法如下：&br&&/p&&div class=&highlight&&&pre&&code class=&language-text&&yarn config get registry
&/code&&/pre&&/div&&p&可以改成 taobao 的源：&/p&&div class=&highlight&&&pre&&code class=&language-text&&yarn config set registry 'https://registry.npm.taobao.org'
# -& yarn config v0.15.0
# -& success Set &registry& to &https://registry.npm.taobao.org&.
# -& Done in 0.04s.
&/code&&/pre&&/div&&p&然后 yarn install 的速度就快多了&/p&&br&&p&另外，目前的小瑕疵还是不少，例如我刚刚遇到的问题，某个工程的 package.json 里面是这样写的：&/p&&div class=&highlight&&&pre&&code class=&language-js&&&span class=&s2&&&eslint-plugin-markdown&&/span&&span class=&o&&:&/span& &span class=&s2&&&*&&/span&&span class=&p&&,&/span&
&/code&&/pre&&/div&&p&yarn install 的时候报错：&/p&&div class=&highlight&&&pre&&code class=&language-text&&error Couldn't find any versions for eslint-plugin-markdown that matches *.
&/code&&/pre&&/div&&p&改成&/p&&div class=&highlight&&&pre&&code class=&language-js&&&span class=&s2&&&eslint-plugin-markdown&&/span&&span class=&o&&:&/span& &span class=&s2&&&latest&&/span&&span class=&p&&,&/span&
&/code&&/pre&&/div&&p&之后，安装可以通过。&/p&&br&此外，这样的写法（直接引用本工程路径）目前也是不支持的：&br&&div class=&highlight&&&pre&&code class=&language-js&&&span class=&s2&&&eslint-plugin-material-ui&&/span&&span class=&o&&:&/span& &span class=&s2&&&./packages/eslint-plugin-material-ui&&/span&&span class=&p&&,&/span&
&/code&&/pre&&/div&&br&&p&类似的小问题估计在近期会被各种人发现（提 issue 呗），最后如何取舍，是否都能修复，看团队的反应。目前还是可以看好。&/p&
就在昨天（2016 年 10 月 11 日），facebook 公开了新的 javascript 包管理工具 yarn, 用来替代目前被广泛使用的 npm (nodejs 自带的包管理工具) github 项目地址：…
每次我说 node 不适合做后端工程的时候总有人跳出来说你看 linkedin 如何如何，现在啪啪啪感觉又如何？&br&&br&放弃 scala 我觉得并非和 scala 难有关，不就一个工具么，高阶程序员还在乎语言层面难不难的？我认为更多的是因为技术积累的问题。scala 调用 java 容易，反过来就是草泥马了啊。既然用了 jvm 了，何不就直接上一套 java 的完事？无论是招人还是基础设施成本都是可预见的下降。所以我总觉得啊，不是 scala 或者 clojure 不好，现在招人成本这么高，还特么是小众语言，往上走人力成本是不能承受的之痛。&br&&br&至于 node，黑箱和以桌面为目标的V8衍生出来这2个点就足矣在工程选型的时候直接放弃。做工程，尤其是做大工程的，基本不会选用这么不严谨的技术。本来前后端要解决的问题就不一样，省了这么一丢丢的所谓 fullstack 成本，后期运维成本分分钟焦作人。
每次我说 node 不适合做后端工程的时候总有人跳出来说你看 linkedin 如何如何，现在啪啪啪感觉又如何？ 放弃 scala 我觉得并非和 scala 难有关，不就一个工具么，高阶程序员还在乎语言层面难不难的？我认为更多的是因为技术积累的问题。scala 调用 java 容…
&b&Disclaimer: 以下对比可能有强烈的个人色彩&/b&&br&&br&Node.js & Python 的地方&br&&ol&&li&快：这个快有两方面，第一是V8引擎快，在V8引擎背后操刀的是&b&Lars Bak&/b&大神，他创造过高性能SmallTalk引擎和Java Hotspot引擎(现在Java的默认VM)，他带领下的V8引擎让Javascript速度达到了一个新的阶段。第二是异步执行，Node.js功能上是一个基于V8引擎的异步网络和IO Library，和Python的Twisted很像，不同的是Node.js的event loop是很底层的深入在语言中的，可以想象成整个文件在执行的时候就在一个很大的event loop里。&/li&&li&npm：npm可以说是用起来最顺手的package management了，npm作为Node.js的官方package management，汇集了整个社区最集中的资源。不像Python经历过easy_install和pip，还有2to3的问题。&/li&&li&Windows支持：Node.js有微软的加持，Windows基本被视为一等公民来支持，libuv已经可以很好的做到统一跨平台的API；而Python虽然也对Windows有官方的支持，但是总感觉是二等公民，时不时出些问题。&/li&&/ol&Python & Node.js 的地方&br&&ol&&li&语言：就单纯从语言的角度来说，Python写起来要比Javascript舒服很多。Javascript设计本身有许多缺陷，毕竟当时设计的时候只是作为在浏览器中做一些简单任务的script，所以代码一旦庞大，维护还是有困难（不过Node.js的module很大的改善了这个问题）。不过用Coffeescript可以很大的改善Javascript，几乎可以和Python等同。&/li&&li&成熟：成熟包括语言本身已经成熟，还有Framework和ecosystem也很庞大。Node.js的绝大多数framework都很新，有的API一直在变，有的感觉已经不在维护，总之没有一个像Django那种百足之虫感觉的framework。Python的主流ORM SQLalchemy也很成熟。&/li&&/ol&Python 和 Node.js 很难分高下的地方&br&&ol&&li&异步Style：Node.js的异步Style是CPS，也就是层层callback，基于event，和浏览器中的Javascript很像。CPS好处是让熟悉浏览器Javascript的人能很快上手，学习难度也不大。缺点是逻辑一复杂，就变得很难维护，基本上需要通过async.js这种library，或者用promise。Python的异步除了和Node.js很像的Twisted之外，也有基于coroutine的gevent，coroutine让异步代码维护起来更容易，不过学习曲线陡。&/li&&li&应用场景：如果是一个CRUD的app，那么想都不想直接是Python，Node.js本身不擅长CRUD的app（绝大多数Node.js都是直接裸在外面的，而不是有一个Nginx在前面，否则websocket就不能用了，不过新版nginx开始支持websocket），代码又不好维护，而Python的WSGI很适合，成熟的stack也有很多。如果更偏向于real-time，比如一个chat room，那么Node.js实现更容易。这两个应用场景还是有差别的。&/li&&/ol&
Disclaimer: 以下对比可能有强烈的个人色彩 Node.js & Python 的地方 快：这个快有两方面，第一是V8引擎快，在V8引擎背后操刀的是Lars Bak大神，他创造过高性能SmallTalk引擎和Java Hotspot引擎(现在Java的默认VM)，他带领下的V8引擎让Javascript速度达到了…
作为一个前阿里PHP工程师，我来回答一下。&br&&ol&&li&阿里是Java的技术文化，绝大部分业务部门后台系统是Java实现的。PHP在天猫也只是做一些前端展现层的工作，俗称套页面。呵呵，毕竟这方面PHP比Java好用太多。这个团队比起Java来说规模非常小，在早期业务复杂多变的时期，这些PHP工程师们立下了汗马功劳。多少脏活累活都干了。&/li&&li&更准确的说PHP做的是后端中的前端，浏览器前端当然还是JavaScript的天下。本来关系紧密的工作还分成2个团队，增加了大量沟通的成本。&/li&&li&套页面嘛本来也不是什么有技术含量的工作，被node.js抢了去也是好事情。这样前端的团队多了一块蛋糕，浏览器前端与HTML展现层（套页面）的工作一个团队负责，少了很多沟通的成本。而退下来PHP工程师直接转去做空间更大的Java后台开发，双赢的局面。&br&&/li&&/ol&天猫的PHP转Node的案例实际上只是在它这个场景下最有利的选型，其他公司如果不是类似的情况就别效仿了，避免带来不必要的麻烦。
作为一个前阿里PHP工程师，我来回答一下。 阿里是Java的技术文化，绝大部分业务部门后台系统是Java实现的。PHP在天猫也只是做一些前端展现层的工作，俗称套页面。呵呵，毕竟这方面PHP比Java好用太多。这个团队比起Java来说规模非常小，在早期业务复杂多变的…
今天心血来潮，回答一波技术问题。总体来说，我看到这个消息是非常兴奋！一颗赛艇！缘由是之前好歹也用过 wordpress 去搭过一段时间自己的blog，对它有感情。同时也试过其他一些blog，比如 jekyll 和 hugo，一直觉得 Wordpress 的技术结构已经很老了，UI也看起来比较像80年代产物，早就应该到了改版的时候。这次 Calypso 就是对于wordpress的dashboard进行一次全面的升级，整个dashboard是用 single page app 来和server的restful API通信。&br&&br&首先看它的codename：Calypso：是古代一个神的名字。国外的公司在做一个项目的时候，经常喜欢用拉丁神话里的名字来命名，比如 Iris，Zeus，Hermes（包包）等：具体可以看这个页面 &a href=&///?target=https%3A//en.wikipedia.org/wiki/Twelve_Olympians& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Twelve Olympians&i class=&icon-external&&&/i&&/a&
Facebook里我知道的项目使用过 宙斯，Iris，普罗米修斯，Titan等名字。&br&&br&具体来说 Calypso 的技术栈。除了这个问题描述里所说的之外， 我们再具体看看它的github上面的详情：&br&&br&&blockquote&&p&Calypso is the new &a href=&///?target=http%3A//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& front-end – a beautiful redesign of the WordPress dashboard using a single-page web application, powered by the &a href=&///?target=http%3A//& class=& external& target=&_blank& rel=&nofollow noreferrer&&&span class=&invisible&&http://&/span&&span class=&visible&&&/span&&span class=&invisible&&&/span&&i class=&icon-external&&&/i&&/a& REST API. Calypso is built for reading, writing, and managing all of your WordPress sites in one place.&br&&/p&&br&&p&It’s built with JavaScript – a very light &a href=&///?target=https%3A//nodejs.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&node&i class=&icon-external&&&/i&&/a& plus &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&express&i class=&icon-external&&&/i&&/a& server, &a href=&///?target=https%3A//facebook.github.io/react/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&React.js&i class=&icon-external&&&/i&&/a&, &a href=&///?target=https%3A//facebook.github.io/flux/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Flux&i class=&icon-external&&&/i&&/a&, &a href=&///?target=http%3A///& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&wpcom.js&i class=&icon-external&&&/i&&/a&, and many other wonderful libraries on the front-end.&/p&&/blockquote&&br&精简起来： server: node + front-end: react.js + flux + wordpress自己的js。这里使用的技术栈的确是当今最先进同时稳定的。从客观结果来看，感觉他们也是比较喜欢JS，所以整个技术架构都是基于 javascript 来布局的。整体框架的选择以轻量级为主，比如 express server：&a href=&///?target=http%3A///en/index.html& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Express - Node.js web application framework&i class=&icon-external&&&/i&&/a& ，比如 react.js 也是。如果真的要提出一些建议的话，就是用 redux 去换掉 flux，具体理由见：&a href=&///?target=http%3A//redux.js.org/& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&Read Me | Redux&i class=&icon-external&&&/i&&/a& 上面收集了来自我们Facebook内部对于redux的看法，而且Facebook内部也在积极地使用 redux。Redux和Flux在总体架构上区别不大，具体比较看来自redux作者的答案：&a href=&///?target=http%3A///questions//why-use-redux-over-facebook-flux& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&javascript - Why use Redux over Facebook Flux?&i class=&icon-external&&&/i&&/a&&br&&br&另外UI方面的改进也不错（用过wordpress的admin页面的人都有感wordpress的UI都像上个时代的网页）。新版的UI：&br&&img src=&/a77ca0ed5c2585bdb438f3e820afe1fc_b.png& data-rawwidth=&654& data-rawheight=&493& class=&origin_image zh-lightbox-thumb& width=&654& data-original=&/a77ca0ed5c2585bdb438f3e820afe1fc_r.png&&&br&另外看github上的文件列表：&br&&img src=&/a1e27ae000ca5880d8eaf2_b.png& data-rawwidth=&987& data-rawheight=&1041& class=&origin_image zh-lightbox-thumb& width=&987& data-original=&/a1e27ae000ca5880d8eaf2_r.png&&还可以窥视一点有趣的工具：&br&1. Webpack用来打包和混淆等；（替代了grunt）&br&2. Vagrant 用来配置；&br&3. Dockerfile：说明使用了docker，而且docker肯定是未来的方向所在；现在在docker方向的创业我们觉得是很好的选择；&br&4. npm：依赖管理&br&5. 各种linter。&br&6. 在 &a href=&///?target=https%3A///Automattic/wp-calypso/tree/master/server& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&wp-calypso/server at master · Automattic/wp-calypso · GitHub&i class=&icon-external&&&/i&&/a&
还有对于server side rendering 的列表，另外可以看到使用node和jade。&br&&br&我最喜欢这次Calypso的几处改动：&br&1. Single page app + restful API&br&Single page app（单页app）在2010年开始流行（Backbone.js时代），主要好处就是反应快，所有的UI变化都在本地浏览器上完成，不需要重新去server请求一个页面，也不会有明显的页面跳转延时。和server的通信基于网页API（一般是 restful API），而传输的内容只是数据而已，没有了冗长的 html、css和javascript 的传输，所以速度要比原来快不少，即使 on-wire data format 用得是 raw json（如果换成 thrift 里的
TCompact 或者 google的protobuf，或者 iOS 上比较流行的 messagepack，可以让网络上传输的数据量更小）。另外更大的好处是可以复用这一套 restful API，用来给 iOS 和 Android 端使用，也可以后续开放给 3rd party developers，做成一个开放平台。本质上也就是说：将前端逻辑和渲染做成独立的mvc结构，使其和其他移动端并列，用统一的restful API来提供服务。&br&&br&2. React.js 和 Flux（Redux）的使用&br&喜欢这个并不是我之前是Facebook的人，只是单纯从技术上觉得这个的确是以后前端的方向。因为什么？因为简单和清晰的逻辑。在Facebook的时候，我们工程师被 tech lead 们（再次强调，是 tech lead， team lead， engineering lead，而不是 tech &b&leader&/b&！！！不要再说 chinglish 了！） 反复强调： complexity is the source of all evils. 降低复杂度是关键的关键。而我在国内这一年，发行很多创业公司的技术栈是怎么老怎么来，或者怎么fancy怎么复杂怎么来。可能技术人员在这样情况下会特别有成就感（虚拟的），而且可以出来一些炫耀的东西。这是一个公司的CTO或者tech partner要极力禁止的。在Facebook奉行的是：”Move fast & break things”，中文翻译过来就是“糙快猛”。而react + flux/reduct 正是在这种场景下诞生的。react主要解决view（UI）上的问题，让UI的书写可以像逻辑代码一样有复用和聚合，同时 flux/redux 的单向数据流可以将你前端的程序逻辑梳理地极为简单和清晰，不仅让bug发生的概率变小，而且代码的后续可维护性特别高：也就是说整体的开发速度和工程维护度都提高巨大！&br&&br&最后解答大家的一些疑惑：&br&React技术够成熟吗？ ---- React.js 已经非常成熟，而且在Facebook内部各种项目都在使用。比如Facebook首页的整个search功能的UI都是react来完成的，还有里面很多详情页的展示也是react。新项目 -- 比如之前的一个在线教育的项目，也是全部依赖于 react 写就。所以 react.js 可以放心大胆地去使用。另外和其他一些常用的开源框架（比如 backbone）不太一样的地方是：react后面是有Facebook这样一个干爹的，所以不会没人管。整个facebook现在工程团队和公司现金流都是杠杠的，所以更新速度和bug修复速度都会有保证。React会比起一些业余时间完成的开源项目有保障很多。&br&&br&唯一要提醒的一点的事情是： react native （特别是 android 上）由于最近刚刚完成，可能坑很多；而且Facebook内部对于 react native 几乎没有怎么使用。所以使用 react native 要谨慎。（特别是 Android）
今天心血来潮，回答一波技术问题。总体来说，我看到这个消息是非常兴奋！一颗赛艇！缘由是之前好歹也用过 wordpress 去搭过一段时间自己的blog，对它有感情。同时也试过其他一些blog，比如 jekyll 和 hugo，一直觉得 Wordpress 的技术结构已经很老了，UI也…
&p&首先对于排名第一大谈 nodejs 弱爆了，System Engine 才是吊的人做个冷嘲——真正做 nodejs 的如果不熟悉 v8 引擎和 libuv 其实只能是做作外围吧？而熟悉 v8 和 libuv 的哪一个没有扎实的 System Engine 基础（没个七八年的 C/C++ 项目基础能玩转 v8 和 libuv 的那真是少见了）？然后说出什么搞 nodejs 的人搞不清楚 websocket 消耗多少内存这种话你确定打击面没有太大？难道你身边有一些初级的 nodejs 开发人员给你造成了错觉然后你就优越到没边了？&/p&&br&&p&在这种角度就讨论技术，讨论的根本不是技术，而是自己的偏好，自己的圈子和好恶。调侃下可以，但是真的是一点营养都没有。而那些赞同他的人，我只想问你们真的有研究过 nodejs？&/p&&br&&p&分割线下面是之前的回答。&/p&&p&-----------------------------------------------&/p&&br&&p&说 nodejs 只是靠营销的是否太天真了些？当初 nodejs 出来的时候各种 BUG，我简单的测试其大文件传输都会出现各种问题。而同時期的其他阵营早就甩其几条街了。但是为什么却能一直不断发展壮大？难道仅仅靠所谓的营销和忽悠？&br&&br&如果只孤立的去考虑 nodejs 的异步库到底怎样怎样，实在是太片面了，难道 nodejs 里面就只提供了异步网络 IO？&br&&br&事实上，&b&nodejs 是提供了一套通用的异步基础设施，使得你可以基于此构建各种异步 API。&/b&异步网络 IO 只是其上的一个具体应用。而现在问题里提及的 twisted 实际上在这一点上根本不具有与 nodejs 的可比性！&br&&br&我选择 nodejs 的原因很大程度上是因为它是 JavaScript 的，这样一来在前后端我可以用同一种语言完成整个项目，这是极大的一个优势！另外，尽管 nodejs 不是唯一的也不是最早的基于 JavaScript 的服务端方案。但是它是同時期性能 JavaScript 阵营里最佳的。&br&&br&再加上 nodejs 底层的 libuv 设计很简单，非常容易扩展，而且 npm 又那么好用。因此开发效率急速上升。&br&&br&选择 nodejs 到底为什么，其实到了现在，许多人各自有各自的理由。但许多人都是因为他是&b&基于 JavaScript 的低成本&/b&解决方案。&br&&br&考虑 nodejs，不止是考虑它的一小部分 API，而是它带来的各方面的便捷。请不要太片面。&/p&
首先对于排名第一大谈 nodejs 弱爆了，System Engine 才是吊的人做个冷嘲——真正做 nodejs 的如果不熟悉 v8 引擎和 libuv 其实只能是做作外围吧？而熟悉 v8 和 libuv 的哪一个没有扎实的 System Engine 基础（没个七八年的 C/C++ 项目基础能玩转 v8 和 lib…
我喜欢cnbeta的一个评论：IE是轿车，chrome是跑车，firefox是变形金刚。
我喜欢cnbeta的一个评论：IE是轿车，chrome是跑车，firefox是变形金刚。
已有帐号？
无法登录？
社交帐号登录