メインコンテンツへ飛ぶ

WebView2 と Electron

· 読むのにかかる時間 1 分

この数週間で、新しい WebView2 と Electron の違いについていくつかご質問をいただきました。

両チームとも、ウェブ技術をデスクトップ上で最高のものにするという目標を掲げているため、共通点の総合的な比較を検討してみましょう。

Electron と WebView2 は、行動が早く、常に進化しているプロジェクトです。 現在の Electron と WebView2 の共通点と相違点を簡単にまとめてみました。


アーキテクチャの概要

Electron と WebView2 はどちらも、ウェブコンテンツのレンダリングに Chromium ソースを使用しています。 厳密には WebView2 は Edge のソースからビルドされています。しかし、Edge は Chromium のソースをフォークしてビルドされています。 Electron は Chrome と DLL を共有していません。 WebView2 のバイナリは、Edge (Edge 90 の安定チャンネル) をハードリンクしているので、ディスクや一部の動作セットを共有しています。 詳細は Evergreen ディストリビューションモード をご参照ください。

Electron アプリは、常に開発時のバージョンの Electron をバンドルして頒布しています。 WebView2 では、頒布にあたって 2 つの選択肢があります。 アプリケーションが開発された WebView2 ライブラリをそのままバンドルすることもできますし、システム上に既存の共有ランタイム版を使用することもできます。 WebView2 は、共有ランタイムが見つからない場合のブートストラップインストーラーを含む、各手段向けのツールを提供しています。 WebView2 は、Windows 11 から 標準で 付属します。

フレームワークをバンドルしているアプリケーションは、マイナーなセキュリティリリースを含め、そのフレームワークをアップデートする責任があります。 共有 WebView2 ランタイムを使用しているアプリの場合、WebView2 には Chrome や Edge に似た独自の更新機能が用意されており、アプリとは独立して実行されます。 Electron と同じく、アプリケーションのコードやその他の依存関係の更新は開発者の責任です。 Electron も WebView2 も Windows Update では管理されません。

Electron と WebView2 は、どちらも Chromium のマルチプロセスアーキテクチャを継承しています。つまり、1 つのメインプロセスが 1 つ以上のレンダラープロセスと通信します。 これらのプロセスは、システム上で動作している他のアプリケーションと完全に分離されます。 すべての Electron アプリケーションは、ルートのブラウザプロセス、いくつかのユーティリティプロセス、0 個以上のレンダープロセスを含む、独立したプロセスツリーを構成します。 同じ ユーザーデータフォルダ を使用している WebView2 アプリ (スイートアプリのようなもの) は、レンダラープロセス以外を共有します。 異なるデータフォルダを使用している WebView2 アプリは、プロセスを共有しません。

  • ElectronJS プロセスモデル:

    ElectronJS プロセスモデル図

  • WebView2 ベースのアプリケーションプロセスモデル:

    WebView2 プロセスモデル図

WebView2 のプロセスモデルElectron のプロセスモデル についてはこちらをご覧ください。

Electron は、メニュー、ファイルシステムへのアクセス、通知など、デスクトップアプリケーションの一般的需要に応える API を提供します。 WebView2 は、WinForms、WPF、WinUI、Win32 などのアプリケーションフレームワークに統合されることを目的としたコンポーネントです。 WebView2 は JavaScript によるウェブ規格外の OS API を提供しません。

Electron は Node.js を統合しています。 Electron アプリケーションは、レンダラープロセスやメインプロセスから Node.js API、モジュール、Node ネイティブアドオンを利用できます。 WebView2 アプリケーションは、アプリケーションの他の部分が書かれている言語やフレームワークを前提にしていません。 JavaScript コードからオペレーティングシステムへアクセスするには、アプリケーションホストプロセスを介する必要があります。

Electron は、Fugu Project が開発した API を含むウェブ API との互換性を維持するよう努めています。 こちらに Electron の Fugu API 対応状況のスナップショット を用意しました。 WebView2 では、Edge との API の違い について同様のリストを作成しています。

Electron でのウェブコンテンツのセキュリティモデルは、フルアクセスからフルサンドボックスまで設定可能です。 WebView2 のコンテンツは常にサンドボックス化されます。 Electron はセキュリティモデルの選択について、包括的なセキュリティドキュメント を用意しています。 WebView2 にも セキュリティのベストプラクティス が用意されています。

Electron のソースは GitHub 上でメンテンスされており、自由に利用できます。 アプリケーションは、Electron の独自 ブランド を構築できるように変更を加えられます。 WebView2 のソースは GitHub 上で利用できません。

簡単な概要:

ElectronWebView2
ビルドの依存関係Chromiumエッジ
GitHub 上でコードが利用可能ありなし
Edge/Chrome DLL の共有なしあり (Edge 90 のもの)
アプリケーション間でのランタイム共有なし任意
アプリケーション APIありなし
Node.jsありなし
サンドボックス任意常時
アプリケーションフレームワークの必要性なしあり
サポートされているプラットフォームMac, Win, LinuxWin (Mac/Linux は計画中)
アプリ間でのプロセス共有なし任意
フレームワークの更新機構アプリケーションWebView2

パフォーマンスの議論

ウェブコンテンツのレンダリングに関しては、Electron、WebView2、その他 Chromium ベースのレンダラーの間におけるパフォーマンスの差はほとんどないと考えています。 私たちは、潜在的なパフォーマンスの違いを調査するご興味のある方向けに Electron、C++ + WebView2、C# + WebView2 で構築したアプリの土台 を作成しました。

ウェブコンテンツのレンダリング 以外 にもいくつかの違いがあり、Electron、WebView2、Edge などの関係者は、PWA を含めた詳細な比較を行うことに興味を示しています。

プロセス間通信 (IPC)

プロセス間通信は、Electron アプリでのパフォーマンスを考慮する必要があるでしょう。これにはすぐに強調すべき違いがあります。

Chromium では、サンドボックス化したレンダラーとシステムの他の部分との間で、ブラウザプロセスが IPC ブローカーとして機能します。 Electron ではサンドボックスのないレンダープロセスにできますが、多くのアプリはセキュリティ強化のためにサンドボックスを有効にしています。 WebView2 は常にサンドボックスが有効なので、ほとんどの Electron および WebView2 アプリでは IPC が全体のパフォーマンスに影響を与えます。

Electron と WebView2 はプロセスモデルが似ていますが、基礎の IPC が異なります。 JavaScript と C++ や C# の間で通信するには、マーシャリング が必要です。最も一般的なのは JSON 文字列への変換でしょう。 JSON のシリアライズ/パースは重い処理であり、この IPC のボトルネックはパフォーマンスに悪影響を及ぼします。 Edge 93 以降、WV2 はネットワークイベントに CBOR を使用します。

Electron は MessagePorts API を介した直接の IPC を任意の 2 つのプロセス間でサポートしており、これは 構造化複製アルゴリズム を利用しています。 これを活用するアプリケーションは、プロセス間でオブジェクトを送信する際の JSON シリアライズのコストを回避できます。

概要

Electron と WebView2 にはいくつかの違いがありますが、ウェブコンテンツのレンダリング方法に関しては大きな違いはありません。 最終的には、アプリケーションのアーキテクチャと JavaScript ライブラリ/フレームワークが、メモリとパフォーマンスに何よりも大きな影響を与えます。なぜなら、実行箇所に関わらず Chromium は Chromium だからです。

この記事をレビューしてくださり、WebView2 アーキテクチャの最新情報を提供して頂いた WebView2 チームに感謝します。 WebView2 チームの皆さんは プロジェクトのフィードバック を歓迎しています。

新しい Electron リリースケイデンス

· 読むのにかかる時間 1 分

2021 年 9 月から、Electron は 8 週間ごとに新規メジャー安定版をリリースするようになります。


2019 年、Chromium の 6 週間のリリースサイクルに合わせて Electron は 12 週間のリリースサイクルに移行 しました。 先日、Chrome と Microsoft の両方が変更を発表し、Electron の現在のリリースサイクルを再考することになりました。

  1. Chromium は、2021 年 9 月 21 日の Chrome 94 を皮切りに、4 週間 ごとに新規マイルストーンをリリースする予定です。また、このリリースサイクルでは 8 週間ごとに新しい拡張安定版オプションが追加され、すべてのセキュリティ修正が更新されます。

  2. Microsoft Store では、Chromium ベースのアプリが最新から 2 つのメジャーバージョン以内であることを要求するようになります。 例えば、Chromium の最新のメジャーバージョンが 85 の場合、Chromium をベースにしたブラウザは最低でも Chromium バージョン 83 以上でなければなりません。 このルールは Electron アプリも含みます。

Chromium の 8 週間の拡張安定版リリースに合わせて、Electron は 2021 年 9 月より 8 週間ごとに新しいメジャー安定版をリリースする予定です

Chromium 拡張安定版での最初のリリースは、Electron 152021 年 9 月 21 日 になります。

リリースケイデンスの変更は下流の他のアプリケーションにも影響を与えることがわかっているため、できるだけ早く開発者コミュニティに知らせたいと思っております。 2021 年のリリーススケジュールの詳細はこちらをご覧ください。

Electron 15: 臨時アルファ

当初の Electron 15 のリリースは拡張安定版ではないバージョンを対象としていたため (Chromium の拡張安定版バージョンは偶数番号のバージョンをベースにしています)、当初の目標リリース日を変更する必要がありました。 しかし、Electron アプリを Microsoft Store に登録するためには Chromium の最新から 2 つ以内のメジャーバージョンを使用する必要がありましたが、Chromium のバージョンを 2 つ待つことはできません。

この 2 つの要件を満たそうと、チームはタイミングのジレンマに陥りました。 Electron 15 に Chromium M94 を搭載することで、アプリケーション開発者は Chromium の最初の拡張安定版バージョンを利用できるようになりますが、ベータ版から安定版へのサイクルはわずか 3 週間にまで短くなります。

この切り替えを支援するため、Electron は Electron 15 リリースのみを対象とした臨時の アルファビルド を提供します。 このアルファビルドは開発者が Electron 15 のリリースに向けてテストや計画を立てるための時間を確保するためのもので、現在の nightly よりも安定したビルドになっています。

このアルファチャンネルビルドは、Electron 15 として 2021 年 7 月 20 日 に頒布されます。 2021 年 9 月 1 日 にベータ版リリースに移行し、2021 年 9 月 21 日 に安定版リリースを行う予定です。 その後の Electron のリリースではアルファ版のリリースはありません。

2021 年のリリース計画

現在の 2021 年のリリース予定は以下の通りです。

ElectronChromeアルファリリースベータリリース安定版リリース安定版の周期 (週間)
E13M91-2021-Mar-052021-May-2512
E14M93-2021-May-262021-Aug-3114
E15M942021-Jul-202021-Sep-012021-Sep-219 (アルファを含む)
E16M96-2021-Sep-222021-Nov-168
E17M98-2021-Nov-172022-Feb-0111

アルファチャンネルの追加により、Electron 15 のリリースまでの開発期間は 3 週間から 9 週間に延長されました。新しい 8 週間のサイクルに近づきつつ、Windows Store への提出要件を満たせます。

アプリ開発者をさらに支援するために、2021 年の残りの期間から 2022 年 5 月まで、サポートされるバージョンのポリシーを最新 3 バージョンから最新 4 バージョンの Electron に拡張することも決定しました。つまり、アップグレードのスケジュールをすぐに変更できなくても、古いバージョンの Electron にはセキュリティアップデートや修正プログラムが提供されるということです。

懸念事項への対応

リリースサイクルの変更予定よりかなり前に、この記事を公開しているのには理由があります。 リリースサイクルの高速化は、Electron アプリに大きな影響を与えると考えています。中には、私たちのメジャーリリースのペースがすでに積極的すぎると感じている人もいるかもしれません。

以下に、よくある質問をまとめてみました。

❓ なぜこの変更を行うのでしょうか? 12 週間のリリース周期を維持しないのですか?

Electron で Chromium の最新バージョンを提供するには、そのスケジュールを追う必要があります。 Chromium のリリースサイクルに関する詳細は こちら を参照してください。

加えて、現在の 12 週間のリリースサイクルでは、Microsoft Store の新しい提出要件に対応できません。 Electron の最新の安定版を使用しているアプリであっても、約 2 週間の間は新しいセキュリティ要件によりアプリが拒否される可能性があります。

Chromium の各新規リリースには、新機能、バグ修正/セキュリティ修正、V8 の改善が含まれています。 アプリ開発者の皆様にはこれらの変更をタイムリーに受けていただきたいので、安定版のリリース日は他の Chromium 安定版のリリース日と一致させています。 アプリケーション開発者は、Chromium や V8 の新機能や修正に、これまでよりも早くアクセスできるようになります。

❓ 既存の 12 週間のリリーススケジュールでも、既に早いです。 アップグレードを容易にするには、チームでどのような段階を踏めばよいでしょうか?

より頻繁にリリースすることの利点は、より小さい リリースができることです。 Electron のメジャーバージョンのアップグレードは大変だと思います。 リリースを小さくするほど、1 回のリリースにおける Chromium や Node のメジャーの変更や破壊的変更が少なくなることを期待しています。

❓ 今後の Electron のバージョンに対応したアルファ版のリリースはありますか?

現時点では、恒久的にアルファリリースをサポートする予定はありません。 このアルファは Electron 15 のみを対象としており、短いリリース期間の中で開発者がより簡単にアップグレードできるようにするためのものです。

❓ Electron はバージョンのサポート数を増やしていくのでしょうか?

2022 年 5 月の Electron 19 のリリースまでは、サポートバージョンポリシーを最新 3 つから最新 4 つのバージョンに拡張する予定です。 Electron 19 のリリース後は、ベータや nightly リリースと同じく 最新のメジャーバージョン 3 つ をサポートする体制に戻ります。

E13 (May'21)E14 (Aug'21)E15 (Sep'21)E16 (Nov'21)E17 (Feb'22)E18 (Mar'22)E19 (May'22)
13.x.y14.x.y15.x.y16.x.y17.x.y18.x.y19.x.y
12.x.y13.x.y14.x.y15.x.y16.x.y17.x.y18.x.y
11.x.y12.x.y13.x.y14.x.y15.x.y16.x.y17.x.y
----12.x.y13.x.y14.x.y15.x.y--

質問?

📨 ご質問やご不明な点がございましたら、info@electronjs.org までメールでお問い合わせしていただくか、Discord に参加して ご連絡ください。 この変更が多くのアプリケーションや開発者に影響を与えることは承知しており、皆様からのフィードバックは私たちにとって非常に重要です。 ご連絡をお待ちしております!

Electron 13.0.0

· 読むのにかかる時間 1 分

Electron 13.0.0 がリリースされました! これには Chromium 91 とV8 9.1 へのアップグレードが含まれています。 いくつかの API の更新、バグ修正、及び一般的な改善を行いました。 詳しくは以下をご覧ください!


Electron チームは、Electron 13.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

注目すべき変更

累積的変更

注目の機能

  • process.contextIsolated プロパティを追加しました。これは現在のレンダラーコンテキストで contextIsolation が有効かどうかを示します。 #28252
  • セッション固有のデータに対するディスク上のパスを取得するために新しく session.storagePath API を追加しました。 #28866
  • WebContentsnew-window イベントを非推奨にしました。 これは webContents.setWindowOpenHandler() に置き換えられます。
  • @electron/remote で使用されている process.contextId を追加しました。 #28251

新機能と変更の完全なリストは、13.0.0 リリースノート を参照してください。

破壊的変更

  • window.open() の引数 frameName はウインドウタイトルとして設定されなくなりました。 #27481
  • session.setPermissionCheckHandler(handler) で、handler の第一引数である webContentsnull になることがあるように変更しました。 #19903

これらの変更と将来の変更の詳細については、予定されている破壊的な変更 のページを参照してください。

API の変更

  • BrowserWindowroundedCorners オプションを追加しました。 #27572
  • セッション固有のデータに対するディスク上のパスを取得するために新しく session.storagePath API を追加しました。28866
  • コンテキストブリッジで DOM 要素を渡す機能を追加しました。 #26776
  • サンドボックス化したレンダラーに process.uptime() を追加しました。 #26684
  • context-menu イベントの一部として発生する引数に不足していたフィールドを追加しました。#26788
  • Manifest V3 拡張機能のサービスワーカーの登録に対応しました。
  • ServiceWorker に 'registration-completed' イベントを追加しました。 #27562

削除/非推奨となった変更

以下の API は削除されたか非推奨になりました。

  • WebContentsnew-window イベントを非推奨にしました。 これは webContents.setWindowOpenHandler() に置き換えられます。

  • 非推奨だった shell.moveItemToTrash() を削除しました. #26723

  • 非推奨となっていた以下の BrowserWindow 拡張機能 API を削除しました。

    • BrowserWindow.addExtension(path)
    • BrowserWindow.addDevToolsExtension(path)
    • BrowserWindow.removeExtension(name)
    • BrowserWindow.removeDevToolsExtension(name)
    • BrowserWindow.getExtensions()
    • BrowserWindow.getDevToolsExtensions()

    代わりに以下の session API を使用してください。

    • ses.loadExtension(path)
    • ses.removeExtension(extension_id)
    • ses.getAllExtensions()
  • 以下の systemPreferences のメソッドは非推奨になりました。

    • systemPreferences.isDarkMode()
    • systemPreferences.isInvertedColorScheme()
    • systemPreferences.isHighContrastColorScheme()

    代わりに、次の nativeTheme プロパティを使用します。

    • nativeTheme.shouldUseDarkColors
    • nativeTheme.shouldUseInvertedColorScheme
    • nativeTheme.shouldUseHighContrastColors

10.x.y サポート終了

Electron 10.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では約四半期ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。 仮 14.0.0 スケジュール では、Electron 14.0 開発ライフサイクルの主要な日付を示してあります。 また、Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照 してください。

今後のバージョンの Electron で予定されている破壊的な変更の詳細については、予定されている破壊的な変更のドキュメントを参照してください

Electron 12.0.0

· 読むのにかかる時間 1 分

Electron 12.0.0 がリリースされました! これには Chromium 89、V8 8.9、Node.js 14.16 へのアップグレードが含まれています。 remote モジュールの変更、contextIsolation の新しい既定値、新しい webFrameMain API の追加、一般的な改善を行いました。 詳しくは以下をご覧ください!


Electron チームは、Electron 12.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

注目すべき変更

累積的変更

注目の機能

  • ContextBridge の exposeInMainWorld メソッドが、非オブジェクトの API を公開できるようになりました。 #26834
  • Node 12 から Node 14 へアップグレードしました。 #23249
  • メインプロセスから WebContents インスタンスのサブフレームにアクセスするため、新しく webFrameMain API を追加しました。 #25464
  • contextIsolationworldSafeExecuteJavaScript の既定値が true になりました。 #27949 #27502

新機能と変更の完全なリストは、12.0.0 リリースノート を参照してください。

破壊的変更

これらの変更と将来の変更の詳細については、予定されている破壊的な変更 のページを参照してください。

API の変更

  • webFrameMain API の追加: webFrameMain モジュールは、既存の WebContents インスタンス間を横断したフレーム探索に利用できます。 これはメインプロセスにおける既存の webFrame API と等価なものです。 この新しい API の詳細については、こちらドキュメント を参照してください。
  • app API の変更:
    • ローカライズされない serviceName'child-process-gone' / app.getAppMetrics() に追加しました。 #25975
    • Apple シリコン上の Rosetta で動作していることを検出する app.runningUnderRosettaTranslation プロパティを新たに追加しました。 #26444
    • render-process-gone の詳細に exitCode を追加しました (app と webContents)。 #27677
  • BrowserWindow API の変更:
    • BrowserWindow.isTabletMode() API を追加しました。 #25209
    • resized (Windows/macOS) と moved (Windows) イベントを BrowserWindow に追加しました。 #26216
    • システムコンテキストメニューの抑制とオーバーライドができる system-context-menu イベントを追加しました。 #25795
    • BrowserView を手前に移動できる win.setTopBrowserView() を追加しました。 #27713
    • webPreferences.preferredSizeMode を追加しました。これにより document の最小サイズに応じてビューのサイズを変更できます。 #25874
  • contextBridge API の変更:
    • ContextBridge の exposeInMainWorld メソッドが、非オブジェクトの API を公開できるようにしました。 #26834
  • display API の変更:
    • Display オブジェクトに displayFrequency プロパティを追加し、Windows でのリフレッシュレートに関する情報を取得できるようにしました。 #26472
  • extensions API の変更:
    • いくつかの chrome.management API のサポートを追加しました。 #25098
  • MenuItem API の変更:
    • macOS 共有メニュー表示のサポートを追加しました。 #25629
  • net API の変更:
    • net.request() に新しく credentials オプションを追加しました。 #25284
    • 現在インターネットに接続しているかどうかを検出する net.online を追加しました。 #21004
  • powerMonitor API の変更:
    • powerMonitor.onBatteryPower を追加しました。 #26494
    • macOS 上での powerMonitor に高速なユーザー切り替えイベントを追加しました。 #25321
  • session API の変更:
    • ses.loadExtension() API に allowFileAccess オプションを追加しました。 #27702
    • session.setPermissionRequestHandler のために display-capture API を追加しました。 #27696
    • session.setSSLConfigdisabledCipherSuites オプションを追加しました。 #25818
    • extension-loadedextension-unloadedextension-ready イベントを session に追加しました。 #25385
    • SSL の構成ができるように session.setSSLConfig() を追加しました。 #25461
    • session.setProxy() のモードへ directauto_detectsystem のいずれかを明示的に指定するサポートを追加しました。 #24937
    • Serial API サポートを追加しました。 #25237
    • スペルチェッカーを有効/無効にする API を追加しました。 #26276
  • shell API の変更:
    • 同期 API の shell.moveItemToTrash() に代わり、新しく非同期のshell.trashItem() API を追加しました。 #25114
  • webContents API の変更:
    • レンダラーのクラッシュのデバッグに役立つよう、コンソールに小さなコンソールヒントを追加しました。 #25317
    • webRequest ハンドラーの details オブジェクトに framewebContents のプロパティを追加しました。 #27334
    • ハングしたレンダラーの回復を支援するため、レンダラープロセスを強制的に終了させる webContents.forcefullyCrashRenderer() を追加しました。 #25580
    • レンダラーが作成した子ウィンドウ用の setWindowOpenHandler API を追加し、new-window イベントを非推奨にしました。 #24517
  • webFrame API の変更:
    • レンダラーにスペルチェックの API を追加しました。 #25060

削除/非推奨となった変更

以下の API は削除されたか非推奨になりました。

  • remote モジュールを非推奨にしました。 これは @electron/remote に置き換えられます。 #25293
  • 非推奨だった crashReporter API を削除しました。 #26709
  • パッケージアプリのデフォルトの 'ヘルプ' メニューにある Electron ウェブサイトへのリンクを削除しました。 #25831

9.x.y サポート終了

Electron 9.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では約四半期ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。 仮 13.0.0 スケジュール では、Electron 13.0 開発ライフサイクルの主要な日付を示してあります。 また、Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照 してください。

今後のバージョンの Electron で予定されている破壊的な変更の詳細については、予定されている破壊的な変更のドキュメントを参照してください

Electron 11.0.0

· 読むのにかかる時間 1 分

Electron 11.0.0 がリリースされました! これには Chromium 87、V8 8.7、Node.js 12.18.3 へのアップグレードが含まれています。 Apple Sillicon のサポート追加に、ほか一般的な改善となりました。 詳しくは以下をご覧ください!


Electron チームは、Electron 11.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 今回のリリースでは、アップグレード、修正、Apple の M1 ハードウェアの新規サポートなどが盛り込まれています。

新機能たちと共に何を作るのか、楽しみにしています! このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

注目すべき変更

累積的変更

注目の機能

  • Apple M1 に対応: 11 月 10 日、Apple は 今後のハードウェア に内蔵される新しい M1 チップを発表しました。 Electron 11 から、Intel Mac (x64) 用と Apple の次期 M1 ハードウェア (arm64) 用の別々のバージョンを頒布する予定です。 Electron アプリを Apple の M1 ハードウェア上で動作させる方法については、こちら を参照してください。 #24545
  • crashReport の引数に V8 のクラッシュメッセージと位置情報を追加しました。 #24771
  • コンテキストブリッジを介して大きめのオブジェクトを送信する際のパフォーマンスを改善しました。 #24671

新機能と変更の完全なリストは、11.0.0 リリースノート を参照してください。

破壊的変更

  • 実験的 API の削除: BrowserView.{fromId, fromWebContents, getAllViews}BrowserViewid プロパティ。 #23578

これらの変更と将来の変更の詳細については、予定されている破壊的な変更 のページを参照してください。

API の変更

  • 特定のプロトコルを扱うアプリの詳細情報を返す API app.getApplicationInfoForProtocol() を追加しました。 #24112
  • ファイルのパスと最大サムネイルサイズを指定するとファイルのプレビュー画像を返す API app.createThumbnailFromPath() を追加しました。 #24802
  • ハングしたレンダラーの回復を支援するため、レンダラープロセスを強制的に終了させる webContents.forcefullyCrashRenderer() を追加しました。 #25756

8.x.y サポート終了

Electron 8.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では約四半期ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。 仮 12.0.0 スケジュール では、Electron 12.0 開発ライフサイクルの主要な日付を示してあります。 また、Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照 してください。

今後のバージョンの Electron で予定されている破壊的な変更の詳細については、予定されている破壊的な変更のドキュメントを参照してください

remote モジュールの非推奨化作業の継続

Electron 9 から remote モジュールの削除作業を開始してきました。 Electron 14 では remote モジュール自体を削除する予定です。

この Issue から、非推奨化の全計画と詳細をご確認ください。

ネイティブ Node モジュールで Context Aware や N-API を要求するようにする最終段階 (Electron 12 にて)

Electron 6 以降、レンダラープロセスで読み込まれる ネイティブ Node モジュール では、N-API または Context Aware のいずれかであることを要求するように下準備の作業が行われてきました。 この変更を適用することで、セキュリティの強化、パフォーマンスの高速化、保守作業の軽減が可能になります。 この計画の最終段階は、Electron 12 でレンダラープロセスの再利用を無効にする機能を削除することです。

提案のタイムラインを含む詳細は、この Issue をご参照ください。

Apple Silicon サポート

· 読むのにかかる時間 1 分

Apple Silicon ハードウェアが下半期にリリース予定です。 新ハードウェアで Electron アプリを動作させるにはどうすればよいでしょうか?


Electron 11.0.0-beta.1 のリリースに伴い、Electron チームでは Apple が下半期に出荷予定の新 Apple Silicon ハードウェア上で動作する Electron ビルドを頒布しています。 npm install electron@beta で最新のベータ版を入手するか、 releases website から直接ダウンロードできます。

どのように動作するのですか?

Electron 11 では、Intel Mac と Apple Silicon Mac で別々のバージョンの Electron がリリースされます。 これに先立ち、既に darwin-x64mas-x64 の 2 つのアーティファクトがリリースされました。 後者には Mac App Store との互換性があります。 上記のアーティファクトの Apple Silicon に相当する、darwin-arm64mas-arm64 の 2 つのアーティファクトもリリースしています。

必要事項は何ですか?

x64 (Intel Mac) 用 と arm64 (Apple Silicon) 用、2 つのバージョンのアプリを頒布する必要があります。 electron-packagerelectron-rebuildelectron-forge はすでにこの arm64 アーキテクチャターゲットをサポートしていす。 これらのパッケージの最新バージョンを実行している限り、 ターゲットアーキテクチャを arm64に更新すると、アプリが完璧に動作するはずです。

将来的には、 arm64x64 アプリを単一のユニバーサルバイナリにマージできるパッケージをリリースしますが、このバイナリは_巨大になるため_、おそらくユーザーへのリリースには適していません。

更新: このパッケージは現在 @electron/universal で利用できます。 パッケージ化された x64 と arm64 の 2 つのアプリを、1 つのバイナリへ統合するために使用できます。

潜在的な問題

ネイティブモジュール

新しいアーキテクチャをターゲットにしているため、いくつかの依存関係はビルドで問題を引き起こす可能性があるため更新する必要があります。 各依存関係の最小バージョンは、以下をご参照ください。

依存関係バージョン要件
Xcode>=12.2.0
node-gyp>=7.1.0
electron-rebuild>=1.12.0
electron-packager>=15.1.0

これらの依存関係のバージョン要件のために、特定のネイティブモジュールを修正/更新しなければならない場合があるでしょう。 注意として、Xcode のアップグレードによって新しいバージョンの macOS SDK が導入されるため、ネイティブモジュールのビルドに失敗する可能性があります。

どのようにテストするのですか?

現在、Apple Silicon アプリケーションは、このブログ記事を書いている時点では市販されていない Apple Silicon ハードウェア上でしか動作しません。 開発者移行キット をお持ちの場合、そのマシン上でアプリケーションをテストできます。 さもなくば、アプリケーションの動作テストには、製品版の Apple Silicon ハードウェアのリリースを待つ必要があります。

Rosetta 2 についてはどうなるのでしょうか?

Rosetta 2 は、Apple の Rosetta 技術の最新の成果で、同社の新しい arm64 Apple Silicon ハードウェア上でも x64 Intel アプリケーションを実行できます。 x64 Electron アプリは Rosetta 2 で動作すると推測していますが、注意すべき重要な点が (ネイティブ arm64 バイナリを頒布すべきかどうかについても) いくつかあります。

  • アプリのパフォーマンスが著しく低下します。 Electron / V8 は JavaScript を JIT コンパイルしており、Rosetta の動作方式によっては、事実上 JIT を 2 回 (V8 で 1 回、Rosetta で 1 回) 実行します。
  • メモリのページサイズ増大など、Apple Sillicon の新技術の恩恵を受けられなくなります。
  • パフォーマンスが 大幅に 低下するって言いましたよね?

コミュニティDiscordサーバーとHacktoberfest

· 読むのにかかる時間 1 分

コミュニティの絆とオープンソースの1ヶ月間のお祝いのために私たちに参加してください。


Hacktoberfest と Discord のバナー

Electron コミュニティの Discord の立ち上げ

Electronの Outreach ワーキンググループ は、 公式コミュニティ Discord サーバーの立ち上げを発表することを楽しみにしています!

なぜ新しいDiscordサーバーなのか?

Atom テキスト エディタののバックボーンとして、Electron フレームワークに関するコミュニティでのディスカッションは、Atom の Slack ワークスペースの1チャネルで行われていました。 時間が経ち、2つのプロジェクトが分離していくにつれて、AtomワークスペースとElectronプロジェクトとの関連性は低下し、Slackチャンネルへのメンテナンの参加者も同様に低下しました。

これまで、招待を受け取るのに苦労したと多く人からの報告を受けました。コアメンテナンス担当者のほとんどがチャンネルを頻繁に行なっていたにもかかわらず、より広範なコミュニティをAtom Slackワークスペースにリダイレクトしていました。

この新しいサーバーは、Electron に関する最新情報を得ることができる、コミュニティの中心的な議論の場となるようにしています。

ぜひお越しください!

今のところ、サーバーのメンバーシップは数人のメンターが協力して立ち上げていますが、皆さんとお話しできることをとても楽しみにしています。 助けを求めたり、Electron の最新情報を得たり、他の開発者と交流したりできます。 サーバーにアクセスできる便利な 招待リンク をご用意しました!

Hacktoberfest 2020

大規模で長期間実行されているオープンソースプロジェクトとして、Electronはコミュニティからの貢献なしにはほとんど成功しませんでした。 コードの提出からバグレポート、ドキュメントの変更まで様々です。 だからこそ、Hacktoberfest に参加することで、あらゆるスキルレベルの開発者たちがより広いコミュニティでプロジェクトに参加できるようになることが重要だと考えています。

寄せ集め物

今年は、あなたにすべてを与えるより広いプロジェクトを持っていません。しかし、Electron JavaScript エコシステム全体に貢献する機会に焦点を当てたいと思います。

私達のさまざまリポジトリで hacktoberfest のタグのある課題をみてください。メインの electron/electron リポジトリ、electron/electronjs.org ウェブサイト、electron/fiddle、それに electron-userland/electron-forgeもあります。

P.S. 特に冒険したい方向けに、help wanted タグが付けられた Issue のバックログも用意しています。

つまづきましたか? 一緒にチャットしてみましょう!

さらに、私たちの Discord サーバーのグランドオープンが、今年最大のオープンソースソフトウェアの祭典と重なったのも偶然ではありません。 Hacktoberfest の PR に協力してもらうためにも、#hacktoberfest チャンネルをチェックしてみましょう。 見逃した方のために、招待リンクをこちらに再びご用意しました!

Electron 10.0.0

· 読むのにかかる時間 1 分

Electron 10.0.0 がリリースされました! これには Chromium 85、V8 8.5、Node.js 12.16 へのアップグレードが含まれています。 いくつかの新しい API 統合の追加と改善を行いました。 詳しくは以下をご覧ください!


Electron チームは、Electron 10.0.0 のリリース発表にワクワクしています! npm install electron@latest から npm でインストールするか、リリースウェブサイト からダウンロードできます。 このリリースには、アップグレード、修正、新機能が含まれています。

この Electron 10 リリースでは、リリースノートにも変更を加えました。 Electron 10 の新機能と、Electron 10 と過去のリリースとの間で変更された点を分かりやすくするために、Electron 10 に導入されつつ過去のリリースにも後方移植された変更点も含めるようにしました。 これにより、Electron をアップグレードする際に新機能やバグ修正を探しやすくなることを期待しています。

新機能たちと共に何を作るのか、楽しみにしています! このリリースの詳細については下に続きます。是非ご意見をお聞かせください!

注目すべき変更

累積的変更

注目の機能

  • contents.getBackgroundThrottling() メソッドと contents.backgroundThrottling プロパティを追加しました。 [#21036]
  • メインプロセスで desktopCapturer モジュールを公開しました。 #23548
  • ses.isPersistent() API を呼び出すことで、与えられた session が永続的であるかどうかをチェックできるようになりました。 #22622
  • ネットワークの IP アドレスの変更や ICE により、RTC 通話が接続できないネットワーク問題を解決しました。 (Chromium issue 1113227)。 #24998

新機能と変更の完全なリストは、10.0.0 リリースノート を参照してください。

破壊的変更

  • enableRemoteModule の既定値を false に変更しました。 #22091
    • これは remote モジュールを非推奨にしユーザーランドへ移行する計画の一部です。 この Issue を読んで経緯を知ってください。この Issue では、理由を説明し非推奨化予定のタイムラインを提案しています。
  • app.allowRendererProcessReuse の既定値を true に変更しました。 #22336 (Electron 9 でも)
    • これにより、コンテキスト未対応のネイティブモジュールがレンダラープロセスでロードされるのを防げます。
    • この Issue を読んで経緯を知ってください。この Issue では、理由を説明し非推奨化予定のタイムラインを提案しています。
  • macOS で OS のロケールが右書き言語 (アラビア語やヘブライ語など) に設定されている場合のウインドウボタンの位置を修正しました。 フレームレスウインドウのアプリは、この変化を考慮してウインドウのスタイルを作る必要があるかもしれません。 #22016

これらの変更と将来の変更の詳細については、予定されている破壊的な変更 のページを参照してください。

API の変更

  • Session: ses.isPersistent() API を呼び出すことで、与えられた session が永続的であるかどうかをチェックできるようになりました。 #22622
  • Contents: contents.getBackgroundThrottling() メソッドと contents.backgroundThrottling プロパティを追加しました。 #21036

非推奨となった API

以下の API は非推奨化または削除されました。

  • 非推奨だった netLogcurrentlyLoggingPath プロパティを削除しました。 更に、netLog.stopLogging が記録したログのパスを返さなくなりました。 #22732
  • crashReporter での非圧縮形式のクラッシュのアップロードを非推奨化しました。 #23598

7.x.y サポート終了

Electron 7.x.y はプロジェクトの サポートポリシー に則りサポート終了となりました。 開発者とアプリケーションは新しいバージョンの Electron にアップグレードすることを推奨します。

次回予告

短期的には、Chromium、Node、V8 といった Electron を構成する主要コンポーネントの開発に遅れないでチームが注力し続けるでしょう。 リリース日について約束しないように注意していますが、予定では約四半期ごとに新しいメジャーバージョンの Electron を、各コンポーネントの新しいバージョンに対してリリースします。 仮 11.0.0 スケジュール では、Electron 11.0 開発ライフサイクルの主要な日付を示してあります。 また、Electron のバージョン管理の詳細については バージョン管理のドキュメントを参照 してください。

今後のバージョンの Electron で予定されている破壊的な変更の詳細については、予定されている破壊的な変更のドキュメントを参照してください

remote モジュールの非推奨化作業の継続 (Electron 11 にて)

Electron 9 から remote モジュールを削除する作業を開始しており、このモジュール削除計画は継続しています。 Electron 11 では、Electron 10 で行ったように WeakRef を実装するためのリファクタリング作業を継続する予定です。 こちらの Issue から、非推奨化の全計画と詳細をご確認ください。

ネイティブ Node モジュールで Context Aware や N-API を要求するようにする最終段階 (Electron 12 にて)

編集: 元々、このブログ記事では Electron 11 でレンダラープロセスの再利用が無効になると記載してありました。 レンダラープロセスの再利用を無効にする機能は Electron 12 に延期されました。

Electron 6 以降、レンダラープロセスで読み込まれる ネイティブ Node モジュール では、N-API または Context Aware のいずれかであることを要求するように下準備の作業が行われてきました。 この変更を適用することで、セキュリティの強化、パフォーマンスの高速化、保守作業の軽減が可能になります。 この計画の最終段階は、Electron 12 でレンダラープロセスの再利用を無効にする機能を削除することです。 提案のタイムラインを含む詳細は、この Issue をご参照ください。

Electron が OpenJS Foundation Impact Project になる

· 読むのにかかる時間 1 分

今朝 OpenJSワールド で、Electronが OpenJS財団の インキュベーションプログラムを正式に卒業し、現在OpenJS財団インパクトプロジェクトになったことを発表しました。

Electron は 2019 年 12 月にインキュベーションに参加しました。これは、モントリオールで開催された直近の OpenJS Foundation グローバルカンファレンスで発表されました。 私たちは、Impact Project として JavaScript コミュニティでより大きな役割を果たし、OpenJS Foundation とのパートナーシップを継続できることを嬉しく思います。


詳細

財団、その使命、財団員については、[OpenJSF ウェブサイト](https://www.notion.so/Electron-joins-the-OpenJS-Foundation- d898f12480874e56abe78f29b041fb91#0801fd7e9fa340afbcdce0510ba05f8a) で見ることができます。 OpenJS 財団は、jQuery、Node.js、webpack などの多くのオープンソース JavaScript プロジェクトをホストしています。 GoDaddy、Google、IBM、Intel、Joyent、Microsoft を含む 30 の企業やエンドユーザーメンバーによってサポートされています。

Electron は、ウェブ技術を備えたクロスプラットフォームのデスクトップアプリケーションを構築するオープンソースフレームワークです。 Electron の裏方の人物とどのように連携するのかについては、ガバナンスページ を参照してください。

Electron 自体を使い始める場合は、ドキュメント をご覧ください。

Google Season of Docs

· 読むのにかかる時間 1 分

Google Season of Docs 第 2 段に参加させていただき、Electron としては大変光栄です。このイニシアティブでは、オープンソース組織のメンターとテクニカルライターがペアを組み、プロジェクトのドキュメントを改善していきます。


Season of Docs とは何ですか?

Season of Docs ロゴ

Season of Docs は、テクニカルライターとオープンソースコミュニティのコラボレーションを促進し、両者の利益に貢献するプログラムです。 オープンソースのメンテナーは、ライターのテクニカルライティングの専門知識を活用して、ドキュメントの構造と内容を改善します。テクニカルライターは、指導者の指導のもとオープンソースのコミュニティへ派遣されます。 詳細は Google の Season of Docs ウェブサイト で解説しています。

このプログラムに初めて参加した弊社では、テクニカルライター 1 名をメンターとして迎え、Electron の エコシステム作業グループ と協力しドキュメントの大部分を再構築していきます。 プロジェクト全体のタイムラインについては、こちら をご覧ください。

登録方法は何ですか?

テクニカルライターとして弊社とのコラボレーションに興味がございますか? まずは、今年のプログラムのために Google の テクニカルライターガイド を把握し、用意した 2 つの プロジェクトのアイデア草稿 をご確認ください。

Season of Docs のテクニカルライターとして採用されるには、6 月 8 日から 7 月 9 日までの期間中に Google Season of Docs のウェブサイトから応募する必要があります。

応募書類には、3 ヶ月間 Electron ドキュメントで何を成し遂げようとしているのかを詳細に記述した提案書を添付してください。 この提案書は、プロジェクトのアイデア草稿に記載した出発点のいずれかを発展させた内容か、全く新しいものにして頂いて構いません。 どこから手を付ければいいのかわかりませんか? 昨年の 受理された提案書のリスト を閲覧して、知見を得ることもできますよ。

提案書とは別に、テクニカルライターとしての経歴も審査されます。 履歴書には、テクニカルライティングのサンプル (既存のドキュメント、チュートリアル、ブログ記事など) と、加えて関連するライティング経験を強調したコピーを添付してください。

プロジェクトの提案を議論したい場合は、season-of-docs@electronjs.org までメールでお問い合わせください。そこからお話しましょう!

リファレンス