Node-WebkitとElectron
クロスプラットフォームのデスクトップアプリケーションを構築する予定です。 Node-Webkit が最適な選択であることがわかりました。しかし、GitHubはNode-Webkitを使用する代わりに、 Electron と呼ばれる独自のフレームワークを開発しました。
それらの違いは何ですか？
Electronには、node-webkitとの違いを説明するページがあります：
https://github.com/atom/electron/blob/master/docs/development/atom-Shell-vs-node-webkit.md
Node-Webkitと同様に、ElectronはJavaScriptとHTMLを使用してデスクトップアプリケーションを作成するプラットフォームを提供し、Webページの低レベルシステムへのアクセスを許可するためのNode統合を備えています。
しかし、ElectronをNode-Webkitから完全に分離した製品にする2つのプロジェクトには根本的な違いもあります。
1-アプリケーションのエントリ
NW.jsでは、アプリケーションのメインエントリポイントはWebページまたはJSスクリプトです。 package.jsonでhtmlまたはjsファイルを指定すると、アプリケーションのメインウィンドウ（htmlエントリポイントの場合）としてブラウザーウィンドウで開かれるか、スクリプトが実行されます。
Electronでは、エントリポイントはJavaScriptスクリプトであり、URLを直接提供するのではなく、ブラウザーウィンドウを手動で作成し、対応するAPIでhtmlファイルをロードする必要があります。また、アプリケーションを終了するタイミングを決定するために、ウィンドウイベントをリッスンする必要があります。
ElectronはNode.jsランタイムのように動作し、APIはより低レベルです。また、phantomjsのようなWebテスト目的でElectronを使用することもできます。
2-ビルドシステム
Chromium全体の構築の複雑さを回避するため、Electronはlibchromiumcontentを使用してChromiumのContent APIにアクセスします。libchromiumcontentは、Chromium Contentモジュールとそのすべての依存関係を含む単一の共有ライブラリです。そのため、ユーザーはatom-Shellを構築するために強力なマシンを必要としません。
3-Node統合
Node-Webkitでは、Node Webページへの統合にはChromiumにパッチを適用する必要がありますが、Electronでは、libuvループを各プラットフォームのメッセージループに統合してChromiumのハッキングを回避する別の方法を選択しました。それが行われた方法のnode_bindingsコード。
4-マルチコンテキスト
経験豊富なNode-Webkitユーザーの場合、NodeコンテキストとWebコンテキストの概念に精通している必要があります。これらの概念はNode-Webkitの実装方法により発明されました。
Nodeのマルチコンテキスト機能を使用することで、ElectronはWebページに新しいJavaScriptコンテキストを導入しません。
ソースコード保護
Electronは、アプリケーションの保護されていないソースコードを含む asar でアプリケーションをパッケージ化しています。これにより、アプリケーション1がアプリケーション2を抽出し、ユーザーに気付かれずに脆弱なスクリプトを挿入できます。 GitHubのこのプロジェクトでは、Slackアプリの操作方法の例を確認できます をチェックアウトできます。今のところ、 Electronチームには、ソースコード保護のサポートを実装する計画はありません 。
NW.jsには ソースコードを保護されたバイナリにコンパイルするためのサポートが組み込まれています があります。