Spędź wystarczająco dużo czasu na Hacker News lub Reddicie, a w końcu natkniesz się na tę samą krytykę: Electron jest ociężały, zużywa zbyt dużo pamięci, a poważne aplikacje desktopowe powinny być natywne.
W tej krytyce jest trochę prawdy. Aplikacje oparte na Electronie zazwyczaj mają większe podstawowe zapotrzebowanie na zasoby, ponieważ zawierają Chromium i Node.js. Starannie zaprojektowana aplikacja natywna może zużywać mniej pamięci, uruchamiać się szybciej i głębiej integrować z systemem operacyjnym.
Jednak ta debata skupia się zbyt mocno na komputerze, a zbyt mało na firmie tworzącej oprogramowanie.
Dla większości użytkowników technologia stojąca za aplikacją ma niewielkie znaczenie. Liczy się to, czy aplikacja działa, czy reaguje sprawnie, czy błędy są naprawiane i czy stale pojawiają się przydatne funkcje. Dlatego dla firmy programistycznej jedną z najważniejszych cech stosu technologicznego jest coś, co rzadko pojawia się w tabelach wyników testów wydajności: jak szybko zespół może tworzyć i wydawać produkt, wyciągać wnioski i go ulepszać?
W przypadku wielu współczesnych aplikacji desktopowych Electron sprawdza się pod tym względem wyjątkowo dobrze.
Deficytowym zasobem jest czas programistów
W wyidealizowanej firmie tworzącej natywne oprogramowanie desktopowe istnieje znakomity zespół macOS, drugi zespół budujący aplikację na Windows i być może jeszcze jeden obsługujący Linuksa. Każda aplikacja jest starannie zoptymalizowana pod swoją platformę, a każdy programista dogłębnie rozumie system operacyjny, z którym pracuje.
Większość firm nie ma takiego luksusu.
Nad produktem desktopowym może pracować pięciu programistów. Może też być ich dwóch. Ci sami programiści muszą tworzyć funkcje, naprawiać błędy, poprawiać wydajność, odpowiadać klientom, utrzymywać infrastrukturę, radzić sobie ze zmianami w systemach operacyjnych i stale rozwijać produkt.
Tworzenie aplikacji natywnych utrudnia to zadanie, ponieważ macOS, Windows i Linux to rzeczywiście różne platformy. Mają różne frameworki interfejsu użytkownika, API, systemy uprawnień, zasady zarządzania cyklem życia aplikacji, instalatory, mechanizmy aktualizacji, systemy powiadomień, zarządzanie oknami, API dostępności oraz specyficzne dla danej platformy osobliwości narastające przez lata.
Electron zmienia ten rachunek. Łączy Chromium, Node.js i API desktopowe we wspólny model aplikacji dla macOS, Windows i Linuksa. Ten sam programista TypeScript może często zbudować funkcję od interfejsu po logikę aplikacji i udostępnić ją na każdej platformie desktopowej. Kod natywny pozostaje dostępny wtedy, gdy jest rzeczywiście potrzebny, ale staje się wyjątkiem, a nie fundamentem produktu. Sam projekt Electron opisuje to jako jedną ze swoich głównych zalet: jedną bazę kodu JavaScript dla wszystkich trzech głównych platform desktopowych.
Znaczenie tej różnicy narasta z biegiem lat. Jeśli każda istotna funkcja wymaga osobnych implementacji na Maca i Windows, firma wielokrotnie ponosi ten dodatkowy koszt obsługi platform: przy każdej funkcji, zmianie projektu, eksperymencie, poprawce błędu, usprawnieniu dostępności i optymalizacji wydajności.
W Electronie dużą część tej pracy wykonuje się tylko raz.
Electron stawia na szybkość iteracji
Produkty rzadko stają się świetne dlatego, że pierwsza implementacja była doskonała. Stają się świetne dzięki kolejnym iteracjom.
Zespół coś udostępnia. Klienci z tego korzystają. Zespół wyciąga wnioski. Modyfikuje funkcję. Korzysta z niej więcej osób. Ujawnia się kolejny problem. Zespół ponownie ją ulepsza.
Im krótszy cykl między pomysłem, implementacją, informacją zwrotną i ulepszeniem, tym szybciej produkt staje się lepszy.
Electron wyjątkowo dobrze skraca ten cykl, ponieważ opiera się na technologiach, z których firmy programistyczne już powszechnie korzystają: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js i npm.
Oznacza to, że firmy mogą współdzielić znacznie więcej niż kod źródłowy. Mogą współdzielić programistów, komponenty interfejsu użytkownika, narzędzia, biblioteki, infrastrukturę, metody testowania i wiedzę organizacyjną między produktami webowymi a desktopowymi.
Programista frontendu nie staje się nagle nieprzydatny tylko dlatego, że firma potrzebuje pomocy przy kliencie na Windows. Programista aplikacji desktopowych może pracować nad aplikacją webową. Programista full-stack korzystający z TypeScriptu może przechodzić między produktami wraz ze zmianą priorytetów.
Dla małej lub średniej firmy taka elastyczność może być warta znacznie więcej niż oszczędność 100 MB pamięci RAM.
Spójrz, kto faktycznie używa Electrona
Electron bywa opisywany jako droga na skróty dla firm, które nie chcą inwestować w „porządną” aplikację desktopową. Produkty zbudowane za jego pomocą sprawiają, że coraz trudniej bronić tego argumentu.
Sam projekt Electron wymienia takie produkty jak Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom i Canva. Nie są to proste narzędzia. Wiele z nich należy do najbardziej zaawansowanych i najczęściej używanych aplikacji wspierających produktywność na świecie.
Visual Studio Code jest szczególnie dobrym przykładem. Microsoft mógłby zbudować swój flagowy edytor kodu przy użyciu praktycznie dowolnej technologii Windows, a jednak VS Code korzysta z Electrona w systemach Windows, macOS i Linux. Oferuje terminale, debugowanie, serwery językowe, integrację z Gitem, zdalne środowiska programistyczne, notatniki, rozszerzenia i daleko dostosowane edytory.
Ciekawe pytanie nie brzmi, czy Microsoft mógłby zaoszczędzić pamięć, tworząc trzy osobne wersje natywne. Oczywiście, że mógłby.
Lepsze pytanie brzmi: czy VS Code rozwijałby się równie szybko, zachował tak dużą spójność między platformami i zbudował tak rozległy ekosystem, gdyby każda ważna funkcjonalność wymagała kilku osobnych implementacji?
ChatGPT i Claude pokazują różnicę w podejściu
Pouczające jest również porównanie ChatGPT i Claude.
OpenAI początkowo stworzyło dedykowaną, natywną aplikację ChatGPT na macOS. Anthropic natomiast zbudował Claude Desktop na Electronie i od początku dysponował wspólną podstawą aplikacji desktopowej dla różnych platform.
Ta różnica nabrała znaczenia wraz z rozbudową produktów. Claude Desktop mógł dodawać kolejne możliwości, takie jak integracje MCP, rozszerzenia i Claude Code, do tej samej aplikacji wieloplatformowej. Anthropic obsługuje teraz Claude Code bezpośrednio w swojej aplikacji desktopowej, w tym wiele sesji lokalnych i zdalnych.
Później OpenAI również obrało kierunek oparty na Electronie w swoich nowszych pracach nad wieloplatformową aplikacją desktopową, a Electron wymienia teraz zarówno ChatGPT, jak i Claude wśród znanych aplikacji korzystających z tej technologii.
Stwierdzenie, że sam Electron wyjaśnia różnicę w tempie rozwoju produktów, byłoby zbyt daleko idące. Znaczenie mają także wielkość zespołu, priorytety, strategia produktowa i organizacja wewnętrzna. Przewaga architektoniczna jest jednak prosta: wspólna, wieloplatformowa podstawa ułatwia udostępnianie funkcji w różnych systemach operacyjnych bez utrzymywania osobnych implementacji.
To właśnie ten rodzaj przewagi, który zyskuje na wartości wraz z rozwojem produktu desktopowego.
Evernote poznał koszt utrzymywania osobnych klientów
Evernote jest jednym z najbardziej wyrazistych historycznych przykładów tego problemu.
Przez lata Evernote utrzymywał różne aplikacje na Maca, Windows, urządzenia mobilne i do przeglądarki. Z czasem w tych produktach narastały różnice w zachowaniu i renderowaniu, przestarzałe założenia oraz problemy z synchronizacją.
W 2020 roku Evernote przebudował swoje aplikacje na Windows i Maca wokół wspólnej bazy kodu. Firma zapowiedziała, że nowa podstawa zwiększy stabilność aplikacji, umożliwi szybsze naprawianie błędów, częstsze udostępnianie funkcji i lepszą synchronizację między platformami.
Ta migracja nie była bezbolesna, a części wieloletnich użytkowników nie spodobała się początkowa utrata funkcji specyficznych dla poszczególnych platform. Jednak powód, dla którego Evernote podjął się tak kosztownego przepisania aplikacji, jest ciekawszy niż same problemy związane z migracją.
Gdy produkt ma już rozbudowany edytor, przechowywanie danych offline, wyszukiwanie, załączniki, współpracę, zadania, kalendarze i złożoną synchronizację, utrzymywanie kilku niezależnych implementacji staje się coraz droższe. Błędy zachowują się inaczej. Renderowanie się różni. Logika synchronizacji współdziała z różnymi lokalnymi architekturami. Każda istotna zmiana produktu musi zostać wprowadzona w kilku klientach.
Wspólna architektura nie sprawia, że trudne problemy znikają. Pozwala firmie rozwiązywać więcej z nich tylko raz.
Linux może być najbardziej niedocenianą zaletą Electrona
Linux jeszcze bardziej wzmacnia argumenty za Electronem.
Zapewnienie właściwej obsługi Linuksa jest trudne. W przeciwieństwie do macOS czy Windows „desktopowy Linux” nie jest jedną ściśle kontrolowaną platformą. Programiści muszą radzić sobie z różnymi dystrybucjami, formatami pakietów, środowiskami graficznymi, stosami graficznymi, bibliotekami systemowymi i protokołami wyświetlania.
Dla wielu firm programistycznych racjonalną decyzją biznesową byłaby po prostu rezygnacja z obsługi Linuksa.
Electron zmienia rachunek ekonomiczny.
Ponieważ Electron zapewnia wspólne środowisko uruchomieniowe dla macOS, Windows i Linuksa, dodanie obsługi Linuksa może być zdecydowanie łatwiejsze niż utrzymywanie osobnej natywnej implementacji dla tego systemu. To jeden z powodów, dla których użytkownicy Linuksa mają dziś dostęp do wielu ważnych aplikacji desktopowych, które dawniej mogłyby nigdy nie doczekać się oficjalnego klienta na Linuksa.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian i wiele innych narzędzi może obsługiwać Linuksa bez utrzymywania całkowicie osobnej aplikacji opartej na GTK lub Qt.
Electron przejmuje też od twórców aplikacji wiele złożonych kwestii specyficznych dla Linuksa. Dobrym przykładem jest przejście z X11 na Waylanda. Opiekunowie Electrona opisywali, jak przejście Chromium na Waylanda w praktyce pociągnęło za sobą aplikacje Electron, ograniczając ilość pracy nad stosem wyświetlania, którą każdy zespół musiałby wykonać samodzielnie.
Bez frameworków takich jak Electron wiele firm nie tworzyłoby natywnych klientów na Linuksa. Po prostu obsługiwałyby macOS i Windows, pozostawiając użytkownikom Linuksa kartę w przeglądarce.
Electron prawdopodobnie zrobił dla komercyjnego oprogramowania desktopowego na Linuksa więcej, niż się mu przypisuje.
Nawet Microsoft coraz częściej wybiera technologie webowe
Microsoft jest być może najmocniejszym kontrprzykładem dla przekonania, że poważne oprogramowanie na Windows powinno zawsze korzystać z natywnych frameworków interfejsu użytkownika tego systemu.
Microsoft kontroluje Windows. Kontroluje Win32, .NET, WinUI, WebView2 i znaczną część platformy, na której pracują programiści. Gdyby w pełni natywne tworzenie aplikacji na Windows zawsze było oczywistą odpowiedzią, Microsoft miałby najlepsze możliwe warunki, by stosować je wszędzie.
Nie robi tego.
Visual Studio Code korzysta z Electrona. Teams nadal opiera się na React, TypeScript i Chromium, nawet po zastąpieniu Electrona bardziej zoptymalizowaną warstwą hostującą opartą na WebView2. Nowy Outlook dla Windows również w dużym stopniu korzysta z technologii webowych, a Microsoft wprost opisuje tę architekturę jako sposób na zwiększenie elastyczności, szybsze dostarczanie funkcji i zapewnienie bardziej spójnego doświadczenia użytkownika.
Teams jest szczególnie pouczającym przykładem. Microsoft chciał poprawić wydajność i zmniejszyć zużycie zasobów, więc zmienił architekturę. Nie przepisał jednak interfejsu jako tradycyjnej, natywnej aplikacji Windows.
Zachował stos webowy i zoptymalizował otaczającą go architekturę.
To rozróżnienie ma znaczenie. Microsoft uznał, że warto zachować organizacyjne zalety Reacta, TypeScriptu i Chromium, nawet przy intensywnych pracach nad poprawą wydajności.
Jest tu również inna lekcja. Sam Microsoft przez lata wprowadził wiele generacji technologii aplikacyjnych dla Windows: Win32, WPF, UWP, WinUI i inne. Firma wybierająca „natywny Windows” niekoniecznie wybiera ponadczasową platformę. Często stawia na jedną generację frameworka preferowanego przez Microsoft.
Platforma webowa stała się, nieco ironicznie, jednym z bardziej stabilnych środowisk docelowych dla aplikacji.
Rekrutacja jest częścią architektury
Wybór frameworka określa również, kogo możesz zatrudnić.
Programiści JavaScript i TypeScript stanowią jedną z największych grup specjalistów w branży. Firma tworząca oprogramowanie w Electronie może rekrutować z tej grupy, zamiast potrzebować osobnych zespołów doświadczonych specjalistów od macOS, Windows i Linuksa.
Specjaliści od technologii natywnych nadal są cenni. Poważne produkty desktopowe wciąż potrzebują programistów, którzy dogłębnie rozumieją systemy operacyjne. Electron zmienia jednak liczbę potrzebnych specjalistów.
Zamiast wymagać, by większość aplikacji była tworzona przez ekspertów od poszczególnych platform, można utrzymywać stosunkowo niewielką ilość natywnego kodu integracyjnego i pozwolić większości zespołu pracować nad wspólnym produktem.
Ma to jeszcze większe znaczenie, gdy firma ma już aplikację webową. Czasem można współdzielić komponenty Reacta. Biblioteki TypeScript można wykorzystywać ponownie. Logika produktu może być przenoszona między wersją webową a desktopową. Programiści mogą zmieniać zespoły bez uczenia się zupełnie innego ekosystemu.
Rekrutacja staje się też mniej podatna na problemy kadrowe. Jeśli odejdzie jedyny programista, który dogłębnie rozumie natywnego klienta na Windows, zastąpienie jego wiedzy może być trudne. W Electronie znacznie większa część bazy kodu korzysta z technologii znanych reszcie organizacji.
Framework nie określa więc jedynie sposobu renderowania interfejsu. Wpływa na to, jak można zorganizować sam zespół programistyczny.
Natywność nie oznacza automatycznie lepszego oprogramowania
Programiści często używają słowa „natywny” niemal jako synonimu słowa „szybki”.
Tak nie jest.
Natywne API dają programistom możliwość stworzenia bardzo wydajnej aplikacji. To, czy końcowy produkt rzeczywiście taki będzie, zależy od architektury, zespołu, budżetu i ilości pracy nad optymalizacją, na jaką firma może sobie pozwolić.
Aplikacja natywna nadal może być powolna, pełna błędów, pamięciożerna, niespójna lub źle utrzymywana.
Co ważniejsze, podział ograniczonego zespołu między kilka natywnych implementacji oznacza, że na każdą z nich przypada mniej godzin pracy programistów.
Wyobraź sobie firmę, która ma sześciu programistów do pracy nad produktem desktopowym. Jedną z możliwości jest podzielenie ich między Maca i Windows, być może bez obsługi Linuksa. Inną jest skierowanie niemal całej szóstki do pracy nad jedną wspólną aplikacją Electron obsługującą wszystkie trzy platformy.
Które podejście daje firmie większe możliwości skracania czasu uruchamiania, naprawiania wycieków pamięci, dopracowywania interakcji, poprawiania dostępności, ograniczania awarii i reagowania na potrzeby użytkowników?
Nie jest oczywiste, że aplikacje natywne okażą się lepszym produktem.
Powstaje tu ciekawy paradoks: framework, który zużywa nieco więcej zasobów komputera, może pozwolić firmie zbudować lepiej zoptymalizowany produkt, ponieważ pochłania znacznie mniej zasobów programistycznych.
Electron daje kontrolę nad platformą
Electron ma też inną zaletę, którą łatwo przeoczyć: dostarcza środowisko uruchomieniowe Chromium, dla którego aplikację zbudowano i przetestowano.
Eliminuje to ważną zmienną z tworzenia oprogramowania wieloplatformowego.
Frameworki oparte na systemowych komponentach WebView mogą pozwalać na tworzenie mniejszych aplikacji, ale ceną za to jest sytuacja, w której ten sam frontend działa na WebView2 w Windows, WKWebView w macOS i WebKitGTK w Linuksie. Te silniki mają różne możliwości, błędy, harmonogramy wydań i zachowanie podczas renderowania.
Electron wybiera inny kompromis: dołącza środowisko uruchomieniowe i czyni je częścią aplikacji.
Tak, to zajmuje miejsce na dysku.
Daje jednak programistom znacznie bardziej spójne środowisko docelowe w trzech bardzo różnych systemach operacyjnych.
Spójność ma ogromną wartość z punktu widzenia pracy programistycznej.
Gdy Electron nie wystarcza, nadal można sięgnąć po kod natywny
Wybór Electrona nie oznacza rezygnacji z dostępu do natywnych możliwości systemu.
Aplikacje Electron mogą w razie potrzeby korzystać z modułów natywnych i kodu specyficznego dla danej platformy. Oznacza to, że wybór architektoniczny nie sprowadza się tak naprawdę do:
100% kodu natywnego albo 100% JavaScriptu.
Dla wielu produktów lepszy model to:
większość aplikacji współdzielona, z niewielką ilością kodu natywnego tam, gdzie system operacyjny rzeczywiście tego wymaga.
Kod natywny staje się wyjściem awaryjnym, a nie fundamentem całego produktu.
Dla wielu firm jest to znacznie lepszy sposób wykorzystania pracy programistów.
Użytkowników obchodzą produkty, nie frameworki
Istnieje niewielka grupa zaawansowanych technicznie użytkowników, którzy otwierają Monitor aktywności, zauważają kilka procesów Chromium i od razu narzekają, że aplikacja korzysta z Electrona.
Większość użytkowników tego nie robi.
Nie obchodzi ich, że Slack korzysta z Electrona. Nie obchodzi ich, że VS Code jest zbudowany przy użyciu technologii webowych. Nie wiedzą, z jakiego frameworka korzysta Claude. Liczy się dla nich to, czy oprogramowanie pomaga im wykonywać pracę.
Jeśli aplikacja uruchamia się wystarczająco szybko, sprawnie reaguje, rzadko ulega awarii i rozwiązuje problem użytkownika, technologia jej implementacji pozostaje w dużej mierze niewidoczna.
Działa to również w drugą stronę. Aplikacja natywna nie staje się automatycznie dobrym produktem tylko dlatego, że korzysta ze Swifta lub WinUI.
Oprogramowanie konkuruje na poziomie produktu, a nie frameworka.
Optymalizuj firmę, nie tylko plik binarny
Electron wiąże się z realnymi kosztami. Zajmuje więcej miejsca na dysku. Jego podstawowe zużycie pamięci jest zwykle wyższe niż w przypadku małej aplikacji natywnej. Z pewnością istnieją produkty, dla których te koszty sprawiają, że Electron jest złym wyborem.
Niewielkie narzędzie działające w pasku menu prawdopodobnie nie potrzebuje Chromium. Sterownik urządzenia z pewnością go nie potrzebuje. Gry, profesjonalne oprogramowanie audio i aplikacje wyjątkowo wrażliwe na opóźnienia mają inne wymagania. A jeśli produkt ma zawsze działać tylko w jednym systemie operacyjnym, znacznie łatwiej uzasadnić wybór technologii natywnej.
Ogromna część współczesnego oprogramowania desktopowego nie należy jednak do tych kategorii.
To złożone interfejsy połączone z usługami chmurowymi. Muszą działać w Windows i macOS, a użytkownicy coraz częściej oczekują również obsługi Linuksa. Muszą stale się rozwijać. Konkurują z produktami, które wprowadzają zmiany co tydzień. I zazwyczaj są tworzone przez firmy z ograniczoną liczbą programistów.
W przypadku takich produktów produktywność programistów jest częścią wydajności aplikacji.
Electron pozwala firmie rekrutować ze znacznie większej puli specjalistów, współdzielić programistów między aplikacjami webowymi i desktopowymi, utrzymywać jedną główną aplikację zamiast kilku, wykorzystywać ekosystem JavaScript, bardziej spójnie udostępniać funkcje w różnych systemach operacyjnych, obsługiwać Linuksa po kosztach, które w innym przypadku często trudno byłoby uzasadnić, oraz poświęcać więcej czasu programistów na ulepszanie produktu zamiast utrzymywania równoległych implementacji.
Koszt Electrona można łatwo zmierzyć w megabajtach.
Koszty alternatyw są trudniejsze do zauważenia. Przybierają postać dodatkowych programistów, powielonych implementacji, dłuższych cykli wydawniczych, błędów specyficznych dla platform, trudności rekrutacyjnych, silosów organizacyjnych, użytkowników Linuksa pozbawionych wsparcia oraz funkcji, które trafiają do wszystkich o wiele miesięcy później.
Tych kosztów nie widać w Monitorze aktywności.
Ale dla firmy tworzącej oprogramowanie mogą być one znacznie większe.
Celem tworzenia oprogramowania nie jest uzyskanie najmniejszego pliku binarnego.
Jest nim zbudowanie najlepszego produktu, jaki organizacja jest w stanie dostarczać, utrzymywać i stale ulepszać.
Dla zaskakująco dużej grupy aplikacji desktopowych Electron pozostaje jednym z najbardziej efektywnych sposobów osiągnięcia właśnie tego celu.