知乎上前端开发领域有哪些值得推荐的问答？
自问自答。自己在知乎上收集了不少前端开发领域的问答，收获不小，但结构比较凌乱，整理了下，头绪也清楚了些。希望对大家也有用处，同时感谢这些问答的作者。===非常感谢 童鞋的重新排版。===更新于日。另外，整理了一下个人的chrome收藏夹，对前端有兴趣的童鞋可以关注，===前端资源：前端大牛：前端书籍：技术细节：　JavaScript 方面　HTML 方面　CSS 方面前端工具：Angular：前端学习：　入门　高级前端就业：前端招聘：前端漫谈：PS，打个小广告，推广一下个人微信公众号：sunln_404 ，扯淡前端、理财、旅游、生活、运动的个人小角落，时常宕机并404……欢迎关注。
可以去看一下，facebook 官方提供的一个开源前端框架！真的很强大，无论是性能还是代码的优雅度，都是没的说！
你见过最美的网页是哪个？ - 知乎
总结了好多啊
这个专栏问答 最后介绍一个新做的技术问答平台极乐问答平台，用了一段时间，蛮不错的
现在H5比较流行吧。可以研究下啊。
谢谢各位的分享，可以学好多了！楼主好人
已有帐号？
无法登录？
社交帐号登录1您所在的位置： &
Node.js真的无所不能？那些不适用的应用领域分析(1)
Node.js真的无所不能？那些不适用的应用领域分析(1)
其实到今天为止，很少有哪些大的互联网公司是和 Node.js 无关的。LinkedIn，Yahho，Paypal, eBay, Walmart 都在将既有的系统向 Node.js 迁移（/Node-js/What-companies-are-using-Node-js-in-production 翻墙看）。国内的淘宝、网易、百度等也都有很多项目运行在 Node.js 之上。
Node.js是一个服务器端JavaScript解释器，底层采用的还是libevent；它的目标是帮助程序员构建高度可伸缩的应用程序，目前对Node.js 的采用状况，Node.js 官方站点有一些罗列，但是相当不完整。如果你自己公司用到，也可以在 github 上提交自己的 pull-request 来更新这个文档。
其实到今天为止，很少有哪些大的互联网公司是和 Node.js 无关的。LinkedIn，Yahho，Paypal, eBay, Walmart 都在将既有的系统向 Node.js 迁移（/Node-js/What-companies-are-using-Node-js-in-production 翻墙看）。国内的淘宝、网易、百度等也都有很多项目运行在 Node.js 之上。
2011 年我开始接触 Node.js 的时候，npmjs.org 上只有不到 3,000 个 Node.js 的 packages，今天()则有 61,897 个，这个数字还在快速增长中。
下面有两个链接，第一个是在讲 Walmart 这几年为什么以及如何迁移到 Node.js 上；第二个则为 eBay 是如何从 Node.js 的怀疑者转变为采用者。
&这篇文章的最后一段，列出了 eBay 为什么选择 Node.js。
每天都有几百个新的 packages 被发布到&&上，小到几行代码，大到万行代码的 Framework。一天有7百万次的包下载（安装到某台电脑上），对于单一开发框架的社区来说，用沸腾的海洋来形容并不过分。
以下应用领域和程序员不适合选择Node.js：
计算密集型应用。Javascript 的计算性能是很难和 C 语言代码相比的。当然，也有反例：http://onlinevillage.blogspot.jp/2011/03/is-javascript-is-faster-than-c.html，只不过不具有典型性。
需要精密控制内存的分配和释放的场景，如果用 Node.js 实现 Redis 数据库，虽然程序会简单不少，但是 JVM 对内存数据结构的精密控制能力是比不了用 C 语言纯手工打造的。
大量且需要频繁通过 C Binding 调用 C library 的情况。这种场景下，往返参数的 Marshal/Unmarshal 的成本可能会大于 C Library 带来的性能提升。
实时性要求很高的场景，例如：交换机或者工控机器人。这是因为所有通过垃圾回收机制来管理内存的系统都有可能在 GC 过程中产生停顿，从而影响响应速度，而且很难优化。
需要单一进程控制大内存的场景：v8 引擎的设计限制，在 32-bit下有 1GB 最大堆尺寸的限制，在 64-bit下是1.7GB。当然，由于 node.js buffer 的分配不是在 v8 的堆上，因此可以超过此限制。这个限制可以通过向 v8 引擎传递max_old_space_size&参数来超越，但是也会带来 GC 的性能退化。这一问题在几乎所有 GC Based 的系统下都存在。
不关心系统吞吐率或者不需要异步调用的场景：例如，自动化脚本，这些脚本不需要关心多用户并发访问的性能消耗。用 Python 这样的&胶水&语言写起来会更简单。
某些非通用场景：例如 nginx 对于静态 web server 或者 反向代理的场景是特别设计的，这些场景中 nginx 的性能比 Node.js 要好。
强类型强迫症：有些 Java 或者 .NET 过来的程序员会认为只有强类型语言和严格定义的类型系统是专业化的象征，构造这样的系统是架构师的使命，而动态语言只是玩具，只能用来做 Demo 或者前端开发。
团队成员难以理解或者接受函数式编程：Javascript 本质上更像函数式语言，有些程序员在理解和使用闭包、高阶函数等概念时总是不能习惯，这个问题在国内的开发团队中还挺普遍的。
回调式编程的不习惯：Node.js 的异步IO 大量依赖回调。回调让程序的执行出现了两条路径，出现故障时调用栈也很难理解。这对习惯了同步编程的程序员来说一开始确实是个坎。async,&Q promise&等 package 可以缓解这个问题（在 ES6 的Generator 普及之前），不过这也带来了更陡峭的学习曲线。一般情况下，需要半年到一年的习惯过程，当然前提是多看，多写。随着越来越多的经验分享，这个过程也在不断地缩短。
除此之外的领域，或者没有上述问题的，都都可以享受到 Node.js 带来的生产力提升和稳定的性能保障。
性能的争议
不同开发环境间的性能对比从来都是有争议的话题。我只能说，当开发 Web 或 网络环境下的应用时，Node.js 靠以下几个方面来避免出现不必要的性能问题：
Chrome V8，一个可靠的优秀的虚拟机(hidden classes 和 inline caching)，让 Javascript 的运行速度进入了第一阵营(C++, Java, .NET)。
异步 IO 大大降低了线程数量，莫名其妙的死锁和等待的概率被降低了很多。大部分场景不用去考虑并发和同步锁，犯错误的机会少。而在 Python 中，异步 IO 并不是标准，并没有被贯穿到所有 Package 中，因此应用程序也就很难获得一致的性能保障。
非常轻巧的&内核&。Node.js 的模块分为 Core Modules 和 Userland 两部分。Core Modules 非常精简，只包括 TCP, HTTP, DNS, File System, child processes 和其他一些模块，这些网络库还只有异步版本。相对地，在 Userland 中却有着海量的 Packages。开发应用的时候，我们根据应用的需求来组合 Userland 的 Packages，使得我们的应用程序有机会在一个很低的资源消耗水平下运行（在中指出，一台开发服务器就可以支持 12 万活跃连接，平均每个连接消耗 2k 内存）。事实上，我开发的 WebSockte 应用在 Raspberry Pi 下都可以支持几百并发长连接（WebSocket）。和那些动辄上万个类的企业开发框架相比，这是一个巨大的优势。这种方式降低了出现问题的概率、查找问题的成本以及减少部署成本。
对 Javascript 的绝对性能的追求一直没有停顿（例如， Mozilla 的&&）。而 Node.js 则在绝对性能的基础上，确保应用程序可以获得稳定和可预测的性能保障（ Benchmark 和实际的应用运行往往是两回事）。
Node.js继承了JavaScript 的灵活性，优秀的JS库应当如何选择
可以在 npmjs.org 或者 google 上搜索关键词。如果类似的返回很多，则看其被其他 package 依赖的数量有多少。上 github 上查看 starred 和 forks 的数量，读 issues。
如果是&名人&（substack, visionmedia (TJ Holowaychuk), dominictarr, rvagg 等）写的 Packages 自然会被加分。
最后是把 Git Repo. Clone 或者 Fork 下来, 阅读且注释他们的源代码。这个过程也可以发现很多他们依赖的其他 Packages。这是一个蛮享受的过程，可以学到很多新知识和新的用法。
还有一些乱枪打鸟的方法：
在 Tweeter 上关注 @nodenpm，所有在 npm 上发布或者更新的 packages 都会在该 handle 上发布出来。在你的碎片时间没事可以刷刷这个，当然你需要 APN 翻墙。
关注一些推荐和评论账号：@dailyjs，@echojs 等。
&会提供不错的开源信息汇总，其中包括 Node.js、Javascript 和 npm 栏目。
&则不会让你忽略软件行业的一些&大事&或者新概念。
一个项目开始前的研究阶段，我大约会浏览几十个 Packages，精读其中的5 ~ 10个。开发过程中则根据需要还会不断地发现和精读一些，这些都被我计入了项目的成本。
&自由选择，自己负责&，在这个庞大的开发社区了不要指望有人能告诉你&标准答案&。每个人面临的问题域和知识背景都不一样，坚持多看，多试，多思考，享受获得新知识的过程比获得&标准答案&更重要。
在众多的成熟开发框架下为什么需要Node.js
在每一个特定的问题域，大家总是在尝试找到最优解。这个过程是没有终结的，就想最终也会有其他框架代替 Node.js 一样。
今天的 Web，是无数相互连接的 Web Services 组成的，这些连接的本质是异步的。Node.js 天生异步的特性和这个场景的匹配度相对其他开发框架要更高，因此实现起来也更自然。
除此之外，Node.js 的设计基本原则遵循了 《》，参见 Isaac Z. Schlueter (前任 Node.js 的Gatekeeper，目前负责 npm 的商业化) 的Blog：&。
npm 和 stream 就是上述哲学的产物。
npm 是 Node.js 的包管理系统。包管理系统不是新东西，但是和 npm 的那些前辈和表兄弟不同的是：
npm 直接集成在 Node.js 中，无需单独安装，发布，安装 packages 非常简单。
npmjs.org 提供一个统一的入口，你可以看到每个 package 被哪些 packages 所依赖，你也可以一目了然地看到它依赖了l，以及最近的下载次数。结合到 github 上的更新情况，基本上对一个 package 的基本情况你都能了解到。
约定俗成的发布规范：一个 git repo. 让你可以直接找到源代码；README.md 提供简要的说明让消费者能尽快用起来。
对于开发者来说，每一个 package 就是一个 &micro service&，是最小重用单元。大部分的 package 只有几百行代码，甚至有些只有几行代码。这样的重用粒度是在其他社区难以想象的。
在 Node.js 的应用的开发过程中，编写 &一口尺寸&（bite-size）的 module 是推荐的编程方式。这也很方便你把这些小 module 封装为 package 分享到社区当中，而不用担心泄露&企业机密&。
npm 是每一个 Noder 的 &home&，也是每一个 Node.js 应用的系统架构的一部分。
内容导航&第 1 页： &第 2 页：
关于&&的更多文章
Node.js是一个使用了Google高性能V8引擎的服务器端JavaScript实
网友评论TOP5
作为移动开发者，WOT2016移动互联网技术峰会，绝对有你不得不来的理由。
讲师： 0人学习过讲师： 35人学习过讲师： 58人学习过
每年的一月份大约都是在看似忙忙碌碌中度过的。最近一
自从MySQL被Oracle收购以后，PostgreSQL逐渐成为开源
1314的的日子在，在忙忙碌碌中过去了。一周五天，中间
针对Ajax技术的日益流行，本书对Ajax技术的典型应用进行了归纳总结，基本上覆盖了Ajax技术应用的典型场景。书中共有45个实例，分
51CTO旗下网站软件开发领域那些经典的技术之争
　作者: 核子可乐编译　编辑:
　　【IT168&技术】无论大家是否认同二元论在人类思维与社会形成当中所扮演的重要角色以及基础性地位，这种“非黑即白”的审视角度已经成为我们日常生活当中组织定义的重要手段之一：共产主义与资本主义、咸党与甜党、足球运动中的转球与带球。环视我们身边，每一种事物似乎都被锁定在一场与其对立面的永恒对抗当中，而这也让我们能够随时随地对自己的的喜好或者选择进行分析以及决断。　　这种思维方式在计算机技术领域的作用则更为明显——二者选其一，众多各有所长的方案在努力争夺我们的感性支持、理性支持以及口袋里的钞票——这些技术成果往往牢牢坚守着自己的差异化设计思路，进而导致用户很难从中找到万全的决策结论。如果一边标榜自身是X，那么另一边则常常会以“非X”自居并将此作为核心卖点。双方阵营的拥护者开始纷纷站队，并向对立阵营的成员们大加嘲讽或者拉拢。如果没有这些争斗、没有由此带来的激烈辩论与两难选择，两套方案可能早就已经合而为一、并成为用户没有选择中的最好选择。然而缺少了这种多样性，创新活动将受到严重束缚、我们的世界也不可能如此丰富多彩。　　在今天的文章中，我们将了解开发人员们最感兴趣的十大二选一难题。每当一个新项目火热出炉，我们都需要面对隐藏在其差异化技术实施机制之下的本质性问题。我们到底更倾向于简便还是正确?更喜爱开源体系还是商业支持?成熟框架还是空白但无拘无束?正如阴阳对立但又彼此依存，相信对这些问题的探讨能够帮助企业开发人员在面临取舍难题时作出更为明智的判断。　　开发技术之争第一位：PHP对Node.js　　作为一款从未受到计算机科学家青睐的语言，PHP受到想为自身网站增添一点智能元素的开发人员的热烈追捧。这些包含激情的技术人员为我们带来了众多令人赞赏的框架，例如WordPress、Drupal以及Joomla等等。时至今日，大多数Web内容都由PHP所构建。　　现在这套已经相当成熟的模式面临着新的挑战者。刚刚入门的新人们更推崇Node.js，这是一套基于JavaScript的服务器端编程机制。几乎在一夜之间，程序员们已经可以编写出有能力运行在客户端或者服务器端的代码，而且根本不需要额外再学习一门新语言。　　Node.js拥有自己的独特风格，但众多出色的现有框架已经能够使其获得可与各类最佳PHP堆栈相比肩的功能特性。下一代开发人员是否会出于编写便捷性考量而选择且只选择JavaScript?又或者，他们会继续坚持使用更易于嵌入至HTML当中的编码方式?很明显，原本喜爱JavaScript的开发人员会毫不犹豫地投身于Node怀抱，而希望使用WordPress或者Drupal等源自PHP的稳定堆栈的从业者则将与这场Node.js普及风暴谨慎地保持距离。　　开发技术之争第二位: MySQL对PostgreSQL　　在过去近二十年当中，这两款堪称伟大的开源数据库方案一直在争斗不休、而且时至今日我们也看不到双方握手言和的可能性。在一方面，MySQL在Web基础工作负载领域拥有无可匹敌的巨大份额占比，这要归功于其简便易行的安装与配置机制。而在另一方面，PostgreSQL长久以来则始终承诺提供更理想的事务处理机制、从而保护数据免受潜在漏洞的威胁。这两位重量级选手都在向对方学习优势与长处，现在MySQL已经拥有更出色的事务处理功能、而PostgreSQL也对自身的初次启动流程进行了大刀阔斧的精简。　　不过历史的惯性仍然推动着二者在当下保持着对立关系。PostgreSQL通常被视为更具“稳定性”的解决方案，而MySQL的长处则在于“快捷性”。不过平心而论，这两种差异如今更多地反映在固有印象而非实际表现层面。所谓积重难返，这两套软件包可能还将在未来二十年中继续这种激烈的对抗，而杰出的技术大牛与甲骨文反对者们的鼎力支持似乎让PostgreSQL拥有更为顺遂的发展前景。
第1页：第2页：
大学生分期购物销量榜
IT168企业级Node.js真的无所不能？那些不适用的应用领域分析-Golang语言社区-微转化
欢迎来到 Go语言社区 社区网址: APP网址: 社区非公司性质,完全个人爱好建立;做的不好的地方大家见谅
这六种女人再干净都不要睡，谁睡谁倒霉！
[广告][广告]●●●●●●●●●●●
热门公众号Accounts
精彩内容热门推荐
十分感谢和欢迎您关注我们
啪啪啪! 两性话题,两性知识,荤段子、教育视频,么么哒,想了解秘密进来嘛!小编提醒观众自带纸巾,欢淫进入!
gaoyibenditong
?高邑?本地通,给你一个精彩的?高邑?资讯平台
好玩、有趣、靠谱,定期发布?航天?资讯,为?航天?青年搭建沟通交流平台,欢迎行业内外优秀青年关注转发.
传递有价值的信息!
yinyue5105
一键制作精美的?音乐?照片影集
wei-rongxian
微容县时代,为容县商家提供微平台服务~
郑重承诺:只发精品,拒绝糟粕低俗色情!
有人成功了,有人失败了,有的还在路上,有的还在沉寖幻想中!无论怎样,你都必须努力. 分享人生智慧,传播正能量!让我们一起走下去....
mh_toutiao
?恐怖??漫画?、故事推荐,长篇解读,短篇呈现,带你进入一个荒诞离奇刺激的世界.
Node.js真的无所不能？那些不适用的应用领域分析
阅读&5449&发表& 21:44:00
Node.js是一个服务器端JavaScript解释器，底层采用的还是libevent；它的目标是帮助程序员构建高度可伸缩的应用程序，目前对Node.js 的采用状况，Node.js 官方站点有一些罗列，但是相当不完整。如果你自己公司用到，也可以在 github 上提交自己的 pull-request 来更新这个文档。其实到今天为止，很少有哪些大的互联网公司是和 Node.js 无关的。LinkedIn，Yahho，Paypal, eBay, Walmart 都在将既有的系统向 Node.js 迁移（/Node-js/What-companies-are-using-Node-js-in-production 翻墙看）。国内的淘宝、网易、百度等也都有很多项目运行在 Node.js 之上。2011 年我开始接触 Node.js 的时候，npmjs.org 上只有不到 3,000 个 Node.js 的 packages，今天()则有 61,897 个，这个数字还在快速增长中。下面有两个链接，第一个是在讲 Walmart 这几年为什么以及如何迁移到 Node.js 上；第二个则为 eBay 是如何从 Node.js 的怀疑者转变为采用者。&这篇文章的最后一段，列出了 eBay 为什么选择 Node.js。每天都有几百个新的 packages 被发布到&&上，小到几行代码，大到万行代码的 Framework。一天有7百万次的包下载（安装到某台电脑上），对于单一开发框架的社区来说，用沸腾的海洋来形容并不过分。&以下应用领域和程序员不适合选择Node.js：计算密集型应用。Javascript 的计算性能是很难和 C 语言代码相比的。当然，也有反例：http://onlinevillage.blogspot.jp/2011/03/is-javascript-is-faster-than-c.html，只不过不具有典型性。需要精密控制内存的分配和释放的场景，如果用 Node.js 实现 Redis 数据库，虽然程序会简单不少，但是 JVM 对内存数据结构的精密控制能力是比不了用 C 语言纯手工打造的。大量且需要频繁通过 C Binding 调用 C library 的情况。这种场景下，往返参数的 Marshal/Unmarshal 的成本可能会大于 C Library 带来的性能提升。实时性要求很高的场景，例如：交换机或者工控机器人。这是因为所有通过垃圾回收机制来管理内存的系统都有可能在 GC 过程中产生停顿，从而影响响应速度，而且很难优化。需要单一进程控制大内存的场景：v8 引擎的设计限制，在 32-bit下有 1GB 最大堆尺寸的限制，在 64-bit下是1.7GB。当然，由于 node.js buffer 的分配不是在 v8 的堆上，因此可以超过此限制。这个限制可以通过向 v8 引擎传递max_old_space_size&参数来超越，但是也会带来 GC 的性能退化。这一问题在几乎所有 GC Based 的系统下都存在。不关心系统吞吐率或者不需要异步调用的场景：例如，自动化脚本，这些脚本不需要关心多用户并发访问的性能消耗。用 Python 这样的“胶水”语言写起来会更简单。某些非通用场景：例如 nginx 对于静态 web server 或者 反向代理的场景是特别设计的，这些场景中 nginx 的性能比 Node.js 要好。强类型强迫症：有些 Java 或者 .NET 过来的程序员会认为只有强类型语言和严格定义的类型系统是专业化的象征，构造这样的系统是架构师的使命，而动态语言只是玩具，只能用来做 Demo 或者前端开发。团队成员难以理解或者接受函数式编程：Javascript 本质上更像函数式语言，有些程序员在理解和使用闭包、高阶函数等概念时总是不能习惯，这个问题在国内的开发团队中还挺普遍的。回调式编程的不习惯：Node.js 的异步IO 大量依赖回调。回调让程序的执行出现了两条路径，出现故障时调用栈也很难理解。这对习惯了同步编程的程序员来说一开始确实是个坎。async,&Q promise&等 package 可以缓解这个问题（在 ES6 的Generator 普及之前），不过这也带来了更陡峭的学习曲线。一般情况下，需要半年到一年的习惯过程，当然前提是多看，多写。随着越来越多的经验分享，这个过程也在不断地缩短。除此之外的领域，或者没有上述问题的，都都可以享受到 Node.js 带来的生产力提升和稳定的性能保障。性能的争议不同开发环境间的性能对比从来都是有争议的话题。我只能说，当开发 Web 或 网络环境下的应用时，Node.js 靠以下几个方面来避免出现不必要的性能问题：Chrome V8，一个可靠的优秀的虚拟机(hidden classes 和 inline caching)，让 Javascript 的运行速度进入了第一阵营(C++, Java, .NET)。异步 IO 大大降低了线程数量，莫名其妙的死锁和等待的概率被降低了很多。大部分场景不用去考虑并发和同步锁，犯错误的机会少。而在 Python 中，异步 IO 并不是标准，并没有被贯穿到所有 Package 中，因此应用程序也就很难获得一致的性能保障。非常轻巧的“内核”。Node.js 的模块分为 Core Modules 和 Userland 两部分。Core Modules 非常精简，只包括 TCP, HTTP, DNS, File System, child processes 和其他一些模块，这些网络库还只有异步版本。相对地，在 Userland 中却有着海量的 Packages。开发应用的时候，我们根据应用的需求来组合 Userland 的 Packages，使得我们的应用程序有机会在一个很低的资源消耗水平下运行（在中指出，一台开发服务器就可以支持 12 万活跃连接，平均每个连接消耗 2k 内存）。事实上，我开发的 WebSockte 应用在 Raspberry Pi 下都可以支持几百并发长连接（WebSocket）。和那些动辄上万个类的企业开发框架相比，这是一个巨大的优势。这种方式降低了出现问题的概率、查找问题的成本以及减少部署成本。对 Javascript 的绝对性能的追求一直没有停顿（例如， Mozilla 的&&）。而 Node.js 则在绝对性能的基础上，确保应用程序可以获得稳定和可预测的性能保障（ Benchmark 和实际的应用运行往往是两回事）。Node.js继承了JavaScript 的灵活性，优秀的JS库应当如何选择可以在 npmjs.org 或者 google 上搜索关键词。如果类似的返回很多，则看其被其他 package 依赖的数量有多少。上 github 上查看 starred 和 forks 的数量，读 issues。如果是“名人”（substack, visionmedia (TJ Holowaychuk), dominictarr, rvagg 等）写的 Packages 自然会被加分。最后是把 Git Repo. Clone 或者 Fork 下来, 阅读且注释他们的源代码。这个过程也可以发现很多他们依赖的其他 Packages。这是一个蛮享受的过程，可以学到很多新知识和新的用法。还有一些乱枪打鸟的方法：在 Tweeter 上关注 @nodenpm，所有在 npm 上发布或者更新的 packages 都会在该 handle 上发布出来。在你的碎片时间没事可以刷刷这个，当然你需要 APN 翻墙。关注一些推荐和评论账号：@dailyjs，@echojs 等。&会提供不错的开源信息汇总，其中包括 Node.js、Javascript 和 npm 栏目。&则不会让你忽略软件行业的一些“大事”或者新概念。一个项目开始前的研究阶段，我大约会浏览几十个 Packages，精读其中的5 ~ 10个。开发过程中则根据需要还会不断地发现和精读一些，这些都被我计入了项目的成本。"自由选择，自己负责"，在这个庞大的开发社区了不要指望有人能告诉你“标准答案”。每个人面临的问题域和知识背景都不一样，坚持多看，多试，多思考，享受获得新知识的过程比获得“标准答案”更重要。在众多的成熟开发框架下为什么需要Node.js在每一个特定的问题域，大家总是在尝试找到最优解。这个过程是没有终结的，就想最终也会有其他框架代替 Node.js 一样。今天的 Web，是无数相互连接的 Web Services 组成的，这些连接的本质是异步的。Node.js 天生异步的特性和这个场景的匹配度相对其他开发框架要更高，因此实现起来也更自然。除此之外，Node.js 的设计基本原则遵循了 《》，参见 Isaac Z. Schlueter (前任 Node.js 的Gatekeeper，目前负责 npm 的商业化) 的Blog：&。npm 和 stream 就是上述哲学的产物。npmnpm 是 Node.js 的包管理系统。包管理系统不是新东西，但是和 npm 的那些前辈和表兄弟不同的是：npm 直接集成在 Node.js 中，无需单独安装，发布，安装 packages 非常简单。npmjs.org 提供一个统一的入口，你可以看到每个 package 被哪些 packages 所依赖，你也可以一目了然地看到它依赖了誰，以及最近的下载次数。结合到 github 上的更新情况，基本上对一个 package 的基本情况你都能了解到。约定俗成的发布规范：一个 git repo. 让你可以直接找到源代码；README.md 提供简要的说明让消费者能尽快用起来。对于开发者来说，每一个 package 就是一个 "micro service"，是最小重用单元。大部分的 package 只有几百行代码，甚至有些只有几行代码。这样的重用粒度是在其他社区难以想象的。在 Node.js 的应用的开发过程中，编写 “一口尺寸”（bite-size）的 module 是推荐的编程方式。这也很方便你把这些小 module 封装为 package 分享到社区当中，而不用担心泄露“企业机密”。npm 是每一个 Noder 的 "home"，也是每一个 Node.js 应用的系统架构的一部分。Stream如果说，npm 提供了“开发时重用”的机制，那么 stream 的则提供了“运行时”不同组件之间的“重用”机制。stream 概念和 unix 中的 stream 对应，应用中的每一个 component 则对应 unix 的 filter。下面举一个实际的例子：在某个应用中，我需要一个 API Server，它的客户端包括 Web Browser，iOS App., 以及网络中的其他 Server。Web Browser 和我们的 API Server 的通信基于&(当然你也可以选择 SocketIO，或者 Faye 等)，它为浏览器兼容提供了适当的 “Fallback” 方案；对于 iOS App.来说，由于不需要考虑浏览器兼容，则采用基于标准的 RFC 6455 的纯 WebSocket 通信协议，这样实现起来更简单；而对于其他 Server 来说，局域网内则用 TCP，互联网上则用 TLS 来保证传输安全。我在 Node.js 上是这么实现的：利用&&构建一个通信无关的 RPC Server 来提供 API 服务。用 Node.js Core Modules 中的 tcp, tls 创建 TCP/TLS Server 并监听，用第三方的&&和&&分别创建 SockJS 和 WebSocket 的 Server 并监听。当 Client 连接到不同的端口，在 Server 上就会创建基于该协议的 Commnucation Stream，然后创建一个新的 dnode 实例，得到一个 dnode 的 Stream。最后将 Commnucation Stream 和 dnode Stream 像接水管一样接到一起即可。net.createServer(function(connStream){ &&&&&dnodeStream&=&dnode({&func1:&function(){}&}); &&&&&connStream.pipe(dnodeStream).pipe&connS &}); &考虑到在不稳定的网络环境下的自动重连需求，也可以添加&。不算你自己 RPC API 的实现逻辑，支持这么多的通信协议的 Server 框架只需要百十行代码，还加上了一定程度的异常处理。tcp, tls, SockJS，或者 reconnect 的开发者并不能确定“消费者”是如何使用这些 Package 的，但是大家都支持 Stream 的接口，则让自己的 Package 能够被运用到更多的场景。进一步，我们也可以多路复用一个底层的 Stream。我们把上面的例子再扩展一下：在既有的通信连接上（connStream），除了提供 RPC API 之外，还需要添加分布式的状态同步功能，例如：通过&，完成 Client 与 Server 或 Server 与 Server 之间的常量数据自动同步，而不用为这些功能设计新的 RPC API。通过&&，可以复用既有的网络通信 Stream（tcp, SockJS, Web Socket...），避免建立不必要的网络连接。Stream 是 Node.js 的核心概念之一，其接口和工作方式被广泛地采用，为不同组件在运行时相互通信提供了最基本的支持。在 Node.js 中，如何使用 Stream 可以用一本书的容量来描述，不是因为 Stream 的概念有多复杂，而是因为其组合方式非常丰富。小结三年前接触 Node.js，并且学习和采用，主要原因是因为 Node.js 在解决当今网络应用的问题时，提供了高性能、高可靠和低功耗的方法。高性能、高可靠和低功耗，不是在于 Node.js 做了什么，而是在于 Node.js 不做什么。Node.js 和 Javascript 的概念，在 Java 或者其他开发框架中都能找到对应的概念。但是 Node.js 仅保留了它认为最重要的部分作为 Core Modules，其他都让给了 User Land，这才是高性能、高可靠和低功耗的最本质的保障。随着 Node.js 这三年的发展，今天使我浸淫其中的理由已经不是之前的那些特点了。npm 建立了一个“人人为我，我为人人”社区，无论你是一个入门级的 Noder,还是一个多年的老兵，都在自觉或不自觉地从这个社区吸取营养，也在不断地回馈社区。在使用 npm 的过程中，你会很自然地发现，将自己的应用切割为尽量小的 Modules，发布为公有的 Packages，配上一个简单扼要的 README.md，反而是最有效率的系统架构方式。Node.js 所遵循的 Unix 设计哲学，又提供了最简单有效的复用规范。简单有效，才会被大家自觉采用，采用得越多，重用的可能性就更大。以&( MEAN 架构中的那个 \'E\' )为例，这么一个流行的 MVC Web Framework的核心代码只有 2,600 多行（不算测试，中间件和例子，但是包括注释）。npm 和 github 一起，为今天的软件生产提供了新的生产关系，这也是当前 Node.js 超越其他社区的根本原因。不是单纯的性能，也不仅仅是因为动态语言，甚至不是因为大量熟悉 Javascript 的前端程序员（和后端程序员相比，由于缺少系统性的思维，前端 Javascript 程序员掌握 Node.js 未必有多少优势 ），而是以更加便捷的分享式开发为基础的生产关系实实在在地提升了软件生产力。&Node.js的驾驭能力如果“复杂的后端程序” 等于 “庞大的继承树”，“强类型安全”，“精细的异常定义和处理”，那么 Node.js 当然无法驾驭。因为 Node.js 和 Java, .NET 相比，是一颗独立的“科技树”。原型继承、函数式编程、模块系统、回调...，这些概念和编程方式对习惯了 Java 以及 .NET 的程序员来说不仅仅是不熟悉，甚至一开始会产生“不舒服的”感觉。从我的体验来看（Basic-&C-&VB-&Delphi-&.NET-&Node.js），这种不舒服更多地来自于之前对严谨的类型系统的信仰。原本所谓的“架构师”，承担着整个应用或项目的类型系统的建设任务，对任何破坏类型一致性的行为都会自然而然的产生抵触情绪。要想掌握 Node.js，最好的方法是先从 Java, .NET 这颗“科技树”上爬下来，清空自己，然后重新爬 Node.js 这棵树。程序员从 Java, .NET 可以学到面向对象和泛型这些重用手段，而在 Node.js 的世界中，当你接触到大量来自于完全不同背景的程序员所编写的 Packages 的时候，你也会意识到，不是每样东西都是“类”，重用也不一定都基于继承。虽然有人试图在 Node.js 中克隆之前自己熟悉的类型系统，但是更多的程序员则在不断尝试更优雅、简单的编写方式。在 Node.js 的开发过程中，没有所谓的“最佳实践”，类似的问题总会有人尝试不同的解决方法。对于一个勤于思考和反思的程序员，这是一个充满乐趣的过程。反之，如果你的团队是由缺少独立思考或者独立解决问题的程序员组成的，那么 Node.js 确实不适合。你需要用强类型语言搭好一个受限的框架，然后让体力型的队友去填空。我们公司只有两个程序员，一个负责 iOS 开发，而我负责“复杂”后端程序和 Web Browser 开发。如果用 Java 或者 .NET 来开发，完成同样的功能需要至少三倍以上的人力。Node.js能否统一前后端完全统一既不可能，也没必要。再说这个所谓的“统一”与其放到 Node.js 脑袋上，不如送给 Javascript，因为 Javascript 用到的场景太多了。让我们看几个事实：Node.js 让我们可以用 Javascript 写后台程序Node.js 让我们写 Web Browser 前端：一方面，可以通过 Grunt 或者其他持续集成工具生成可发布的前端静态网站内容（例如:&）; 另一方面，也可以通过&&在前端代码中使用 Node.js 的 Modules，让前后台代码使用统一的代码基（例如：。很多 Node.js 的 Modules 本身就经过了浏览器兼容测试，可以同时运行在两端）。用 Node.js 开发桌面应用，例如：/rogerwang/node-webkit/wiki/List-of-apps-and-companies-using-node-webkit，列出了基于 node-webkit 的桌面应用列表。即使在性能受限的移动设备中，我们也可以通过 Javascript Binding 将一部分应用逻辑用 Javascript 来实现，而 UI 的渲染还是 Native 的方式。这在很多游戏中已经被采用(/question/)。只要用到 Javascript，或者说，随着 Javascript 代码基的扩大，npm based 的包管理方式就会通过 Browserify 的方式被慢慢引入。除了第二个问题提到的那些不适合 Node.js 的地方，其他领域想彻底不碰 Node.js 是很难的。&Node.js发展方向如果你的老板不让你碰 Node.js，你需要让他支付青春损失费。开个玩笑:)投资在 Node.js 不会吃亏。基于&&的贡献，前后台一致的代码基正在成为现实（在我的一个项目中已经如此，Web Client 通过 Node.js 的 stream 和后端传递数据 ）。你可以看到在前端使用原本为后台写的Module，或者用写后端程序的方法写前端代码，例如：。浏览器中无需运行一个完整的 Node.js，只要打包好需要的 Modules 下载到浏览器执行即可。在问题 5 中，大家已经看到 Node.js 在分布式计算领域的应用能力。 在问题 8 中，大家可以看到 Node.js 在客户端开发中所扮演的角色。传统的数据库这一领域也在发生变化。通用的数据库系统在未来会慢慢“失宠”，“乐高积木”化的存储服务会流行起来。Hackers 们围绕着&构建自己的存储引擎，从 key/value，到Graph DB；从基于 B 树的一维索引到基于 R-Tree 的多维索引；从能够在浏览器中运行的嵌入数据库到支持成千上万访问者，高可用的数据库系统；从支持两阶段提交的 Transaction 到，到支持实时增量的 Map-Reduce。在我的一个项目中已经开始采用这种方法，为特定的存储和查询需求构建特定的存储服务。这在以前是不可想象的，但是现在，也就是一个程序员的工作吧。我是一个自己写程序的“产品经理”。每年有8个月是集中开发的时间，剩下的时间则是负责产品设计。关注的方向从 Web、Mobile App. 到后端系统。Node.js 给我提供了无数块“乐高积木”，让我可以拼装自己的玩具，这是很快乐的体验的过程。遗憾的就是时间不够多，有那么多东西没时间去了解，去体会其他人的奇思妙想。小公司也是对成本极度敏感的，如果没有 Node.js 很多东西连想都不敢想。
评论Comments
微信公众号