GitHub 如何基於 Node.js 和 Chromium 開發 Atom？

看到回答里, 多数都没有回答到点子上, 还有些给了很是主观的意见而没有给出实际结论和分析过程.

题主的问题有四个: 

1. Github 如何基于 Node.js 和 Chromium 开发 Atom?

Atom 是基于 Atom-Shell (atom/atom-shell · GitHub) 开发的, atom-shell 是一个将 Chromium 和 Node.js (在最近的版本中已经替换成了 io.js 了) 整合在一块儿的 shell 框架. 那么他是如何整合 node.js 和 chromium 的呢? Atom-Shell 在浏览器的底层和渲染层分别加入了 node.js 的事件循环, 由此在浏览器内核中驱动了 node.js. 之因此将渲染层和内核层的事件循环区分, 是为了 CEF3 的渲染架构而这么设计的, 而为了可以让渲染层之间, 以及渲染层和内核层之间通信, 采用 ipc 进行封装, 具体的 ipc 实现我没深刻去查看源代码, 应该是直接走了 Chromium 的 IPC 接口. 
相似的 Shell 技术还有 nw.js 和 bracket-shell. 可是这些 shell 技术都有差别, 具体的差别能够阅读这几篇文档:

atom-shell/atom-shell-vs-node-webkit.md at master · atom/atom-shell · GitHub
https://speakerdeck.com/zcbenz/practice-on-embedding-node-dot-js-into-atom-editor
https://speakerdeck.com/zcbenz/node-webkit-app-runtime-based-on-chromium-and-node-dot-js

Github 的 Atom 就是在 Atom-Shell 的基础上, 经过 coffee-script 写页面端的表现, 经过 node.js/io.js 的整合处理 io 层的需求. 而后经过 atom-shell 整合操做系统中一些 native 窗口的能力.

2. 有过来人能分享学习经验?

学习经验倒也谈不上, 我基本上是阅读了一遍 atom-shell 官方的文档, 重点学习了一下如何使用 ipc 进行窗口间, 内核层之间的通信方式以及页面编程相关的知识. 这个过程当中, 我以为有几个地方能够系统学习:

1. 通信模型的创建:

为了更好的进行 ipc 通信, 咱们须要一些有效的经验模型来总结通信的方法, 为此, 我找了两个通信模型的文档进行学习:

Getting Started with 'nanomsg'
http://zguide.zeromq.org/page:all

经过对 nanomsg, zero-mq 中提出的几种通信方式的总结, 咱们渐渐地设计出符合咱们需求的消息通信编码规范, 和通信类型. 

2. CSS 排版, DOM 页面渲染知识:

为了可以让我写的 GUI 高效的在页面中运转, 我须要掌握更多的关于浏览器如何渲染 DOM, 如何解析 CSS 等浏览器渲染内核的知识, 为此我阅读了如下文档:

How Browsers Work: Behind the scenes of modern web browsers (这是一篇基础入门的好文章, 他让我在短短1个礼拜内, 经过本身的编码实践和扩展阅读理解了浏览器的大概的工做原理)
Getting Started With the WebKit Layout Code (这也是一篇很是好的文章, 他经过解析 Webkit 的底层 layout 代码, 让你明白整个浏览器是如何进行 css 排版工做的)
A Visual Method for Understanding WebKit Layout (这篇文章继承上一篇, 经过实践进一步理解 layout 的技术内容)
Rendering: repaint, reflow/relayout, restyle / Stoyan's phpied.com (这篇文章也是讲关于 reflow 的底层细节)
Understanding the CSS Specifications (而后由于 css 的文档自己太晦涩, 我一个初入门 web 前端编程的人一开始没能读懂, 因此我就先找到了这篇进行学习)
Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification (在那以后, 我进行了一些实践, 差很少以为能够掌握了, 就通读了一遍这篇文档, 并经过少许编码, 完成大部分 css2 的排版计算过程, 打通了我心中对于排版的诸多疑问)

这以后, 我又扩展阅读了如下一些 css 草案:

• CSS Animations CSS3 Animation 草案
• CSS Transitions CSS3 Transition 草案，transition和animaiton貌似有不少重合点，有待深究
• Web Animations 1.0 Web Animation 草案
• CSS Flexible Box Layout Module Level 1 CSS3 Flexbox 草案
• CSS Grid Layout Module Level 1 CSS3 Grid Layout 草案
• CSS Transforms Module Level 1 CSS3 Transform 草案，Transform 和 position 仍是有不一样之处，两个属性并无过分冗余
• CSS Shapes Module Level 1 CSS3 Float Shape 草案，图文混排方面，属于进阶需求

而后经过上面的几轮实践, 我又回过头来学习了如下几篇关于排版的知识点:

• Introduction to Layout in Mozilla 这是 Mozilla Gecko 引擎的 Layout 技术细节
• David Baron's CSS Playground Mozilla 的开发者的Blog，里头有很是多技术详解
• David's Inline Box Model 这是上述开发者里的一片关于 Inline Box 的详解
• The WebKit Open Source Project 这是 WebKit 中关于其技术细节的相关文档。
• CSS animations and transitions performance: looking inside the browser

大概前先后后花了约 4 个月时间, 完成了整个 web 渲染和排版的基础知识. 

3. Node.js/io.js 学习

Node.js 的学习我是在项目中持续进行的, 这期间因为项目进度比较紧张, 我并无很好的作好各类学习笔记, 因此很差意思, 没有特别多能够分享的经验. 

3. 还有经过这种方式开发移动应用呢?


有一些 Hybrid 的应用经过类似的方法构建, 比较出名的有:

• PhoneGap | Home
• The Crosswalk Project

这方面我接触的很少, 因此没有太多的经验能够分享.

4. 基于 Node 开发类桌面应用有什么建议?


我以为仍是要从项目自己的需求出发点考虑, 若是你是一个 javascript 依赖较多的项目, 或者一个偏页面应用的项目, 那么基于 Node/Chromium 构建的桌面 APP 将给你带来很是好的基础结构, 让你专一在开发自己.

 

 

*********************************************************************************************************************************************************

 

题主没必要把眼光局限在 ATOM，对于通常的应用程序，我更推荐 XDK 使用的框架 nodw-webkit，也就是如今的 NW.js，这个框架作起来很是顺手。

我不推荐 ATOM 所用的 atom-shell，缘由在于它比较难上手，特别是引入了 ipc 通信机制。若是你是作一些相似 CS 架构的应用，那么 ipc 是你的得力助手。若是你只是作一些普通的桌面应用，ipc 会逼着你把简单的任务复杂化，违反了 KISS 原则。并且 ipc 有不少坑，会成为你开发中最浪费时间的部分。

下文统一介绍一下这个领域现成的技术框架和成功案例：

• atom-shell

atom 基于 atom-shell 开发而来，atom-shell 基于 node.js(io.js) 和 Chromium(CEF2) 开发而来。
atom-shell 表明案例可参考 Fireball 总设计师回答的这个帖子：还要多少年, 前端开发才能像客户端开发那样轻松？ - Johnny Wu 的回答

• NW.js

NW.js 由 node-webkit 改名而来，技术底层和 atom-shell 是同样的，比 atom-shell 还容易上手，用的人最多。node-webkit 是为了支撑 Intel 自家的 XDK 而作的，谁会想到这样的 IDE 神器居然是用 JavaScript 写的？但也正是因为这点，nw 以前的更新停滞了一段时间，因而被咱们无情抛弃了，这个项目最近彷佛从新活跃了起来。

看完上面的两个框架和对应的案例，我想题主心中会有答案。此外相似的框架还有比较小众的 brackets-shell 和 heX，分别支撑 brackets 和 有道词典的开发。

下面是吐槽时刻：

nodejs + chromium ≈ sb

为何这么说，先说≠的部分，若是你要在linux花30分钟写出一个界面酷炫功能简单的小工具，nodejs+chromium（也就是node-webkit）是很好的选择，在windows上是vb，要界面酷炫的话 http://vb.net/c# + wpf，mac也请退坑，默认的就够好了。

谁都知道WPF和VB很好用，可是要跨平台怎么办？想要跨平台的话，用 node+web 再好不过了。

若是你要作个比较重的东西，chromium的效率和bug会把你拖累成狗，你说npm绝赞？node-webkit索然披着node皮可是用到本地代码的编译起来炒鸡蛋疼。

atom-shell 的 bug 响应时间是按天算的呢，chromium的效率还真的很棒。本地代码的编译蛋疼在哪了…… 不就一个命令行搞定的事吗？你要是换了其它技术，那编译起来各类依赖库才叫一个酸爽呢。

若是你要作一个小玩意，可是给人用，带个node-webkit不知道多重……

好几十MB，听起来是很重，可是我用有道词典那么多年了，一直没发现它很重啊？谁会注意到它是 CEF 作的呢。你作了一个棒棒的工具，这年头谁还会在意体积啊？

其余的，你要炫酷界面opengl/directui

网页作界面才叫酷炫呢，看看我上面的 atom-shell 案例

你要跨平台gtk / qt各有各的好

AIR 和 Java 更好，gtk/qt 已经入土为安了。

速度慢, 执行效率低.

看个人案例，游戏引擎都能作了，XDK 这样的重量级 IDE 都能作了，还有什么性能上可质疑的呢？

占用资源较多.

你作的什么应用，要常驻后台吗？你的内存还差这几十MB？

开发周期长.

明明是缩短了开发周期好吗…… 不信你跨个平台试试。就算不跨平台，你看看我前面 atom-shell 贴的案例吧，网页作起 UI 开发效率很高的。

references:

http://www.zhihu.com/question/23679877