Electron і NW.js — два усталені фреймворки для створення кросплатформних настільних застосунків за допомогою вебтехнологій. Обидва поєднують Chromium і Node.js, даючи розробникам змогу створювати застосунки за допомогою HTML, CSS, JavaScript і знайомих фронтенд-фреймворків, як-от React, Vue та Angular.
Насправді NW.js — старіший фреймворк. Проєкт, спочатку відомий як node-webkit, розпочався у 2011 році й став загальнодоступним до 2012 року. Electron з’явився у 2013 році: спочатку GitHub розробляв його для свого редактора коду Atom. Попри пізнішу появу, Electron зрештою став більш поширеним фреймворком для настільних застосунків широкого вжитку.
Сьогодні на Electron працюють такі відомі застосунки, як Visual Studio Code, Slack, Discord, Notion і Figma. Його розвитку також сприяють участь великих технологічних компаній та управління через OpenJS Foundation. У WebCatalog ми обрали Electron як основу наших кросплатформних настільних застосунків.
Водночас NW.js значно менш помітний серед провідних застосунків для продуктивності та бізнесу. Його подальше використання особливо помітне в ігровій індустрії, зокрема в інді-іграх та іграх, створених за допомогою RPG Maker.
Тож як ці два фреймворки співвідносяться між собою і який із них варто обрати розробникам?
Electron і NW.js: короткий огляд
Обидва фреймворки дають розробникам змогу створювати настільні застосунки за допомогою вебтехнологій, але по-різному підходять до архітектури застосунків, нативної інтеграції та безпеки.
| Характеристика | Electron | NW.js |
|---|---|---|
| Перша поява | 2013 | 2011–2012 |
| Початковий розробник | GitHub | Intel Open Source Technology Center |
| Управління та екосистема | OpenJS Foundation за участю великих корпоративних учасників | Підтримується спільнотою, походить з Intel |
| Браузерний рушій | Chromium | Chromium |
| Середовище виконання JavaScript | Node.js | Node.js |
| Настільні платформи | macOS, Windows, Linux | macOS, Windows, Linux |
| Архітектура | Головний процес і процеси рендерингу | Архітектура Chromium із прямою інтеграцією Node.js |
| Доступ до Node.js | Головний процес і контрольована інтеграція в процесах рендерингу | Прямий доступ зі сторінок застосунку, які мають відповідні дозволи |
| Розмір застосунку | Відносно великий | Відносно великий |
| Продуктивність | Залежить від застосунку | Залежить від застосунку |
| Безпека | Ізоляція в пісочниці, ізоляція контексту, IPC | Налаштовуваний доступ до Node та ізоляція фреймів |
| Поширення | Широко використовується в настільних застосунках широкого вжитку | Менша екосистема, помітне використання в іграх |
| Підтримка мобільних платформ | Офіційної підтримки немає | Офіційної підтримки немає |
Найважливіші відмінності стосуються не продуктивності чи розміру застосунку. Обидва фреймворки постачаються разом із Chromium і Node.js, тому їхні вимоги до ресурсів загалом зіставні. Натомість основні відмінності стосуються архітектури, меж безпеки, інструментів розробника та підтримки екосистеми.
Історія: NW.js з’явився першим, але Electron став популярнішим
NW.js був одним із перших проєктів, які продемонстрували, що розробники можуть поєднувати Node.js із браузерними технологіями для створення настільних застосунків. Спочатку він називався node-webkit і виник у Intel Open Source Technology Center: розробка почалася у 2011 році, а публічні випуски з’явилися до 2012 року.
Його основна ідея була простою: дозволити JavaScript, що виконується в середовищі, подібному до браузера, безпосередньо звертатися до модулів Node.js. Це дало змогу розробляти настільні застосунки за допомогою знайомих вебтехнологій без створення традиційного нативного інтерфейсу.
Electron з’явився у 2013 році під назвою Atom Shell. GitHub розробив його для свого редактора коду Atom, публічна бета-версія якого вийшла у 2014 році. Electron задумувався як альтернатива тогочасним фреймворкам для настільних застосунків на основі вебтехнологій, зокрема node-webkit і Chromium Embedded Framework.
Хоча обидва фреймворки мали на меті зробити розробку настільних застосунків доступною для веброзробників, Electron використав іншу архітектуру, яка відокремлювала функціональність рівня застосунку від вебвмісту. Цей підхід ставав дедалі привабливішим, коли розробники почали створювати складніші застосунки.
Згодом Electron набув поширення серед стартапів і великих технологічних компаній. GitHub, Slack, Microsoft та інші організації долучилися до його розробки й розвитку екосистеми. У 2019 році Electron приєднався до OpenJS Foundation, перейшовши з власності GitHub до нейтральної фундації відкритого програмного забезпечення.
Сьогодні Electron працює за усталеною моделлю управління з робочими групами, що опікуються безпекою, випусками, API, оновленнями Chromium і Node.js та іншими напрямами. У його підтримці й управлінні брали участь інженери, пов’язані з такими організаціями, як Microsoft і Slack.
NW.js також має корпоративне походження, адже його створили в Intel. Однак його нинішня екосистема менша й не має такого самого широкого кола помітних учасників серед великих компаній — розробників настільного програмного забезпечення.
Ця історія ілюструє важливу відмінність: першість не гарантує довгострокового домінування. NW.js допоміг утвердити концепцію створення настільних застосунків за допомогою Chromium і Node.js, але Electron залучив ширшу екосистему розробників, супроводжувачів і комерційних користувачів.
Докладніше дивіться в ретроспективі 10 років Electron, матеріалі про приєднання Electron до OpenJS Foundation та історії проєкту node-webkit.
Архітектура: головні процеси та пряма інтеграція Node.js
Electron використовує багатопроцесну архітектуру, успадковану від Chromium. Кожен застосунок Electron має головний процес, відповідальний за керування вікнами, подіями життєвого циклу застосунку, інтеграціями з операційною системою та привілейованою функціональністю. Вебвміст виконується в окремих процесах рендерингу, які обмінюються даними з головним процесом через міжпроцесну взаємодію (IPC).
Це створює розмежування між логікою застосунку та кодом користувацького інтерфейсу. Процес рендерингу зазвичай поводиться як звичайне браузерне середовище, тоді як головний процес виконує операції, що потребують доступу до Node.js або нативних API. Electron також надає скрипти попереднього завантаження та API contextBridge, які дають розробникам змогу відкривати процесу рендерингу доступ до вибраних функцій, не надаючи необмеженого доступу до Node.js.
NW.js використовує інший підхід. Його створили для того, щоб зробити функціональність Node.js доступною безпосередньо у вебзастосунках. На сторінці застосунку з відповідними дозволами розробники можуть звертатися до модулів Node.js через знайомі JavaScript API, не створюючи окремого IPC-інтерфейсу для кожної операції.
Наприклад, локально упакований застосунок NW.js може використовувати Node.js безпосередньо зі скрипту, що виконується на його сторінці:
const fs = require('node:fs');
const content = fs.readFileSync('notes.txt', 'utf8');
document.body.textContent = content;
Ця простота — одна з визначальних переваг NW.js. Розробники можуть поєднувати браузерні API та функціональність Node.js без обов’язкового поділу коду на окремі шари застосунку. NW.js також підтримує окремі контексти JavaScript і режим змішаного контексту, забезпечуючи гнучкість у взаємодії браузерної функціональності та Node.js.
Electron загалом заохочує чіткіше розділення. Щоб прочитати файл із процесу рендерингу, типовий безпечний застосунок Electron надав би доступ до обмеженої операції через скрипт попереднього завантаження, а сам доступ до файлової системи виконував би в головному процесі.
Такий підхід потребує додаткового коду, але робить межу між привілейованою функціональністю застосунку та вебвмістом чіткішою. У складних застосунках це розділення може полегшити супровід і зробити обов’язки щодо безпеки зрозумілішими.
Жодна з архітектур не є кращою в усіх випадках. NW.js може здаватися простішим для невеликих застосунків або проєктів, яким корисна пряма інтеграція Node.js. Electron пропонує структуру, яка може бути особливо корисною зі зростанням складності застосунку.
Продуктивність, використання пам’яті та розмір застосунку
Оскільки і Electron, і NW.js постачаються разом із Chromium і Node.js, жоден із фреймворків не має вродженої архітектурної переваги, зіставної з різницею в розмірах між Electron і Tauri.
Навіть простий застосунок, створений за допомогою будь-якого з цих фреймворків, потребує постачання доволі великого середовища виконання. Обидва фреймворки також можуть створювати кілька процесів Chromium, що збільшує споживання пам’яті, але допомагає ізолювати робочі навантаження та покращувати швидкість відгуку.
Пряма інтеграція Node.js із браузерним середовищем у NW.js може зменшити потребу в IPC для певних операцій. Залежно від налаштувань контексту код JavaScript може безпосередньо взаємодіяти з функціональністю Node.js, спрощуючи деякі операції та потенційно зменшуючи накладні витрати на обмін даними.
Electron відокремлює привілейовані операції від коду рендерингу, що потребує IPC під час перетину меж процесів. Однак це не означає, що Electron за своєю природою повільніший. Додаткові накладні витрати можуть бути незначними для звичайної взаємодії з користувацьким інтерфейсом, а таке розділення допомагає винести ресурсоємну внутрішню обробку за межі процесу рендерингу.
На практиці продуктивність застосунку значною мірою залежить від того, як розробники використовують Chromium, керують фоновими процесами, реалізують рендеринг і працюють зі станом застосунку.
Для змістовного порівняння розробникам варто оцінювати:
- Час запуску: як швидко застосунок стає готовим до взаємодії.
- Використання пам’яті: як у стані простою, так і за реалістичних робочих навантажень.
- Використання процесора: споживання ресурсів під час рендерингу та фонових операцій.
- Розмір застосунку: розмір завантаження та вимоги до дискового простору після встановлення.
- Швидкість відгуку: наскільки добре інтерфейс реагує під час ресурсоємних завдань.
Жоден із фреймворків не варто вважати однозначно швидшим без вимірювань на репрезентативному застосунку. На результати тестів можуть впливати відмінності у версіях Chromium, конфігураціях збирання, нативних модулях та архітектурі застосунку.
Для розробників, які насамперед прагнуть зменшити розмір застосунку, перехід з Electron на NW.js навряд чи дасть таке суттєве скорочення, як перехід на фреймворк із системним WebView.
Безпека: різні підходи до нативного доступу
Безпека — одна з найважливіших відмінностей між Electron і NW.js, особливо для застосунків, що відображають віддалені вебсайти чи інший недовірений вміст.
Electron надає кілька механізмів безпеки, зокрема ізоляцію Chromium у пісочниці, ізоляцію контексту та можливість вимкнути інтеграцію Node.js у процесах рендерингу. У сучасних версіях Electron важливі засоби захисту ввімкнено за замовчуванням, а документація проєкту з безпеки наполегливо рекомендує відокремлювати привілейовані нативні API від віддаленого вмісту.
NW.js дозволяє пряміший доступ до Node.js зі сторінок застосунку з відповідними дозволами. Це може спрощувати розробку, але також вимагає ретельного вибору того, який вміст отримує такі привілеї.
NW.js розрізняє звичайні фрейми та фрейми з увімкненим Node. Він також підтримує налаштування на кшталт node-remote, щоб контролювати, які віддалені URL-адреси можуть отримувати доступ до функціональності Node.js. Його компонент webview може відображати гостьовий вміст в окремому процесі, не надаючи йому автоматично привілеїв застосунку.
| Аспект безпеки | Electron | NW.js |
|---|---|---|
| Привілейований доступ до Node.js | Переважно головний процес і контрольовані мости | Доступний безпосередньо в контекстах застосунку з відповідними дозволами |
| Ізоляція віддаленого вмісту | Процеси рендерингу та вебвміст у пісочниці | Звичайні фрейми та ізольовані webview |
| Надання доступу до нативних API | IPC і contextBridge | Контексти Node та налаштовуваний доступ |
| Ізоляція Chromium у пісочниці | Підтримується з безпечними типовими налаштуваннями | Залежить від типу фрейму та конфігурації |
| Відповідальність розробника | Перевіряти IPC, навігацію, дозволи та надані API | Контролювати привілейовані фрейми, доступ до Node та віддалений вміст |
Ні Electron, ні NW.js не слід автоматично вважати безпечним браузером загального призначення. Застосунки, що відображають довільні сторонні вебсайти, потребують додаткових засобів безпеки незалежно від фреймворку.
Для застосунків, повністю побудованих навколо довіреного локального вмісту, пряма інтеграція NW.js може бути зручною. Для застосунків, яким потрібне надійне розділення привілейованого коду та недовіреного вебвмісту, архітектура Electron може зробити ці межі чіткішими.
Зрештою безпека залежить від проєктування застосунку, конфігурації, керування залежностями та швидкості, з якою розробники встановлюють оновлення безпеки.
Поширення: Electron домінує серед настільних застосунків широкого вжитку
Одна з найсуттєвіших відмінностей між Electron і NW.js — їхнє поширення серед розробників настільного програмного забезпечення.
Попри те, що Electron — молодший проєкт, він утвердився як широко вживаний фреймворк для настільних застосунків промислового рівня. Його використовують в інструментах розробки, комунікаційних платформах, програмному забезпеченні для продуктивності, дизайнерських застосунках і бізнес-утилітах.
Ось кілька відомих прикладів:
| Компанія | Застосунок на Electron |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
Ці продукти демонструють, що Electron може бути основою складних настільних застосунків, якими користуються мільйони людей. Його поширення також сприяло появі розгалуженої екосистеми бібліотек, документації, інструментів налагодження та рішень для пакування.
Участь компаній — ще одна перевага. Спочатку Electron розроблявся GitHub, а згодом до нього почали долучатися інженери великих технологічних компаній. Управління через OpenJS Foundation забезпечує організаційну структуру для співпраці, підтримки безпеки, керування випусками та довгострокового розвитку.
Це не означає, що кожна компанія, яка використовує Electron, безпосередньо робить внесок у фреймворк, і не гарантує, що Electron завжди підтримуватиметься краще. Однак широко вживаний фреймворк із різноманітним колом комерційних зацікавлених сторін може отримувати користь від спільних інженерних інвестицій і досвіду реальної експлуатації.
NW.js має інший профіль поширення. Хоча його використовували для створення настільних застосунків, порівняно небагато відомих сучасних застосунків для продуктивності чи бізнесу публічно називають NW.js своїм фреймворком. Багато застосунків, які традиційно згадують у добірках NW.js, — це старіші проєкти, тому такі списки менш корисні для оцінювання його поточного поширення.
Це не означає, що NW.js покинутий або не використовується. Він і далі отримує випуски з оновленими версіями Chromium і Node.js. Однак у сегменті настільного програмного забезпечення широкого вжитку його видима екосистема значно менша за екосистему Electron.
Для розробників, які обирають фреймворк для нового комерційного застосунку, ця відмінність важлива. Більша екосистема зазвичай полегшує пошук готових рішень, найм розробників із відповідним досвідом і розв’язання проблем під час експлуатації.
Популярність Electron не робить його технічно кращим у всьому, але ширше поширення та участь компаній — це практичні переваги, які не варто ігнорувати.
Більше прикладів можна знайти в офіційній добірці застосунків Electron.
Де NW.js досі популярний: інді-ігри
Хоча NW.js не має широкого представлення серед провідних сучасних застосунків для продуктивності, він і далі помітно присутній у розробці ігор, особливо серед незалежних розробників.
Одна з причин — його інтеграція з інструментами розробки ігор, як-от RPG Maker MV. Ігри, створені за допомогою RPG Maker MV, можуть використовувати NW.js як настільне середовище виконання, що дає іграм на основі HTML5 і JavaScript змогу працювати як самостійні застосунки.
Це означає, що розробники можуть використовувати NW.js опосередковано через свій ігровий рушій, а не обирати його як настільний фреймворк загального призначення.
Є також незалежні свідчення того, що NW.js і далі трапляється в нових іграх. SteamDB відстежує ігри, що використовують NW.js, автоматично перевіряючи технологічні сигнатури у файлах, які постачаються з ними. Її база даних містить ігри, випущені у 2025 та 2026 роках, що свідчить про подальше використання й дає змогу не покладатися повністю на потенційно застарілі добірки застосунків.
Серед прикладів, пов’язаних із NW.js:
| Гра | Жанр | Випуск у Steam |
|---|---|---|
| Look Outside | Рольова гра жахів | Березень 2025 |
| OMORI | Рольова гра | Грудень 2020 |
| CrossCode | Екшн-RPG | Вересень 2018 |
| Fear & Hunger | Рольова гра жахів | Грудень 2018 |
| Ib | Пригодницька гра жахів | Квітень 2022 |
| Saihate Station | Пригодницька гра | Березень 2025 |
| Sheepy: A Short Adventure | Платформер | Лютий 2024 |
Джерело: виявлення технології NW.js у SteamDB.
SteamDB автоматично визначає технології за файлами гри, тому окремі результати можуть містити помилки або вказувати на включену залежність, а не на середовище виконання, свідомо обране розробником. Наявність NW.js також не встановлює, яку версію фреймворку використовує гра та чи активно розробник її підтримує.
Проте ці приклади демонструють, що NW.js залишається частиною сучасної екосистеми розробки ігор.
Це створює цікаву відмінність між двома фреймворками. Electron дуже помітний у настільних застосунках широкого вжитку, особливо в інструментах для продуктивності та розробки. NW.js менш представлений у цих категоріях, але й далі з’являється в незалежних іграх.
Для розробників бізнес-програм, комунікаційних інструментів або складних застосунків для продуктивності екосистема Electron може бути доречнішою. Для розробників, які працюють із RPG Maker або підтримують ігри, побудовані на NW.js, старіший фреймворк залишається перевіреним і практичним вибором.
Досвід розробки, інструменти та довгостроковий супровід
Обидва фреймворки підтримують сучасні фронтенд-технології та пакети Node.js, що робить їх доступними для розробників, знайомих із веброзробкою. Однак Electron має значно більшу екосистему, орієнтовану на настільне програмне забезпечення загального призначення.
NW.js пропонує відносно просту модель розробки. Простий застосунок можна визначити за допомогою маніфесту package.json і початкової HTML-сторінки. Розробники можуть безпосередньо звертатися до модулів Node.js зі сторінок застосунку з відповідними дозволами та використовувати API NW.js для керування вікнами, меню, системним треєм та іншими настільними функціями.
Electron зазвичай потребує більшої початкової структури. Розробники створюють точку входу головного процесу, налаштовують вікна застосунку та керують обміном даними між головним процесом і процесами рендерингу. Для невеликих застосунків це може здаватися складнішим, але водночас заохочує розробників організовувати функціональність застосунку в окремі шари.
Electron має перевагу завдяки усталеним інструментам, як-от Electron Forge та electron-builder, які пропонують рішення для пакування, підписування, розповсюдження й оновлення застосунків. Його широке поширення також означає, що розробники можуть знайти більше прикладів та обговорень у спільноті щодо складних питань розробки настільних застосунків.
NW.js надає інструменти пакування, як-от nw-builder, і підтримує ручне пакування. Він також відкриває доступ до API, що походять з архітектури застосунків і розширень Chromium, що може бути привабливим для проєктів, які вже використовують ці API.
Обидва фреймворки вимагають від розробників ураховувати відмінності між операційними системами, підписування коду, сумісність нативних модулів та оновлення застосунків. Жоден із них не усуває складності розповсюдження настільного програмного забезпечення промислового рівня.
Розмір і склад екосистеми стають особливо важливими для довгострокового супроводу. Командам, які створюють комерційні застосунки, можуть знадобитися рішення для підписування коду, автоматичних оновлень, звітів про аварійні завершення, доступності, нативних інтеграцій і платформозалежних помилок.
Ширше використання Electron великими програмними компаніями полегшує пошук усталених практик і повторно використовуваних рішень для багатьох із цих потреб. NW.js залишається функціонально спроможним, але розробники можуть знайти менше прикладів або підтримуваних інтеграцій для спеціалізованої настільної функціональності.
Для проєкту, який планують підтримувати багато років, зрілість екосистеми та постійні інвестиції заслуговують не меншої уваги, ніж API фреймворку чи результати тестів продуктивності.
Чому у WebCatalog ми обираємо Electron
У WebCatalog ми обрали Electron, оскільки його архітектура добре відповідає вимогам наших продуктів. WebCatalog дає користувачам змогу перетворювати вебсайти на настільні застосунки, незалежно керувати кількома обліковими записами та впорядковувати свої застосунки в macOS, Windows і Linux.
На відміну від розробників звичайного настільного застосунку з фронтендом, який вони повністю контролюють, нам потрібно підтримувати вебсайти, створені тисячами різних розробників. Ці вебсайти можуть покладатися на різні системи автентифікації, механізми зберігання даних, браузерні API, мультимедійні можливості та складні JavaScript-застосунки.
І Electron, і NW.js використовують Chromium, тож пропонують схожі переваги щодо сумісності браузерного рушія. Для нас відмінність полягає в тому, наскільки фреймворк дає змогу контролювати вікна застосунку, браузерні сеанси, навігацію, дозволи та розділення привілейованого коду застосунку й віддаленого вмісту.
Electron надає зрілий набір API для цих потреб. Його інтерфейси BrowserWindow, webContents і session дають нам змогу керувати поведінкою браузера на відносно низькому рівні. Постійні розділи сеансів особливо важливі, оскільки дають користувачам змогу одночасно залишатися в кількох облікових записах на одному вебсайті, не змішуючи їхні файли cookie та інші дані сеансів.
NW.js також підтримує вбудовані webview, керування файлами cookie та розділи сховища, тож ці можливості не є винятковими для Electron. Однак окремий процес застосунку та усталені API керування браузером у Electron забезпечують архітектуру, яка добре відповідає нашим потребам.
Безпека — ще один важливий чинник. Оскільки WebCatalog відображає сторонні вебсайти, які ми не контролюємо, нам потрібно ретельно відокремлювати віддалений вміст від привілейованої функціональності застосунку. Модель процесів Electron, ізоляція контексту та механізми IPC допомагають нам підтримувати це розділення, хоча ми й надалі маємо самостійно впроваджувати та підтримувати належні засоби безпеки.
Нарешті, екосистема Electron робить кросплатформну розробку та супровід практичнішими. Наші застосунки мають працювати в macOS, Windows і Linux із підтримкою платформозалежних функцій, пакування, підписування та оновлень. Інструменти, документація та широке використання Electron у реальних продуктах створюють міцну основу для цієї роботи.
Ми також цінуємо довгострокову екосистему розвитку Electron. Участь великих технологічних компаній та управління через OpenJS Foundation дають нам більше впевненості в доступності технічних ресурсів, підтримки безпеки та допомоги спільноти в міру розвитку наших продуктів.
Ми визнаємо недоліки Electron, особливо розмір застосунків і вимоги до ресурсів. Замість заміни фреймворку ми й далі шукаємо способи зменшити зайві накладні витрати. Наприклад, ми впровадили клони APFS, щоб зменшити використання дискового простору створеними застосунками для Mac.
Наше рішення не ґрунтується на переконанні, що NW.js не здатний бути основою складного програмного забезпечення. Обидва фреймворки забезпечують однакову поведінку Chromium, яку ми цінуємо. Для WebCatalog архітектура Electron, засоби безпеки, ширше поширення серед застосунків широкого вжитку та усталена інженерна екосистема роблять його кращим вибором.
Де NW.js досі доречний
Хоча Electron має більшу екосистему, NW.js зберігає кілька суттєвих переваг, які розробникам варто врахувати.
Його найхарактерніша особливість — можливість безпосередньо звертатися до Node.js із браузерних контекстів, що мають відповідні дозволи. Для розробників, які перетворюють наявний вебзастосунок на настільний, це може бути зручним способом додати доступ до файлової системи, інтеграції з операційною системою та інші нативні функції без проєктування окремого шару обміну даними.
NW.js може бути вдалим вибором, коли:
- Ви створюєте ігри за допомогою наявного набору інструментів на основі NW.js. Розробники, які використовують RPG Maker MV або підтримують проєкти, залежні від NW.js, можуть не мати вагомих причин змінювати фреймворк.
- Бажана пряма інтеграція Node.js. Застосунок може виграти від безпосереднього доступу до функціональності Node.js у своєму довіреному інтерфейсі.
- Застосунок відносно простий. Невеликому проєкту може не знадобитися чіткіше розділення логіки головного процесу та процесів рендерингу, яке пропонує Electron.
- Проєкт уже використовує NW.js. Перехід на Electron може дати мало користі, якщо наявний застосунок стабільний і добре підтримується.
- Важливі певні API застосунків Chromium. NW.js надає доступ до підтримуваних API Chrome, які можуть бути корисними для окремих застосунків.
NW.js також залишається активно підтримуваним. Постійні оновлення Chromium демонструють, що він і далі розвивається разом із браузерною платформою.
Для розробників, які підтримують наявний застосунок або гру на NW.js, перехід на Electron потребував би оцінювання архітектурних відмінностей, змін у пакуванні та вимог до сумісності. Якщо немає чіткої технічної чи бізнесової вигоди, збереження наявного фреймворку може бути практичнішим.
Electron чи NW.js: що обрати?
Обидва фреймворки придатні для створення кросплатформних настільних застосунків. Для нових проєктів вибір значною мірою залежить від того, як розробники хочуть структурувати код і яка екосистема найкраще відповідає їхнім вимогам.
| Ваш пріоритет | Кращий початковий вибір | Чому |
|---|---|---|
| Великі складні настільні застосунки | Electron | Усталена архітектура та екосистема |
| Програмне забезпечення для продуктивності чи бізнесу широкого вжитку | Electron | Значно ширше поширення в цих категоріях |
| Довгострокова екосистема та участь компаній | Electron | OpenJS Foundation і великі галузеві учасники |
| Ігри, створені за допомогою RPG Maker MV | NW.js | Усталена інтеграція та набір інструментів |
| Прямий доступ до Node.js зі сторінок застосунку | NW.js | Основна архітектурна особливість |
| Чітке розділення інтерфейсу та привілейованого коду | Electron | Модель головного процесу й процесів рендерингу та IPC |
| Широкий вибір інструментів пакування й розповсюдження | Electron | Зріла екосистема інструментів |
| Наявний застосунок на NW.js | NW.js | Уникнення непотрібної міграції |
| Однакова поведінка Chromium на різних настільних платформах | Будь-який | Обидва постачаються разом із Chromium |
| Мінімальний розмір застосунку | Жоден не має явної переваги | Обидва постачаються разом із Chromium і Node.js |
| Керування браузерними сеансами та вікнами | Electron | Зрілі спеціалізовані API |
| Широкий вибір ресурсів спільноти та прикладів | Electron | Більше поширення серед застосунків широкого вжитку |
Для більшості команд, які починають створювати великий новий настільний застосунок, Electron — кращий вибір за замовчуванням. Його архітектура, екосистема, рекомендації з безпеки, участь компаній і широке використання в реальних продуктах роблять його практичним фреймворком для довгострокової розробки.
NW.js і далі варто розглядати для проєктів, яким корисна пряма інтеграція Node.js, процесів розробки ігор, які вже від нього залежать, або усталених кодових баз NW.js. Для певних сценаріїв він може бути простішим, а його основа на Chromium забезпечує широку сумісність із вебплатформою.
Розробникам також варто пам’ятати, що жоден із фреймворків не є особливо легким. Якщо головні пріоритети — малий розмір застосунку та низьке базове споживання ресурсів, варто розглянути альтернативи на кшталт Tauri.
Підсумки
Electron і NW.js мають більше спільного, ніж відмінного. Обидва поєднують Chromium і Node.js, щоб розробники могли створювати кросплатформні настільні застосунки за допомогою знайомих вебтехнологій. Обидва підтримують сучасні JavaScript-фреймворки, нативну інтеграцію з операційною системою та розвинену функціональність настільних застосунків.
NW.js з’явився першим, запропонувавши свій підхід до поєднання Node.js із вебтехнологіями ще до появи Electron. Однак згодом Electron став більш поширеним фреймворком для настільних застосунків широкого вжитку завдяки початковим інвестиціям GitHub, внескам великих технологічних компаній та управлінню через OpenJS Foundation.
Характер їхнього поширення помітно відрізняється. Electron є основою популярних застосунків для продуктивності, комунікації та розробки, якими користуються мільйони людей. NW.js менш помітний на цьому ринку, але й далі відіграє суттєву роль в інді-іграх, зокрема в іграх на основі RPG Maker та нещодавно випущених проєктах.
У WebCatalog ми обираємо той самий фреймворк, що й багато великих розробників настільного програмного забезпечення. Electron дає нам однакову поведінку Chromium, можливості керування браузером, архітектуру безпеки та кросплатформні інструменти, потрібні для підтримки великого розмаїття вебзастосунків у macOS, Windows і Linux.
NW.js не застарів, а його подальше використання в розробці ігор демонструє, що він залишається корисним. Але для розробників, які починають створювати новий настільний застосунок загального призначення, ширша екосистема Electron, усталені інструменти, участь компаній і більша спільнота роблять його практичнішим вибором за замовчуванням.
Зрештою кращий вибір залежить від вимог застосунку, досвіду команди розробників і довгострокової вартості супроводу програмного забезпечення.
