Electron 1.0 即将到来的 API 变更
自从 Electron 诞生之初，也就是它还叫 Atom-Shell 的时候，我们就一直在尝试为 Chromium 的内容模块和原生 GUI 组件提供一个良好的跨平台 JavaScript API。这些 API 的起步非常自然，随着时间的推移，我们已经对最初的设计进行了多次改进。
🌐 Since the beginning of Electron, starting way back when it used to be called Atom-Shell, we have been experimenting with providing a nice cross-platform JavaScript API for Chromium's content module and native GUI components. The APIs started very organically, and over time we have made several changes to improve the initial designs.
现在 Electron 正在准备 1.0 版本的发布，我们希望借此机会通过解决最后一些令人烦恼的 API 细节来进行调整。下面描述的更改已包含在 0.35.x 中，旧的 API 会显示弃用警告，以便你为未来的 1.0 版本做好更新准备。Electron 1.0 在几个月内才会发布，所以在这些更改变为不兼容之前，你还有一些时间。
🌐 Now with Electron gearing up for a 1.0 release, we'd like to take the opportunity for change by addressing the last niggling API details. The changes described below are included in 0.35.x, with the old APIs reporting deprecation warnings so you can get up to date for the future 1.0 release. An Electron 1.0 won't be out for a few months so you have some time before these changes become breaking.
弃用警告
🌐 Deprecation warnings
默认情况下，如果你使用已弃用的 API，将会显示警告。要关闭它们，你可以将 process.noDeprecation 设置为 true。要跟踪已弃用 API 使用的来源，你可以将 process.throwDeprecation 设置为 true 来抛出异常而不是打印警告，或者将 process.traceDeprecation 设置为 true 来打印弃用的跟踪信息。
🌐 By default, warnings will show if you are using deprecated APIs. To turn them off you can set process.noDeprecation to true. To track the sources of deprecated API usages, you can set process.throwDeprecation to true to throw exceptions instead of printing warnings, or set process.traceDeprecation to true to print the traces of the deprecations.
使用内置模块的新方法
🌐 New way of using built-in modules
内置模块现在被归类到一个模块中，而不是分成独立的模块，因此你可以像 与其他模块不冲突 一样使用它们：
🌐 Built-in modules are now grouped into one module, instead of being separated into independent modules, so you can use them without conflicts with other modules:
var app = require('electron').app;
var BrowserWindow = require('electron').BrowserWindow;
为了向后兼容，旧的 require('app') 方式仍然受到支持，但你也可以将其关闭：
🌐 The old way of require('app') is still supported for backward compatibility, but you can also turn if off:
require('electron').hideInternalModules();
require('app'); // throws error.
使用 remote 模块的更简单方法
🌐 An easier way to use the remote module
由于使用内置模块的方式发生了变化，我们已经使在渲染进程中使用主进程侧模块变得更容易。现在你只需访问 remote 的属性即可使用它们：
🌐 Because of the way using built-in modules has changed, we have made it easier to use main-process-side modules in renderer process. You can now just access remote's attributes to use them:
// New way.
var app = require('electron').remote.app;
var BrowserWindow = require('electron').remote.BrowserWindow;
不使用冗长的请求链：
🌐 Instead of using a long require chain:
// Old way.
var app = require('electron').remote.require('app');
var BrowserWindow = require('electron').remote.require('BrowserWindow');
拆分 ipc 模块
🌐 Splitting the ipc module
ipc 模块在主进程和渲染进程中都有存在，并且每一方的 API 都不同，这对新用户来说相当困惑。我们已将该模块在主进程中重命名为 ipcMain，在渲染进程中重命名为 ipcRenderer，以避免混淆：
🌐 The ipc module existed on both the main process and renderer process and the API was different on each side, which is quite confusing for new users. We have renamed the module to ipcMain in the main process, and ipcRenderer in the renderer process to avoid confusion:
// In main process.
var ipcMain = require('electron').ipcMain;
// In renderer process.
var ipcRenderer = require('electron').ipcRenderer;
对于 ipcRenderer 模块，在接收消息时新增了一个 event 对象，以匹配 ipcMain 模块中处理消息的方式：
🌐 And for the ipcRenderer module, an extra event object has been added when receiving messages, to match how messages are handled in ipcMain modules:
ipcRenderer.on('message', function (event) {
console.log(event);
});
标准化 BrowserWindow 选项
🌐 Standardizing BrowserWindow options
BrowserWindow 选项基于其他 API 的选项有不同的风格，并且由于名称中的 -，在 JavaScript 中使用起来有些困难。它们现在已统一为传统的 JavaScript 名称：
🌐 The BrowserWindow options had different styles based on the options of other APIs, and were a bit hard to use in JavaScript because of the - in the names. They are now standardized to the traditional JavaScript names:
new BrowserWindow({ minWidth: 800, minHeight: 600 });
遵循 DOM 的 API 命名约定
🌐 Following DOM's conventions for API names
Electron 中的 API 名称过去偏向于对所有 API 名称使用驼峰命名法，例如 Url 到 URL，但 DOM 有其自身的命名规范，它们更倾向于 URL 到 Url，同时使用 Id 而不是 ID。我们已进行了以下 API 重命名以匹配 DOM 的风格：
🌐 The API names in Electron used to prefer camelCase for all API names, like Url to URL, but the DOM has its own conventions, and they prefer URL to Url, while using Id instead of ID. We have done the following API renames to match the DOM's styles:
Url已重命名为URLCsp已重命名为CSP
由于这些更改，当你在应用中使用 Electron v0.35.0 时，你会注意到很多已弃用的警告。一个简单的解决方法是将所有 Url 实例替换为 URL。
🌐 You will notice lots of deprecations when using Electron v0.35.0 for your app because of these changes. An easy way to fix them is to replace all instances of Url with URL.
Tray的事件名称更改
🌐 Changes to Tray's event names
Tray 事件名称的风格与其他模块有些不同，因此已进行重命名以与其他模块保持一致。
🌐 The style of Tray event names was a bit different from other modules so a rename has been done to make it match the others.
clicked已重命名为clickdouble-clicked已重命名为double-clickright-clicked已重命名为right-click
