fastmail 提供了一个服务器（ smtps-proxy.messagingengine.com ），这台服务器上所有的端口都提供 smtp 服务，用来应对防火墙的屏蔽（ https://www.fastmail.com/help/technical/servernamesandports.html#proxy ）

@menc 我不能同意「功能有限（或短）就等于不严肃（或不负责任）」这一点。

@ChefIsAwesome 我觉得楼主的问题同样值得讨论，当然楼主的语气不是很好，比如反问用得太多了。

回楼主的问题：

从使用者的角度，这样做的意义是前端对代码体积非常敏感，希望最后发布的代码中只包括自己真正被用到的部分，虽然可以基于模块来拆分（例如 Lodash 既提供整体发行包，又为每个函数提供单独的包或单独的模块，方便开发者选择性地使用），但相比之下分包要显得简单易行一些。

从作者的角度，可能作者一开始只需要一个能完成特定的、很小的工作的库，但没有找到现成的，于是自己写了一个并发布出去。如果你要求作者一定要凑齐所有相关的功能再发布，未免要求太高了，像 Lodash 这种项目，必然是要有专门的人，像对待一项独立的工作一样去维护才能成型的，其实 Lodash 可能就是楼主所希望看到的样子。

>前端近几年出了很多搞不懂的东西，逼格一下子高了许多。
作为一个 Node.js 服务器端工程师，表示 NPM 并不仅是前端在使用，比如 left-pad 这个包和浏览器并没有直接关系。

>PHP 的包管理是加载到项目目录运行的，这个是每次从线上加载？
PHP 的包难道不是从仓库下载的么？如果作者把包从 packagist （不太理解 packagist 是否允许撤下已发布的包）或 GitHub 上撤下也是一样的。

>民心已失。我猜很快会有一个新的完全开放的平台出来。
我个人认为只是 @azer 太矫情了而已， NPM 对于解决包名纠纷有很明确的规则（ https://docs.npmjs.com/misc/disputes ），这是一次很透明的操作。如果对方持有商标，我相信在大部分平台都是可以拿到对应的名字的。

>npm 目前的机制基本无法处理这次危机，超过 250 个项目被移除，其他依赖项目不仅需要寻找替代品，还要防范其他人伪造同名库。
一方面可以修改 unpublish 包的规则（满足特定规则才可以 unpublish 已发布的版本），如果作者的包使用一个自由软件许可证发布的话，从法律上来说，不允许删除也是完全可行的。另一方面可以继续推 Scoped packages （ https://docs.npmjs.com/misc/scope ），像 GitHub 一样以自己的用户名为前缀，虽然用户名可能也有纠纷，但应该会比包名的纠纷少一点。

看到贝米钱包还在扩大规模我就放心了~

关键词：「 node webkit vm snapshot 」 https://github.com/miklschmidt/node-nw-snapshot

最好能提供一个在线制作如 http://skill.phodal.com 的技能树的工具，制作好之后可以将链接分享出去，其他人可以来根据自己的情况点技能，还可以将点了一些技能的页面再分享出去。

express 默认 jade ？据我所知当前版本的 express 已经移除了所有和具体模板引擎有关的逻辑，你可以在源代码中搜索 `jade` 这个词，只出现在了示例和注释中。

相比于 ejs 等模板引擎 Jade 的劣势：

只能渲染 HTML （而很多应用需要渲染非 HTML 内容）；
JavaScript 程序员不习惯用缩进来表示层级（很多编辑器对基于缩进表示层级的语言支持也比较差）；
Jade 引擎的代码量是 ejs 的几倍，如果希望在前后端使用同一个模板引擎， jade 可能不是一个好的选择。

这一点在很多地方都适用，做外包的时候，愿意给出更高价格的客户往往会更理解你的工作；卖软件的时候，不愿意付更高价格的用户往往会有更多不合理的要求。

我想提一种情况，比如有两个 API ： DELETE /users 和 DELETE /users/:name ，分别是删除所有用户和删除指定用户。如果在调用后者时忘记加 name ，就变成了 DELETE /users/，我觉得最好还是不要当作前者，而是直接报错好一些。

既然帖子列表是时间顺序，那么用时间代替页数不就好了么。例如访问首页时，列表中最后一个帖子的回复时间是 T1, 那么在点击「下一页」的时候，客户端向服务器发请求获取「回复时间早于 T1 」的帖子即可。

@otakustay 哈哈，作为程序员当然清楚 Bug 是永远修不完的，更新要是不给力怎么用得下去？尤其 Sublime Text 还不是开源的。

@zhuangdasheng 这里有大尺寸的图 https://jysperm.me/avatars/v5.png

@sox 感谢提醒，这里是我写错了，应该是与上一次的 Virtual DOM 进行对比，附参考链接 https://facebook.github.io/react/docs/reconciliation.html

Atom 的所有数据（包括自行安装的插件）默认存储在 Home 目录下的 .atom 中，但如果在 Atom 主程序目录下有 .atom 目录，则优先使用这个 .atom 目录。
这里有个类似的讨论可供参考： https://atom-china.org/t/atom/895

你好，我是 Atom China 的维护者，说实话我实在不理解为什么对这个话题感兴趣的人这么多。
Atom China 和 Atom 官方社区一样，使用 Discourse https://github.com/discourse/discourse

一种情况是一楼说的 Content-Length, 还有一种是 Transfer-Encoding=chunked
详见 https://zh.wikipedia.org/wiki/%E5%88%86%E5%9D%97%E4%BC%A0%E8%BE%93%E7%BC%96%E7%A0%81

这种不可逆、不可冻结的代价就是整个比特币系统必然是低效的，就好像一个充分民主的社会也必然是低效的一样。