Electron i NW.js to dwa uznane frameworki do tworzenia wieloplatformowych aplikacji desktopowych przy użyciu technologii webowych. Oba łączą Chromium i Node.js, umożliwiając programistom tworzenie aplikacji za pomocą HTML, CSS, JavaScriptu oraz znanych frameworków frontendowych, takich jak React, Vue i Angular.
NW.js jest w rzeczywistości starszym frameworkiem. Projekt, początkowo znany jako node-webkit, rozpoczął się w 2011 roku, a w 2012 roku był już publicznie dostępny. Electron pojawił się w 2013 roku i początkowo był rozwijany przez GitHub na potrzeby edytora kodu Atom. Mimo późniejszego debiutu Electron ostatecznie stał się frameworkiem częściej wybieranym do popularnych aplikacji desktopowych.
Dziś Electron stanowi podstawę takich znanych aplikacji jak Visual Studio Code, Slack, Discord, Notion i Figma. Korzysta również z zaangażowania dużych firm technologicznych oraz nadzoru OpenJS Foundation. W WebCatalog wybraliśmy Electron jako podstawę naszych wieloplatformowych aplikacji desktopowych.
NW.js ma natomiast znacznie mniejszą widoczną obecność wśród czołowych aplikacji biznesowych i zwiększających produktywność. Jego dalsze wykorzystanie jest szczególnie zauważalne w branży gier, w tym w grach niezależnych i tytułach tworzonych za pomocą RPG Maker.
Jak zatem wypada porównanie obu frameworków i który z nich powinni wybrać programiści?
Electron a NW.js w skrócie
Oba frameworki pozwalają programistom tworzyć aplikacje desktopowe przy użyciu technologii webowych, ale różnią się podejściem do architektury aplikacji, integracji natywnej i bezpieczeństwa.
| Cecha | Electron | NW.js |
|---|---|---|
| Pierwsze wydanie | 2013 | 2011–2012 |
| Pierwotny twórca | GitHub | Intel Open Source Technology Center |
| Zarządzanie i ekosystem | OpenJS Foundation, przy znaczącym udziale dużych firm | Utrzymywany przez społeczność, wywodzi się z Intela |
| Silnik przeglądarki | Chromium | Chromium |
| Środowisko uruchomieniowe JavaScript | Node.js | Node.js |
| Platformy desktopowe | macOS, Windows, Linux | macOS, Windows, Linux |
| Architektura | Proces główny i procesy renderujące | Architektura Chromium z bezpośrednią integracją Node.js |
| Dostęp do Node.js | Proces główny i kontrolowana integracja w procesach renderujących | Bezpośredni dostęp ze stron aplikacji spełniających odpowiednie warunki |
| Rozmiar aplikacji | Stosunkowo duży | Stosunkowo duży |
| Wydajność | Zależy od aplikacji | Zależy od aplikacji |
| Bezpieczeństwo | Izolacja w piaskownicy, izolacja kontekstu, IPC | Konfigurowalny dostęp do Node.js i izolacja ramek |
| Popularność | Szeroko stosowany w popularnych aplikacjach desktopowych | Mniejszy ekosystem, zauważalne wykorzystanie w grach |
| Obsługa urządzeń mobilnych | Brak oficjalnego wsparcia | Brak oficjalnego wsparcia |
Najważniejsze różnice nie dotyczą wydajności ani rozmiaru aplikacji. Oba frameworki dołączają Chromium i Node.js, więc ich wymagania dotyczące zasobów są zasadniczo porównywalne. Główne różnice dotyczą natomiast architektury, granic bezpieczeństwa, narzędzi programistycznych i wsparcia ekosystemu.
Historia: NW.js był pierwszy, ale Electron stał się popularniejszy
NW.js był jednym z pierwszych projektów pokazujących, że programiści mogą połączyć Node.js z technologiami przeglądarkowymi, aby tworzyć aplikacje desktopowe. Początkowo nosił nazwę node-webkit i powstał w Intel Open Source Technology Center. Prace nad nim rozpoczęły się w 2011 roku, a publiczne wydania pojawiły się w 2012 roku.
Jego główna idea była prosta: umożliwić kodowi JavaScript działającemu w środowisku podobnym do przeglądarki bezpośredni dostęp do modułów Node.js. Pozwalało to tworzyć aplikacje desktopowe przy użyciu znanych technologii webowych bez budowania tradycyjnego interfejsu natywnego.
Electron pojawił się w 2013 roku pod nazwą Atom Shell. GitHub opracował go na potrzeby swojego edytora kodu Atom, którego publiczna wersja beta ukazała się w 2014 roku. Electron został zaprojektowany jako alternatywa dla dostępnych wówczas frameworków desktopowych opartych na technologiach webowych, w tym node-webkit i Chromium Embedded Framework.
Choć oba frameworki miały ułatwić programistom webowym tworzenie aplikacji desktopowych, Electron przyjął inną architekturę, oddzielającą funkcje na poziomie aplikacji od treści internetowych. Podejście to stawało się coraz atrakcyjniejsze w miarę tworzenia przez programistów bardziej złożonych aplikacji.
Electron zyskał następnie popularność wśród startupów i dużych firm technologicznych. GitHub, Slack, Microsoft i inne organizacje wnosiły wkład w jego rozwój i ekosystem. W 2019 roku Electron dołączył do OpenJS Foundation, przechodząc spod kontroli GitHuba pod opiekę neutralnej fundacji open source.
Dziś Electron działa w ramach ugruntowanego modelu zarządzania z grupami roboczymi zajmującymi się bezpieczeństwem, wydaniami, interfejsami API, aktualizacjami Chromium i Node.js oraz innymi obszarami. W jego utrzymaniu i zarządzaniu uczestniczyli inżynierowie związani z takimi organizacjami jak Microsoft i Slack.
NW.js również ma korzenie korporacyjne, ponieważ powstał w Intelu. Jego obecny ekosystem jest jednak mniejszy, a widoczny udział dużych producentów oprogramowania desktopowego nie jest równie szeroki.
Ta historia pokazuje ważną różnicę: pierwszeństwo nie gwarantuje długoterminowej dominacji. NW.js pomógł ugruntować koncepcję tworzenia aplikacji desktopowych z wykorzystaniem Chromium i Node.js, ale to Electron przyciągnął szerszy ekosystem programistów, opiekunów projektu i użytkowników komercyjnych.
Więcej informacji można znaleźć w podsumowaniu 10 lat Electrona, informacji o dołączeniu Electrona do OpenJS Foundation oraz historii projektu node-webkit.
Architektura: proces główny a bezpośrednia integracja Node.js
Electron korzysta z wieloprocesowej architektury odziedziczonej po Chromium. Każda aplikacja Electron ma proces główny odpowiedzialny za zarządzanie oknami, zdarzeniami cyklu życia aplikacji, integracjami z systemem operacyjnym i funkcjami wymagającymi podwyższonych uprawnień. Treści internetowe działają w osobnych procesach renderujących, które komunikują się z procesem głównym za pomocą komunikacji międzyprocesowej (IPC).
Tworzy to rozdział między logiką aplikacji a kodem interfejsu użytkownika. Proces renderujący zwykle zachowuje się jak tradycyjne środowisko przeglądarkowe, podczas gdy proces główny obsługuje operacje wymagające dostępu do Node.js lub natywnych interfejsów API. Electron udostępnia również skrypty preload i interfejs API contextBridge, dzięki którym programiści mogą udostępniać procesowi renderującemu wybrane funkcje bez przyznawania nieograniczonego dostępu do Node.js.
NW.js stosuje inne podejście. Został zaprojektowany tak, aby funkcje Node.js były dostępne bezpośrednio w aplikacjach webowych. Na stronie aplikacji spełniającej odpowiednie warunki programiści mogą korzystać z modułów Node.js za pomocą znanych interfejsów API JavaScript, bez tworzenia osobnego interfejsu IPC dla każdej operacji.
Na przykład lokalnie spakowana aplikacja NW.js może korzystać z Node.js bezpośrednio ze skryptu działającego na jej stronie:
const fs = require('node:fs');
const content = fs.readFileSync('notes.txt', 'utf8');
document.body.textContent = content;
Ta prostota jest jedną z charakterystycznych zalet NW.js. Programiści mogą łączyć interfejsy API przeglądarki z funkcjami Node.js bez konieczności dzielenia kodu na odrębne warstwy aplikacji. NW.js obsługuje również osobne konteksty JavaScript i tryb mieszanego kontekstu, zapewniając elastyczność we współdziałaniu funkcji przeglądarki i Node.js.
Electron zasadniczo zachęca do bardziej wyraźnego rozdzielenia tych obszarów. Aby odczytać plik z poziomu procesu renderującego, typowa bezpieczna aplikacja Electron udostępniałaby ograniczoną operację przez skrypt preload, a dostęp do systemu plików obsługiwałaby w procesie głównym.
Takie podejście wymaga dodatkowego kodu, ale wyraźniej wyznacza granicę między uprzywilejowanymi funkcjami aplikacji a treściami internetowymi. W przypadku złożonych aplikacji ten podział może ułatwić utrzymanie i zrozumienie obowiązków związanych z bezpieczeństwem.
Żadna z tych architektur nie jest uniwersalnie lepsza. NW.js może wydawać się prostszy w mniejszych aplikacjach lub projektach korzystających z bezpośredniej integracji Node.js. Electron zapewnia strukturę, która może być szczególnie przydatna wraz ze wzrostem złożoności aplikacji.
Wydajność, zużycie pamięci i rozmiar aplikacji
Ponieważ zarówno Electron, jak i NW.js dołączają Chromium i Node.js, żaden z nich nie ma nieodłącznej przewagi architektonicznej porównywalnej z różnicą rozmiaru między Electronem a Tauri.
Nawet prosta aplikacja zbudowana przy użyciu któregokolwiek z tych frameworków musi być dystrybuowana z pokaźnym środowiskiem uruchomieniowym. Oba frameworki mogą również tworzyć wiele procesów Chromium, co zwiększa zużycie pamięci, ale pomaga izolować zadania i poprawiać responsywność.
Bezpośrednia integracja Node.js ze środowiskiem przeglądarkowym w NW.js może ograniczać potrzebę używania IPC przy niektórych operacjach. W zależności od konfiguracji kontekstu kod JavaScript może bezpośrednio korzystać z funkcji Node.js, upraszczając część operacji i potencjalnie zmniejszając narzut komunikacji.
Electron oddziela operacje uprzywilejowane od kodu procesu renderującego, co wymaga użycia IPC przy przekraczaniu granic procesów. Nie oznacza to jednak, że Electron jest z natury wolniejszy. Dodatkowy narzut może być pomijalny przy zwykłych interakcjach z interfejsem użytkownika, a rozdzielenie może pomóc przenieść kosztowne zadania zaplecza poza proces renderujący.
W praktyce wydajność aplikacji zależy w dużej mierze od tego, jak programiści korzystają z Chromium, zarządzają procesami w tle, implementują renderowanie i obsługują stan aplikacji.
Aby porównanie było miarodajne, programiści powinni ocenić:
- Czas uruchamiania: jak szybko aplikacja staje się gotowa do interakcji.
- Zużycie pamięci: zarówno w stanie bezczynności, jak i przy realistycznym obciążeniu.
- Zużycie CPU: wykorzystanie zasobów podczas renderowania i operacji w tle.
- Rozmiar aplikacji: rozmiar pobieranych plików i wymagane miejsce po instalacji.
- Responsywność: zachowanie interfejsu podczas zadań intensywnie wykorzystujących zasoby.
Nie należy uznawać żadnego z frameworków za bezwzględnie szybszy bez pomiarów na reprezentatywnej aplikacji. Różnice w wersjach Chromium, konfiguracjach kompilacji, modułach natywnych i architekturze aplikacji mogą wpływać na wyniki testów wydajnościowych.
Programiści, którym zależy przede wszystkim na zmniejszeniu rozmiaru aplikacji, raczej nie uzyskają po przejściu z Electrona na NW.js tak dużych oszczędności jak przy przejściu na framework wykorzystujący systemowy komponent WebView.
Bezpieczeństwo: różne podejścia do dostępu do funkcji natywnych
Bezpieczeństwo to jedna z najważniejszych różnic między Electronem a NW.js, szczególnie w przypadku aplikacji wyświetlających zdalne witryny lub inne niezaufane treści.
Electron udostępnia kilka mechanizmów bezpieczeństwa, w tym piaskownicę Chromium, izolację kontekstu i możliwość wyłączenia integracji Node.js w procesach renderujących. Współczesne wersje Electrona domyślnie włączają ważne zabezpieczenia, a dokumentacja bezpieczeństwa projektu zdecydowanie zaleca oddzielanie uprzywilejowanych natywnych interfejsów API od treści zdalnych.
NW.js umożliwia bardziej bezpośredni dostęp do Node.js ze stron aplikacji spełniających odpowiednie warunki, co może upraszczać tworzenie oprogramowania, ale wymaga też starannego rozważenia, które treści otrzymują te uprawnienia.
NW.js rozróżnia zwykłe ramki i ramki z włączonym dostępem do Node.js. Obsługuje też ustawienia takie jak node-remote, które kontrolują, jakie zdalne adresy URL mogą korzystać z funkcji Node.js. Jego komponent webview może wyświetlać zewnętrzne treści w osobnym procesie, bez automatycznego nadawania im uprawnień aplikacji.
| Kwestia bezpieczeństwa | Electron | NW.js |
|---|---|---|
| Uprzywilejowany dostęp do Node.js | Głównie proces główny i kontrolowane mosty komunikacyjne | Dostępny bezpośrednio w odpowiednich kontekstach aplikacji |
| Izolacja treści zdalnych | Procesy renderujące i treści internetowe w piaskownicy | Zwykłe ramki i izolowane komponenty webview |
| Udostępnianie natywnych interfejsów API | IPC i contextBridge | Konteksty Node.js i konfigurowalny dostęp |
| Piaskownica Chromium | Obsługiwana z bezpiecznymi ustawieniami domyślnymi | Zależy od typu ramki i konfiguracji |
| Odpowiedzialność programisty | Weryfikacja IPC, nawigacji, uprawnień i udostępnionych interfejsów API | Kontrola uprzywilejowanych ramek, dostępu do Node.js i treści zdalnych |
Ani Electron, ani NW.js nie powinny być automatycznie traktowane jako bezpieczna przeglądarka ogólnego przeznaczenia. Aplikacje wyświetlające dowolne witryny zewnętrzne wymagają dodatkowych zabezpieczeń niezależnie od frameworka.
W aplikacjach opartych w całości na zaufanych treściach lokalnych bezpośrednia integracja NW.js może być wygodna. W aplikacjach wymagających silnego rozdzielenia kodu uprzywilejowanego od niezaufanych treści internetowych architektura Electrona może wyraźniej wyznaczać te granice.
Ostatecznie bezpieczeństwo zależy od projektu aplikacji, konfiguracji, zarządzania zależnościami i szybkości wdrażania aktualizacji zabezpieczeń przez programistów.
Popularność: Electron dominuje wśród głównych aplikacji desktopowych
Jedną z najistotniejszych różnic między Electronem a NW.js jest ich popularność wśród twórców oprogramowania desktopowego.
Choć jest młodszym projektem, Electron ugruntował swoją pozycję jako powszechnie stosowany framework do produkcyjnych aplikacji desktopowych. Jest wykorzystywany w narzędziach programistycznych, platformach komunikacyjnych, oprogramowaniu zwiększającym produktywność, aplikacjach projektowych i narzędziach biznesowych.
Do znanych przykładów należą:
| Firma | Aplikacja oparta na Electronie |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| GitHub | GitHub Desktop |
| Signal | Signal Desktop |
| Postman | Postman |
Produkty te pokazują, że Electron może stanowić podstawę zaawansowanych aplikacji desktopowych używanych przez miliony osób. Jego popularność przyczyniła się również do powstania rozbudowanego ekosystemu bibliotek, dokumentacji, narzędzi do debugowania i rozwiązań do pakowania aplikacji.
Kolejną zaletą jest udział firm. Electron został pierwotnie opracowany przez GitHub, a później przyciągnął współtwórców wśród inżynierów dużych firm technologicznych. Zarządzanie przez OpenJS Foundation zapewnia strukturę organizacyjną wspierającą współpracę, utrzymanie bezpieczeństwa, zarządzanie wydaniami i długoterminowy rozwój.
Nie oznacza to, że każda firma korzystająca z Electrona bezpośrednio uczestniczy w rozwoju frameworka, ani nie gwarantuje, że Electron zawsze będzie lepiej utrzymywany. Jednak szeroko stosowany framework z różnorodną grupą komercyjnych interesariuszy może korzystać ze wspólnych inwestycji inżynieryjnych i doświadczeń z rzeczywistych wdrożeń produkcyjnych.
NW.js ma inny profil wykorzystania. Choć służył do tworzenia aplikacji desktopowych, stosunkowo niewiele znanych współczesnych aplikacji biznesowych lub zwiększających produktywność publicznie wskazuje NW.js jako swój framework. Wiele aplikacji tradycyjnie wymienianych w zestawieniach NW.js to starsze projekty, przez co takie listy są mniej przydatne do oceny jego obecnej popularności.
Nie oznacza to, że NW.js został porzucony lub nie jest używany. Nadal otrzymuje wydania zawierające zaktualizowane wersje Chromium i Node.js. Jego widoczny ekosystem w obszarze popularnego oprogramowania desktopowego jest jednak znacznie mniejszy niż ekosystem Electrona.
Dla programistów wybierających framework do nowej aplikacji komercyjnej ta różnica ma znaczenie. Większy ekosystem zwykle ułatwia znajdowanie gotowych rozwiązań, rekrutowanie programistów z odpowiednim doświadczeniem i rozwiązywanie problemów produkcyjnych.
Popularność Electrona nie czyni go technicznie lepszym pod każdym względem, ale jego szersze wykorzystanie i udział firm stanowią praktyczne zalety, których nie należy pomijać.
Więcej przykładów można znaleźć w oficjalnym katalogu aplikacji Electron.
Gdzie NW.js wciąż jest popularny: gry niezależne
Choć NW.js nie jest szeroko reprezentowany wśród najważniejszych współczesnych aplikacji zwiększających produktywność, nadal ma zauważalną obecność w tworzeniu gier, szczególnie wśród niezależnych deweloperów.
Jednym z powodów jest integracja z narzędziami do tworzenia gier, takimi jak RPG Maker MV. Gry stworzone w RPG Maker MV mogą używać NW.js jako desktopowego środowiska uruchomieniowego, co pozwala grom opartym na HTML5 i JavaScripcie działać jako samodzielne aplikacje.
Oznacza to, że deweloperzy mogą korzystać z NW.js pośrednio za pośrednictwem silnika gry, zamiast wybierać go jako framework desktopowy ogólnego przeznaczenia.
Istnieją również niezależne dowody na to, że NW.js nadal pojawia się w nowo wydawanych grach. SteamDB śledzi gry korzystające z NW.js, automatycznie analizując sygnatury technologii w dystrybuowanych plikach. Baza obejmuje gry wydane w latach 2025 i 2026, dostarczając dowodów dalszego wykorzystania bez polegania wyłącznie na potencjalnie nieaktualnych katalogach aplikacji.
Przykłady gier powiązanych z NW.js:
| Gra | Gatunek | Premiera na Steam |
|---|---|---|
| Look Outside | RPG z elementami horroru | marzec 2025 |
| OMORI | RPG | grudzień 2020 |
| CrossCode | RPG akcji | wrzesień 2018 |
| Fear & Hunger | RPG z elementami horroru | grudzień 2018 |
| Ib | Przygodowa gra grozy | kwiecień 2022 |
| Saihate Station | Gra przygodowa | marzec 2025 |
| Sheepy: A Short Adventure | Gra platformowa | luty 2024 |
Źródło: wykrywanie technologii NW.js przez SteamDB.
SteamDB identyfikuje technologie automatycznie na podstawie plików gier, więc poszczególne wykrycia mogą być błędne lub dotyczyć dołączonej zależności, a nie środowiska uruchomieniowego świadomie wybranego przez dewelopera. Obecność NW.js nie wskazuje też, z której wersji frameworka korzysta gra ani czy jej twórca aktywnie ją utrzymuje.
Niemniej przykłady te pokazują, że NW.js pozostaje częścią współczesnego ekosystemu tworzenia gier.
Tworzy to interesującą różnicę między oboma frameworkami. Electron jest bardzo widoczny w popularnych aplikacjach desktopowych, zwłaszcza w narzędziach do zwiększania produktywności i programowania. NW.js ma mniejszą obecność w tych kategoriach, ale nadal pojawia się w grach niezależnych.
Dla programistów tworzących oprogramowanie biznesowe, narzędzia komunikacyjne lub złożone aplikacje zwiększające produktywność ekosystem Electrona może być bardziej przydatny. Dla twórców pracujących z RPG Maker lub utrzymujących gry oparte na NW.js starszy framework pozostaje sprawdzonym i praktycznym wyborem.
Wygoda pracy programisty, narzędzia i długoterminowe utrzymanie
Oba frameworki obsługują nowoczesne technologie frontendowe i pakiety Node.js, dzięki czemu są przystępne dla programistów znających tworzenie aplikacji webowych. Electron ma jednak znacznie większy ekosystem skoncentrowany na oprogramowaniu desktopowym ogólnego przeznaczenia.
NW.js oferuje stosunkowo prosty model tworzenia aplikacji. Prostą aplikację można zdefiniować za pomocą manifestu package.json i pliku HTML jako punktu wejścia. Programiści mogą uzyskiwać bezpośredni dostęp do modułów Node.js ze stron aplikacji spełniających odpowiednie warunki i korzystać z interfejsów API NW.js do zarządzania oknami, menu, zasobnikiem systemowym i innymi funkcjami desktopowymi.
Electron zwykle wymaga na początku bardziej rozbudowanej struktury. Programiści tworzą punkt wejścia procesu głównego, konfigurują okna aplikacji i zarządzają komunikacją między procesem głównym a procesami renderującymi. W małych aplikacjach może to wydawać się bardziej skomplikowane, ale zachęca też do organizowania funkcji aplikacji w odrębne warstwy.
Electron korzysta z uznanych narzędzi, takich jak Electron Forge i electron-builder, które zapewniają rozwiązania do pakowania, podpisywania, dystrybucji i aktualizowania aplikacji. Jego szerokie wykorzystanie oznacza również, że programiści mogą znaleźć więcej przykładów i dyskusji społeczności dotyczących zaawansowanych problemów tworzenia aplikacji desktopowych.
NW.js udostępnia narzędzia do pakowania, takie jak nw-builder, i obsługuje pakowanie ręczne. Udostępnia też interfejsy API wywodzące się z architektury aplikacji i rozszerzeń Chromium, co może być atrakcyjne dla projektów, które już z nich korzystają.
Oba frameworki wymagają od programistów uwzględniania różnic między systemami operacyjnymi, podpisywania kodu, zgodności modułów natywnych i aktualizacji aplikacji. Żaden nie eliminuje złożoności dystrybucji produkcyjnego oprogramowania desktopowego.
Rozmiar i skład ekosystemu nabierają szczególnego znaczenia przy długoterminowym utrzymaniu. Zespoły tworzące aplikacje komercyjne mogą potrzebować rozwiązań do podpisywania kodu, automatycznych aktualizacji, raportowania awarii, dostępności, integracji natywnych i obsługi błędów specyficznych dla platformy.
Szersze wykorzystanie Electrona przez duże firmy programistyczne ułatwia znajdowanie sprawdzonych praktyk i rozwiązań wielokrotnego użytku dla wielu z tych wymagań. NW.js pozostaje funkcjonalnym rozwiązaniem, ale programiści mogą znaleźć mniej przykładów lub utrzymywanych integracji dotyczących specjalistycznych funkcji desktopowych.
W projekcie, który ma być utrzymywany przez wiele lat, dojrzałość ekosystemu i ciągłe inwestycje zasługują na równie dużą uwagę jak interfejsy API frameworka czy wyniki testów wydajnościowych.
Dlaczego w WebCatalog wybieramy Electron
W WebCatalog wybraliśmy Electron, ponieważ jego architektura dobrze odpowiada wymaganiom naszych produktów. WebCatalog pozwala użytkownikom przekształcać witryny w aplikacje desktopowe, niezależnie zarządzać wieloma kontami i organizować aplikacje w systemach macOS, Windows i Linux.
W przeciwieństwie do programistów tworzących tradycyjną aplikację desktopową z frontendem, nad którym mają pełną kontrolę, musimy obsługiwać witryny tworzone przez tysiące różnych programistów. Mogą one opierać się na różnych systemach uwierzytelniania, mechanizmach przechowywania danych, interfejsach API przeglądarki, funkcjach multimedialnych i złożonych aplikacjach JavaScript.
Zarówno Electron, jak i NW.js korzystają z Chromium, oferują więc podobne korzyści w zakresie zgodności silnika przeglądarki. Różnica polega dla nas na tym, jak dużą kontrolę framework zapewnia nad oknami aplikacji, sesjami przeglądarki, nawigacją, uprawnieniami i rozdzieleniem uprzywilejowanego kodu aplikacji od treści zdalnych.
Electron udostępnia dojrzały zestaw interfejsów API odpowiadających tym wymaganiom. Interfejsy BrowserWindow, webContents i session pozwalają nam zarządzać zachowaniem przeglądarki na stosunkowo niskim poziomie. Szczególnie ważne są trwałe partycje sesji, ponieważ umożliwiają użytkownikom jednoczesne utrzymywanie zalogowania na wielu kontach w tej samej witrynie bez współdzielenia plików cookie i innych danych sesji.
NW.js również obsługuje osadzone komponenty webview, zarządzanie plikami cookie i partycje pamięci, więc możliwości te nie są dostępne wyłącznie w Electronie. Jednak dedykowany proces aplikacji Electrona i jego sprawdzone interfejsy API do zarządzania przeglądarką zapewniają architekturę dobrze dopasowaną do naszych potrzeb.
Kolejną ważną kwestią jest bezpieczeństwo. Ponieważ WebCatalog wyświetla zewnętrzne witryny, nad którymi nie mamy kontroli, musimy starannie oddzielać treści zdalne od uprzywilejowanych funkcji aplikacji. Model procesów Electrona, izolacja kontekstu i mechanizmy IPC pomagają nam utrzymywać ten podział, choć nadal musimy samodzielnie wdrażać i utrzymywać odpowiednie zabezpieczenia.
Wreszcie ekosystem Electrona ułatwia tworzenie i utrzymywanie oprogramowania wieloplatformowego. Nasze aplikacje muszą działać w systemach macOS, Windows i Linux, obsługując funkcje specyficzne dla platformy, pakowanie, podpisywanie i aktualizacje. Narzędzia Electrona, dokumentacja i szerokie wykorzystanie w rzeczywistych wdrożeniach stanowią solidną podstawę tej pracy.
Cenimy również ekosystem wspierający długoterminowy rozwój Electrona. Udział dużych firm technologicznych i zarządzanie przez OpenJS Foundation dają nam większą pewność co do dostępności zasobów technicznych, utrzymania bezpieczeństwa i wsparcia społeczności w miarę rozwoju naszych produktów.
Dostrzegamy wady Electrona, zwłaszcza rozmiar aplikacji i wymagania dotyczące zasobów. Zamiast zastępować framework, nadal szukamy sposobów ograniczania zbędnego narzutu. Na przykład wdrożyliśmy klony APFS, aby zmniejszyć zużycie miejsca na dysku przez generowane aplikacje na Maca.
Nasza decyzja nie wynika z przekonania, że NW.js nie potrafi obsługiwać zaawansowanego oprogramowania. Oba frameworki oferują cenioną przez nas spójność Chromium. W przypadku WebCatalog architektura Electrona, mechanizmy bezpieczeństwa, szersze wykorzystanie w popularnych aplikacjach i ugruntowany ekosystem inżynieryjny sprawiają, że jest on lepiej dopasowany do naszych potrzeb.
Gdzie NW.js nadal ma sens
Choć Electron ma większy ekosystem, NW.js zachowuje kilka istotnych zalet, które programiści powinni wziąć pod uwagę.
Jego najbardziej charakterystyczną cechą jest możliwość bezpośredniego dostępu do Node.js z odpowiednich kontekstów przeglądarki. Dla programistów przekształcających istniejącą aplikację webową w desktopową może to być wygodny sposób dodania dostępu do systemu plików, integracji z systemem operacyjnym i innych funkcji natywnych bez projektowania osobnej warstwy komunikacyjnej.
NW.js może być dobrym wyborem, gdy:
- Tworzysz gry przy użyciu istniejącego zestawu narzędzi opartego na NW.js. Programiści korzystający z RPG Maker MV lub utrzymujący projekty zależne od NW.js mogą mieć niewiele powodów do zmiany frameworka.
- Pożądana jest bezpośrednia integracja Node.js. Aplikacja może korzystać na dostępie do funkcji Node.js bezpośrednio ze swojego zaufanego interfejsu.
- Aplikacja jest stosunkowo prosta. Mniejszy projekt może nie potrzebować tak wyraźnego rozdzielenia logiki procesu głównego i renderującego, jakie oferuje Electron.
- Projekt już korzysta z NW.js. Migracja do Electrona może przynieść niewielkie korzyści, jeśli istniejąca aplikacja jest stabilna i dobrze utrzymywana.
- Ważne są konkretne interfejsy API aplikacji Chromium. NW.js zapewnia dostęp do obsługiwanych interfejsów API Chrome, które mogą być przydatne w określonych aplikacjach.
NW.js jest również nadal aktywnie utrzymywany. Ciągłe aktualizacje Chromium pokazują, że rozwija się wraz z platformą przeglądarkową.
W przypadku programistów utrzymujących istniejącą aplikację lub grę NW.js przejście na Electron wymagałoby oceny różnic architektonicznych, zmian w pakowaniu i wymagań zgodności. Jeśli nie ma wyraźnej korzyści technicznej lub biznesowej, pozostanie przy dotychczasowym frameworku może być bardziej praktyczne.
Electron a NW.js: który wybrać?
Oba frameworki umożliwiają tworzenie wieloplatformowych aplikacji desktopowych. W nowych projektach wybór zależy w dużej mierze od tego, jak programiści chcą uporządkować kod i który ekosystem najlepiej odpowiada ich wymaganiom.
| Twój priorytet | Lepszy punkt wyjścia | Dlaczego |
|---|---|---|
| Duże, złożone aplikacje desktopowe | Electron | Sprawdzona architektura i ekosystem |
| Popularne oprogramowanie biznesowe lub zwiększające produktywność | Electron | Znacznie szersze wykorzystanie w tych kategoriach |
| Długoterminowy rozwój ekosystemu i udział firm | Electron | OpenJS Foundation i znaczący współtwórcy z branży |
| Gry tworzone za pomocą RPG Maker MV | NW.js | Sprawdzona integracja i zestaw narzędzi |
| Bezpośredni dostęp do Node.js ze stron aplikacji | NW.js | Podstawowa cecha architektury |
| Wyraźny podział między interfejsem użytkownika a kodem uprzywilejowanym | Electron | Model procesu głównego i procesów renderujących oraz IPC |
| Rozbudowane narzędzia do pakowania i dystrybucji | Electron | Dojrzały ekosystem narzędzi |
| Istniejąca aplikacja NW.js | NW.js | Uniknięcie niepotrzebnej migracji |
| Spójność Chromium na różnych platformach desktopowych | Dowolny | Oba dołączają Chromium |
| Minimalny rozmiar aplikacji | Żaden nie ma wyraźnej przewagi | Oba dołączają Chromium i Node.js |
| Zarządzanie sesjami przeglądarki i oknami | Electron | Dojrzałe, dedykowane interfejsy API |
| Szerokie zasoby społeczności i liczne przykłady | Electron | Większa popularność w głównym nurcie |
Dla większości zespołów rozpoczynających tworzenie nowej, rozbudowanej aplikacji desktopowej Electron jest lepszym wyborem domyślnym. Jego architektura, ekosystem, zalecenia dotyczące bezpieczeństwa, udział firm i szerokie wykorzystanie produkcyjne sprawiają, że jest praktycznym frameworkiem do długoterminowego rozwoju.
NW.js nadal warto rozważyć w projektach korzystających z bezpośredniej integracji Node.js, procesach tworzenia gier, które już od niego zależą, lub istniejących bazach kodu NW.js. W niektórych zastosowaniach może być prostszy, a oparcie na Chromium zapewnia szeroką zgodność z platformą webową.
Programiści powinni też pamiętać, że żaden z tych frameworków nie jest szczególnie lekki. Jeśli głównymi priorytetami są mały rozmiar aplikacji i niskie bazowe zużycie zasobów, warto rozważyć alternatywy takie jak Tauri.
Podsumowanie
Electron i NW.js mają więcej podobieństw niż różnic. Oba łączą Chromium i Node.js, aby umożliwić programistom tworzenie wieloplatformowych aplikacji desktopowych przy użyciu znanych technologii webowych. Oba obsługują nowoczesne frameworki JavaScript, natywną integrację z systemem operacyjnym i zaawansowane funkcje aplikacji desktopowych.
NW.js pojawił się pierwszy, wprowadzając własne podejście do łączenia Node.js z technologiami webowymi jeszcze przed powstaniem Electrona. Później jednak to Electron stał się częściej wybieranym frameworkiem do popularnych aplikacji desktopowych, korzystając z początkowych inwestycji GitHuba, wkładu dużych firm technologicznych i zarządzania przez OpenJS Foundation.
Wzorce ich wykorzystania wyraźnie się różnią. Electron stanowi podstawę popularnych aplikacji do pracy, komunikacji i programowania, z których korzystają miliony osób. NW.js jest mniej widoczny na tym rynku, ale nadal ma istotną obecność w grach niezależnych, w tym tytułach opartych na RPG Maker i niedawno wydanych grach.
W WebCatalog wybieramy ten sam framework co wielu dużych producentów oprogramowania desktopowego. Electron zapewnia nam spójność Chromium, możliwości zarządzania przeglądarką, architekturę bezpieczeństwa i narzędzia wieloplatformowe potrzebne do obsługi szerokiej gamy aplikacji webowych w systemach macOS, Windows i Linux.
NW.js nie jest przestarzały, a jego dalsze wykorzystanie w tworzeniu gier pokazuje, że pozostaje przydatny. Jednak dla programistów rozpoczynających nową aplikację desktopową ogólnego przeznaczenia szerszy ekosystem Electrona, sprawdzone narzędzia, udział firm i większa społeczność sprawiają, że jest on bardziej praktycznym wyborem domyślnym.
Ostatecznie lepszy wybór zależy od wymagań aplikacji, doświadczenia zespołu programistycznego i długoterminowych kosztów utrzymania oprogramowania.
