Electron: Kiedy aplikacja to tak naprawdę przeglądarka w przebraniu

Przyznaję się bez bicia — zdarza mi się narzekać na aplikacje desktopowe, które po prostu działają... dziwnie. Wszystko jest technicznie na miejscu, ale coś nie gra. Tekst mikroskopijny. Okno zachowuje się jakbys było z innej planety. RAM znika w tempie godnym kopania kryptowalut. Tak, to prawdopodobnie aplikacja Electron.

Dla niewtajemniczonych: Electron to framework, który pozwala tworzyć programy desktopowe z wykorzystaniem technologii webowych — HTML, CSS i JavaScript. Obietnica jest kusząca. Twoi webdeveloperzy mogą budować aplikacje desktopowe tym samym kodem. Bez konieczności uczenia się osobnych codebase'ów dla Windows, macOS i Linuksa. Brzmi jak marzenie dla niewielkich zespołów i startupów z ograniczonym budżetem.

Problem w tym, że marketing mówi tylko połowę prawdy.

Problem z płaszczem i kapeluszem

Uwielbiam cytat jednego z programistów, który trafnie określił aplikacje Electron: przeglądarki w przebraniu, udające natywne oprogramowanie. I wiecie co? Nie myli się. Pod lśniącą powłoką desktopową kryje się w zasadzie pełna instancja przeglądarki Chromium. Pełny silnik JavaScript. Pełny silnik renderowania. I cały narzut z tym związany.

Efekt? Klient pocztowy zżerający więcej RAM niż gra wideo. Aplikacja do robienia notatek, która potrzebuje trzech sekund na uruchomienie. "Lekka" utilka siedząca w docku i konsumująca zasoby jakby wydobywała bitcoiny.

Kiedy wersja webowa wygrywa

A teraz najlepsze. W wielu przypadkach wersja webowa tej samej aplikacji działa lepiej niż jej desktopowy odpowiednik Electron. Ten sam kod, te same funkcje, ale w przeglądarce wszystko sprawia wrażenie szybszego i bardziej responsywnego.

Dlaczego? Przeglądarki mają za sobą dekady optymalizacji. Producenci walczą o wydajność każdej nowej wersji. Komponenty renderujące strony w systemie operacyjnym otrzymują aktualizacje bezpieczeństwa automatycznie. Tymczasem aplikacje Electron dostarczają własną, zbundlowaną wersję Chromiums — zamrożoną w czasie do momentu, aż developer zdecyduje się ją zaktualizować. O ile w ogóle.

To nie jest tylko teoretyczny problem. Badacze bezpieczeństwa wielokrotnie dokumentowali przypadki aplikacji Electron zawierających znane podatności w zbundlowanych komponentach Chromium. Ta przeglądarka, na której to czytasz? Prawdopodobnie zaktualizowała się trzy razy, odkąd zacząłeś czytać. Ta aplikacja Electron na twoim pulpicie? Może uruchamiać kod sprzed dwóch lat.

Podatek od użyteczności

Przejdźmy do kwestii użyteczności. Kiedy korzystasz z natywnej aplikacji na macOS czy Windows, masz pewne oczekiwania. Spodziewasz się, że Cmd+Scroll powiększy tekst. Że okna będą się płynnie zmieniać rozmiarem. Że skróty klawiszowe będą działać spójnie z innymi programami.

Aplikacje Electron często łamią te oczekiwania. Nie dlatego, że developerom nie zależy — wielu z nich naprawdę zależy. Problem w tym, że pracują w ramach frameworka, który nigdy nie był projektowany do replikowania natywnego zachowania. To jakby wymagać od ryby wspinaczki na drzewo i potem dziwić się, że jest zmęczona.

Ile razy musiałem grzebać w ustawieniach, żeby tekst w aplikacji Electron był czytelny, ciągle wracając, żeby sprawdzić, czy zmiany w ogóle zadziałały? Na webie wystarczy Ctrl+ lub gest szczypnięcia na gładziku. Ale dla niektórych desktopowych aplikacji to, cholera, zaawansowana technologia.

WebViews: kompromis, z którego nikt nie jest zadowolony

Czym zastąpić Electron? Niektórzy developerzy zwracają się ku WebViews — komponentom systemowym renderującym treści webowe z wykorzystaniem własnego silnika przeglądarki systemu operacyjnego. To bardziej efektywne niż Electron, bo silnik jest współdzielony między wszystkimi aplikacjami i aktualizowany w ramach aktualizacji systemu.

Ale WebViews mają swoje problemy. Różne systemy operacyjne używają różnych silników webowych. Twoja aplikacja może wyglądać trochę inaczej na Windows, macOS i Linuksie. Ta obietnica "pisz raz, uruchamiaj wszędzie" zaczyna się kruszyć.

Szczerze? Nie ma idealnego rozwiązania. Aplikacje natywne oferują najlepszą wydajność i user experience, ale wymagają osobnych codebase'ów dla każdej platformy. Electron oferuje wygodę разработки kosztem zużycia zasobów i bezpieczeństwa. WebViews dzielą różnicę w niezgrabny sposób.

Co powinieneś zrobić?

Jeśli jesteś programistą budującym aplikacje desktopowe, zachęcam cię do szczerzej oceny, czy Electron to właściwy wybór. Weź pod uwagę swoich użytkowników. Weź pod uwagę, że jakiś developer może waszą aplikację opisać jako "przeglądarkę w przebraniu". Weź pod uwagę, że "u mnie działa" nabiera zupełnie nowego znaczenia, kiedy wysyłasz z aplikacją całą przeglądarkę.

Jeśli jesteś użytkownikiem, nie czuj się winny za narzekanie na tę powolną aplikację Electron. Twoja frustracja jest uzasadniona. Podatek od pamięci, niespójny interfejs, tekst za mały, żeby cokolwiek przeczytać — to nie są drobne uwagi. To realne wpływy na twoją produktywność i zasługują na uwagę.

Pod koniec dnia powinniśmy budować narzędzia szanujące zarówno programistów, jak i użytkowników. Czasem to oznacza wybór wygody. Czasem to oznacza włożenie dodatkowej pracy, żeby zrobić coś porządnie. Pytanie nie brzmi, czy Electron jest dobry czy zły — tylko czy to właściwy wybór dla tego, co chcesz osiągnąć.

Metafora z płaszczem i kapeluszem jest trafna, bo chodzi o maszkaraż. Aplikacje Electron często udają coś, czym nie są. Może czas przestać udawać i zacząć budować oprogramowanie, które wie, czym chce być.