requirejs中除了页面中用require，define是不是可以替代require

没有什么地方必须用require，但是两者的意义是不一样的。定义模块需要用define，而不是require。如果是requirejs的程序入口，则是用require更合适。当然你把define当做require来用也没什么，但感觉那样就不make

sense了

先纠正一点，css不是程序，它类似于装修设计图纸，而图纸是不会自己去进行施工的对吧，所以css不存在执行与否或者执行早晚的问题，只能这么说，浏览器在渲染页面时会自动按照css中的设定来进行，所以它作用于（而不是执行于）网页的渲染阶段。js则是程序，理论上它可以执行于任何阶段（当然是在浏览器获得网页数据之后），但是如果js程序涉及 *** 作页面dom元素，则在渲染阶段可能会出错（因为涉及的dom元素可能尚未调入内存），因此，通常一个健全的、完善的网页，都会先把html、css、js等调入内存，然后再开始执行js，这可以通过把js的入口放在window对象的load事件过程中来实现。

注意: Electron 以前被称为 Atom Shell。

与 NW.js 相似，Electron 提供了一个能通过 JavaScript 和 HTML 创建桌面应用的平台，同时集成 Node 来授予网页访问底层系统的权限。

但是这两个项目也有本质上的区别，使得 Electron 和 NW.js 成为两个相互独立的产品。

1. 程序的入口

在NW.js中，应用的主入口是网页或者JS脚本。 你需要在package.json中指定一个html或者js文件，一旦应用的主窗口(在html作为主入口点的情况下)或脚本被执行，应用就会在浏览器窗口打开。

在 Electron 中，入口是一个 JavaScript 脚本。 不同于直接提供一个URL，你需要手动创建一个浏览器窗口，然后通过 API 加载 HTML 文件。 你还可以监听窗口事件，决定何时让应用退出。

Electron 的工作方式更像 Node.js 运行时。 Electron 的 APIs 更加底层，因此你可以用它替代 PhantomJS 做浏览器测试。

2. 构建系统

为了避免构建整个 Chromium 带来的复杂度，Electron 通过 libchromiumcontent 来访问 Chromium 的 Content API。 libchromiumcontent 是一个独立的、引入了 Chromium Content 模块及其所有依赖的共享库。 用户不需要一个强劲的机器来构建 Electron。

3. Node 集成

在 NW.js，网页中的 Node 集成需要通过给 Chromium 打补丁来实现。但在 Electron 中，我们选择了另一种方式：通过各个平台的消息循环与 libuv 的循环集成，避免了直接在 Chromium 上做改动。 你可以查看 node_bindings 来了解这是如何完成的。

4. 多上下文语境

如果你是有经验的 NW.js 用户，你应该会熟悉 Node 上下文和 web 上下文的概念。这些概念的产生源于 NW.js 的实现方式。

通过使用Node的multi-context(多上下文)特性，Electron不需要在网页中引入新的Javascript上下文。

注意: 自从 0.13 以来，NW.js 选择性支持多上下文。

---