Tauri vs Electron: lekkie aplikacje desktopowe bez ogromnego RAM-u

Dlaczego porównanie Tauri vs Electron stało się tak ważne

Twórcy aplikacji desktopowych, którzy sięgają po technologie webowe, chcą dziś jednocześnie trzech rzeczy: szybkiego developmentu, przyzwoitej wydajności oraz rozsądnego zużycia pamięci RAM. Starcie Tauri vs Electron jest w tym kontekście naturalne – oba narzędzia obiecują prostą ścieżkę od HTML/CSS/JS do natywnej aplikacji, ale robią to w zupełnie inny sposób i z innym śladem zasobów.

Co wiemy? Electron od lat jest „domyślnym” wyborem, napędzając takie aplikacje jak VS Code, Slack czy Discord, a więc narzędzia wykorzystywane codziennie przez miliony użytkowników. Wiemy też, że stał się synonimem ciężkich aplikacji webowych na desktop – zwłaszcza w kontekście RAM-u. Z kolei Tauri wyrósł na odpowiedź środowiska Rust i części świata frontendu: jak dostarczyć podobne możliwości, ale bez pakowania pełnego Chromium do każdej aplikacji.

Czego nie wiemy? Brakuje pełnych, obiektywnych statystyk o wszystkich wdrożeniach Tauri i Electron. Nie ma jednej liczby, która powie, że Tauri zużywa „dokładnie X razy mniej pamięci”. Można natomiast przeanalizować różnice architektoniczne, typowe scenariusze i realne przykłady z produkcji, aby zbliżyć się do świadomej decyzji technologicznej.

Skąd wzięła się popularność Electron i czym odpowiada Tauri

Krótkie tło: JavaScript ląduje na pulpicie

Electron pojawił się jako odpowiedź na prostą potrzebę: wykorzystać istniejące kompetencje frontendowe do budowy aplikacji desktopowych. Programiści znający JavaScript, HTML i CSS dostali możliwość użycia tych samych narzędzi – Reacta, Vue, Angulara czy Svelte – do tworzenia pełnoprawnych aplikacji na Windows, macOS i Linux.

Model był kusząco prosty: aplikacja to z grubsza przeglądarka (Chromium) zintegrowana z Node.js, zamknięta w jednej paczce. Z punktu widzenia zespołów webowych oznaczało to minimalną zmianę środowiska: te same bundlery, ten sam ekosystem NPM, te same konwencje. To właśnie z tego powodu Electron tak szybko zdobył rynek – próg wejścia był niski, a pierwsze sukcesy (Slack, Atom, potem VS Code) dały mu kredyt zaufania.

Skutek uboczny ujawnił się dopiero w praktyce użytkowników: każda aplikacja Electron niesie ze sobą własne Chromium i własne środowisko wykonawcze. Przy kilku takich aplikacjach uruchomionych równocześnie całkowite zużycie RAM nadmuchiwało się szybciej, niż sugerowałaby to funkcjonalność oprogramowania.

Rosnące zmęczenie ciężkim Electronem

Przez lata Electronowi zarzucano głównie trzy rzeczy: duży rozmiar instalatora, wysokie zużycie pamięci i ogólną „ociężałość” w prostych zastosowaniach. Dla edytora kodu czy komunikatora grupowego wielu użytkowników było skłonnych to zaakceptować. Dla małych narzędzi – timerów, klientów API, prostych notatników – narzut Electron zaczął być dyskusyjny.

W społeczności zaczęły pojawiać się pytania: czy naprawdę potrzeba pełnego Chromium, żeby wyświetlić prosty interfejs? Czy konieczne jest pakowanie kilkudziesięciu–kilkuset megabajtów, aby zbudować aplikację, którą dałoby się napisać w natywnym toolkicie w kilka megabajtów? To właśnie w tej szczelinie pojawił się Tauri.

Narodziny Tauri jako lżejszej alternatywy

Tauri przyjął inną filozofię: wykorzystać to, co system operacyjny już ma (systemowe WebView), i dodać do tego cienką warstwę w Rust, która łączy frontend webowy z natywnymi możliwościami systemu. Zamiast bundlować Chromium, Tauri sięga po:

• WebView2 na Windows,
• WKWebView na macOS,
• webkit2gtk na Linuksie.

Dzięki temu binarka może być bardzo mała, a zużycie pamięci – w wielu scenariuszach niższe, ponieważ nie duplikuje całego silnika przeglądarki dla każdej aplikacji. Pojawia się jednak inny kompromis: backend w Rust i slightly bardziej złożona konfiguracja wymagają od zespołu nowych kompetencji, lub przynajmniej gotowości do ich zdobycia.

Realna pozycja obu narzędzi w ekosystemie

Electron, jako projekt działający od wielu lat i wspierany m.in. przez GitHub (Microsoft), ma rozbudowany ekosystem, ogromną liczbę przykładów i stabilny cykl wydawniczy. Tauri jest młodsze, ale szybko dojrzewa, a wersja 1.x przyniosła stabilne API i coraz szersze zastosowanie komercyjne.

Nie istnieje jednak jednoznaczna statystyka mówiąca, które z tych narzędzi „wygrywa”. Electron ma przewagę historyczną i wciąż jest używany przez największych graczy. Tauri rośnie w obszarze narzędzi, gdzie lekkość, mały rozmiar i bezpieczeństwo mają szczególne znaczenie. Wybór technologii staje się więc mniej kwestią mody, a bardziej odpowiedzią na konkretne pytanie: jakie ograniczenia zasobów i jakie wymagania utrzymaniowe są kluczowe dla danego projektu?

Architektura Electron: pełne Chromium kontra systemowe WebView w Tauri

Co faktycznie uruchamia się w tle?

Podstawowe pytanie techniczne brzmi: co tak naprawdę dzieje się po uruchomieniu aplikacji Electron lub Tauri? Odpowiedź określa ślad pamięci, sposób komunikacji między procesami i ogólne poczucie „lekkości”.

Electron składa się z procesu głównego (main process) oraz jednego lub wielu procesów renderera. Proces główny zarządza oknami, integracją z systemem (tray, menu, powiadomienia) i logiką aplikacji. Procesy renderera uruchamiają interfejs użytkownika w kontekście Chromium. Każde okno może mieć własny renderer, a więc potencjalnie własny proces. Do tego dochodzi zintegrowany Node.js, który daje dostęp do systemu plików, sieci czy procesów.

Tauri natomiast uruchamia natywny proces hosta (binarka w Rust, w uproszczeniu) i wykorzystuje istniejące w systemie komponenty WebView do wyświetlenia interfejsu. Logika systemowa i biznesowa znajduje się w procesie Rusta, a frontend działa w ramach WebView opartego na silniku przeglądarki dostarczanym przez OS. Liczba procesów jest zwykle niższa, a ślad pamięci ograniczony przez wykorzystanie wspólnej infrastruktury przeglądarki.

Konsekwencje pełnego Chromium w Electron

Decyzja o bundlowaniu Chromium w każdej aplikacji Electron ma kilka istotnych skutków:

• Stały narzut pamięci – pełny silnik przeglądarki startuje wraz z aplikacją, niezależnie od tego, jak proste jest UI. Obejmuje to m.in. silnik JavaScript (V8), layout, renderowanie, obsługę multimediów.
• Powielanie zasobów – jeśli użytkownik korzysta z kilku aplikacji Electron równocześnie, w pamięci mogą pracować kilka instancji Chromium, zamiast jednego współdzielonego komponentu.
• Większy rozmiar paczki – instalator musi zawierać kompletne binaria Chromium i Node.js, biblioteki natywne i kod aplikacji. Nawet prosta aplikacja osiąga dziesiątki megabajtów.

Z punktu widzenia wydajności CPU Electron nie zawsze wypada źle – wiele zależy od jakości samego kodu aplikacji. Jednak sama baza, od której startuje każdy projekt, jest cięższa niż w podejściu Tauri. Dotyczy to zwłaszcza aplikacji typu „utility”, które robią niewiele, ale są stale uruchomione w tle.

Systemowe WebView w Tauri i ich wpływ na zasoby

Tauri wykorzystuje komponenty WebView dostarczane przez system. Oznacza to m.in., że:

• na Windowsie aplikacja korzysta z Edge WebView2,
• na macOS z WKWebView opartym o Safari/WebKit,
• na Linuksie z webkit2gtk (zależnym od tego, co ma dystrybucja).

W praktyce przekłada się to na mniejszy rozmiar binarki, ponieważ Tauri nie musi bundlować pełnego silnika przeglądarki. Część logiki renderowania jest współdzielona z innymi aplikacjami na systemie korzystającymi z tych samych komponentów. Jeśli użytkownik ma już zainstalowany Edge i WebView2, Tauri używa istniejącej infrastruktury, nie duplikując jej.

Konsekwencja numer dwa to mniejszy footprint w pamięci dla prostych aplikacji: WebView nie jest pełnym, osobnym Chromium, lecz w wielu wypadkach cieńszą warstwą nad istniejącym silnikiem. W bardziej rozbudowanych aplikacjach różnica może się zmniejszać, bo głównym kosztem staje się kod frontendu, ale dla małych narzędzi przewaga Tauri pozostaje zwykle wyraźna.

IPC, bezpieczeństwo i izolacja procesów

W Electron komunikacja między procesem głównym a rendererami odbywa się przez mechanizm inter-process communication (IPC), z użyciem modułu ipcMain i ipcRenderer. Konfiguracja bezpieczeństwa (m.in. contextIsolation, nodeIntegration) decyduje o tym, czy kod frontendu może bezpośrednio wywoływać API Node.js. Niewłaściwe ustawienie tych flag bywa źródłem luk bezpieczeństwa – frontend dostaje zbyt szerokie uprawnienia.

W Tauri most pomiędzy frontendem (JS/TS) a backendem (Rust) jest od początku projektowany jako wąski i kontrolowany. Frontend wywołuje zdefiniowane komendy (tzw. commands), które po stronie Rusta mają precyzyjnie opisane argumenty i zakres działania. Po stronie Tauri istnieje też mechanizm tzw. allowlist – jawnej listy dozwolonych API, które aplikacja może wywoływać. To podejście z definicji zmniejsza powierzchnię ataku.

Z perspektywy architekta różnica jest wyraźna: Electron domyślnie daje szerokie możliwości, które trzeba ograniczać. Tauri domyślnie jest oszczędne i trzeba je otwierać na konkretne potrzeby. Ma to znaczenie zarówno dla bezpieczeństwa, jak i dla zrozumienia, gdzie faktycznie przebiega granica między „webem” a „natynem”.

Mentalny diagram przepływu komunikacji

Prosty schemat działania Electron można streścić następująco: proces główny startuje, tworzy okno z uruchomionym Chromium, ładuje aplikację webową, a następnie oddaje część sterowania frontendowi. Frontend, w zależności od konfiguracji, może bezpośrednio korzystać z Node.js lub wysyłać komunikaty IPC do procesu głównego, prosząc go o wykonanie operacji systemowych.

W Tauri logika jest odwrotna: natywny proces w Rust kontroluje aplikację, a UI w WebView jest w dużej mierze „klientem” wywołującym komendy po stronie Rusta. Frontend nie ma domyślnie bezpośredniego dostępu do systemu plików czy procesów. Wszystko przechodzi przez warstwę backendową, którą programista musi świadomie zaimplementować. W rezultacie przepływ danych jest bardziej przewidywalny, choć wymaga od zespołu większej dyscypliny projektowej.

Zużycie pamięci, CPU i rozmiar paczki – praktyczne porównanie

Proste scenariusze: „Hello world” i CRUD

Porównanie Tauri vs Electron w kontekście zużycia RAM nie powinno opierać się na jednej magicznej liczbie. Zamiast tego warto spojrzeć na typowe scenariusze:

• Minimalne „Hello world” – jedno okno, kilka komponentów UI, brak ciężkich bibliotek frontendu.
• Prosta aplikacja CRUD – formularze, lista, kilka widoków, lokalna baza (np. SQLite).
• Narzędzie w trayu – aplikacja działająca cały czas w tle, z interfejsem wyświetlanym tylko od czasu do czasu.

W pierwszym scenariuszu Tauri zwykle wypada zdecydowanie lżej: brak bundlowanego Chromium oznacza niższy startowy ślad pamięci, a rozmiar binarki może zamknąć się w kilku–kilkunastu megabajtach. Electron, nawet dla „gołego” okna, musi uruchomić pełne Chromium z Node.js, co przekłada się na zauważalny narzut.

Przy prostym CRUD-zie różnica wciąż jest widoczna, choć zaczyna rosnąć udział „własnego” kodu aplikacji i bibliotek JS/TS. Jeśli korzystasz z dużych frameworków frontendu i wielu zależności NPM, ich koszty pojawią się niezależnie od wybranego narzędzia. Tauri nadal nie musi jednak nieść ze sobą całego Chromium, co pozostaje jego przewagą.

Wpływ liczby okien, komponentów UI i bibliotek

Na zużycie pamięci wpływają nie tylko wybór Tauri vs Electron, ale także:

• liczba jednocześnie otwartych okien,
• zastosowany framework frontendu (React z dużą ilością stanu vs prosty Svelte),
• użyte biblioteki UI (ciężkie komponenty, złożone layouty),
• strategia zarządzania stanem (store’y trzymające duże struktury danych w pamięci).

Electron płaci dodatkową cenę za każdy nowy renderer: każde nowe okno może oznaczać nowy proces Lub nowe środowisko sandbox. Tauri, korzystając z systemowego WebView, również zwiększa zużycie pamięci przy wielu oknach, ale ogólny narzut bazowy może być niższy, bo część silnika przeglądarki pozostaje współdzielona.

Dobrym nawykiem w obu technologiach jest ograniczanie liczby ciężkich komponentów jednocześnie załadowanych w DOM-ie, lazy-loading widoków i bibliotek, a także świadome zarządzanie stanem – tak, aby nie trzymać w pamięci wszystkiego naraz, jeśli użytkownik korzysta tylko z fragmentu aplikacji.

Rozmiar instalatora i skład paczki

Różnice w rozmiarze paczek Tauri i Electron wynikają głównie z tego, co jest do nich dołączane. Tę zależność dobrze obrazuje prosta tabela:

Przykładowe wielkości paczek i ich źródła

Różnice w rozmiarze instalatorów są dobrze widoczne już przy prostych projektach. Dla minimalnych aplikacji często obserwuje się następujący rząd wielkości:

To nie są sztywne liczby, raczej porządek wielkości. Konkretny projekt może odbiegać w obie strony, zwłaszcza jeśli po stronie Tauri pojawią się cięższe natywne zależności (np. biblioteki kryptograficzne) albo jeśli aplikacja Electron korzysta z agresywnego usuwania zbędnych modułów.

Co jest istotne z praktycznego punktu widzenia? W przypadku aplikacji dystrybuowanych masowo (np. wewnątrz dużej organizacji) mniejszy rozmiar instalatora Tauri bywa argumentem administracyjnym: krótsze czasy pobierania, mniejsze obciążenie serwerów aktualizacji, łatwiejsza dystrybucja na łączach o gorszej przepustowości.

Różnice w zużyciu CPU przy długotrwałej pracy

Poza pamięcią coraz częściej śledzi się zachowanie aplikacji podczas wielogodzinnej pracy – zwłaszcza w tle. Tu na pierwszy plan wysuwają się dwa czynniki: GC i timer-heavy JavaScript po stronie frontendu, a także sposób obsługi idlingu przez runtime.

Electron, uruchamiając pełne Chromium z V8, dziedziczy całą maszynerię optymalizacji i zarządzania energią z nowoczesnej przeglądarki. To plus – o ile aplikacja nie blokuje głównej pętli zdarzeń ciężkimi obliczeniami. Problem pojawia się, gdy interfejs jest „zagęszczony” timerami, listenerami i różnymi schedulerami JS; nawet z pozoru bezczynna aplikacja może wtedy co chwilę wybudzać CPU.

W Tauri obraz jest podobny od strony frontendu, bo to wciąż aplikacja webowa renderowana w WebView. Różnica leży w backendzie: spora część logiki może zostać przeniesiona do Rusta i uruchamiana poza głównym wątkiem UI. Rustowa część, dobrze napisana, nie generuje dodatkowego overheadu garbage collectora i pozwala łatwiej kontrolować, kiedy coś naprawdę ma działać w tle.

W praktyce oznacza to, że:

• w Electronie duża część kosztu CPU to frontend i ewentualne wtyczki Node.js uruchamiane w tym samym procesie lub procesach powiązanych,
• w Tauri można część obliczeń przenieść do natywnych workerów w Rust, zostawiając WebView w większym „spoczynku”.

Co wiemy? Obie platformy umożliwiają budowę energooszczędnych aplikacji, ale wymagają dyscypliny po stronie kodu frontendu. Czego nie wiemy od razu? Jak konkretny projekt wykorzysta te narzędzia – różnice między dobrze napisanym Electronem a „przeciążonym” Tauri potrafią być większe niż między samymi runtime’ami.

Język i model programowania: JavaScript/TypeScript + Node vs Rust + JS

Doświadczenie typowego zespołu frontendu

Electron jest naturalnym wyborem dla zespołów, które już tworzą SPA w React, Vue czy Angularze. Model mentalny bywa prosty: „to jak przeglądarka, tylko mamy dostęp do systemu”. Cała aplikacja, od UI po większość logiki, powstaje w ekosystemie JS/TS; Node.js daje dostęp do plików, procesów i sieci, a npm/yarn pnpm dostarczają bibliotek.

Tauri stawia na rozdział: interfejs w JS/TS, logika systemowa lub „ciężka” biznesowa w Ruście. Z jednej strony to wyższy próg wejścia – Rust wymaga innego sposobu myślenia o pamięci i współbieżności. Z drugiej, zespoły otrzymują narzędzie pozwalające przenosić najbardziej wrażliwe lub kosztowne fragmenty poza świat dynamicznego JS.

Dla części zespołów dobrym kompromisem jest stopniowe podejście: najpierw wykorzystanie Tauri wyłącznie jako hosta dla frontendu, z prostymi komendami Rust (np. do operacji na plikach), a dopiero później przenoszenie większych bloków logiki po stronie natywnej.

Podział odpowiedzialności: gdzie kończy się frontend

W Electronie granica między frontendem a backendem jest płynna. Ten sam język, wspólne zależności i możliwość współdzielenia kodu zachęcają do umieszczania dużej części logiki po stronie rendererów. Efekt bywa wygodny, ale może prowadzić do rozproszenia odpowiedzialności: kawałki logiki biznesowej lądują zarówno w procesie głównym, jak i w oknach.

Tauri, poprzez jasny kontrakt „komend” Rusta wywoływanych z WebView, wymusza twardsze rozdzielenie: UI i logika prezentacji po jednej stronie, operacje systemowe i „core’owe” reguły po drugiej. Dla architektów oznacza to większą przejrzystość zależności i łatwiejsze śledzenie, które moduły faktycznie dotykają systemu.

Przykładowy scenariusz: aplikacja do zarządzania notatkami. W Electronie całość CRUD-a, szyfrowania i synchronizacji z chmurą może znaleźć się w rendererze, z kilkoma wywołaniami IPC do procesu głównego. W Tauri częściej spotyka się podejście, w którym:

• UI i walidacja formularzy pozostają w JS/TS,
• zapisywanie notatek, szyfrowanie i synchronizacja realizowane są jako komendy Rusta.

Krzywa uczenia się i narzędzia developerskie

Ekosystem Electron korzysta z dojrzałych narzędzi Node.js: debugowanie, hot-reload, integracje z bundlerami (Webpack, Vite, esbuild) są dobrze znane zespołom webowym. Testy jednostkowe i end-to-end można opierać na istniejących frameworkach: Jest, Vitest, Playwright czy Cypress (choć w trybie desktopowym wymaga to dodatkowej konfiguracji).

Tauri łączy dwa światy. Deweloper pracuje równocześnie z:

• narzędziami webowymi (Vite, bundlery, lintery JS/TS),
• toolchainem Rusta (Cargo, rustc, Clippy, Rust Analyzer).

Efekt jest taki, że diagnostyka błędów kompilacji może być bardziej „szumowa” dla zespołów nieznających Rusta. Z drugiej strony, po oswojeniu się z ekosystemem, ostrzeżenia Clippy czy system typów Rusta pomagają wychwycić klasy błędów, które w JS/TS wyszłyby dopiero na etapie runtime’u.

Testowalność i jakość kodu

Z perspektywy jakości kodu Rust oferuje przewagę w obszarach wymagających silnych gwarancji: operacje kryptograficzne, równoległe przetwarzanie danych czy praca z plikami w wielu wątkach. Typowy flow jest taki:

• logika krytyczna: Rust + testy integracyjne,
• interfejs i logika prezentacji: JS/TS + testy jednostkowe/componentowe.

Electron stawia bardziej na jednorodność technologii – wszystko w JS/TS. To skraca czas startu projektu i ułatwia onboardowanie nowych osób, ale przerzuca większość weryfikacji na system typów TypeScripta (gdy jest używany) i testy.

Bezpieczeństwo i powierzchnia ataku: jak chronione są dane i system

Model uprawnień w Electronie

Electron zasadniczo rozszerza możliwości przeglądarki o API systemowe. Domyślnie aplikacja ma szeroki dostęp do dysku, sieci czy procesów – używając Node.js lub natywnych modułów. Z punktu widzenia bezpieczeństwa użytkownika oznacza to, że zaufanie przenosi się z przeglądarki na konkretną aplikację.

W ostatnich latach projekt poprawił domyślne nastawy bezpieczeństwa, jednak wciąż wiele zależy od konfiguracji konkretnej aplikacji. Kluczowe mechanizmy to m.in.:

• contextIsolation – izolacja kontekstu JS, która utrudnia wstrzyknięcie złośliwego kodu w globalny obiekt,
• nodeIntegration – włączenie/wyłączenie bezpośredniego dostępu do API Node.js z poziomu renderera,
• enableRemoteModule, polityka Content-Security-Policy, konfiguracja sandboxów.

Błędy konfiguracyjne bywają kosztowne: pozostawienie szeroko otwartych drzwi do Node.js przy jednoczesnym ładowaniu zewnętrznych zasobów (np. zdalnego HTML-a) może umożliwić ataki typu RCE.

Tauri i filozofia „allowlist”

Tauri od początku implementuje podejście „whitelist/allowlist”: aplikacja musi wyraźnie zadeklarować, z jakich API systemowych zamierza korzystać. Mechanizm ten dotyczy m.in.:

• dostępu do plików (odczyt/zapis, zakres katalogów),
• otwierania zewnętrznych URL-i,
• operacji na oknach, powiadomieniach, schowku.

Dopóki dana funkcja nie znajdzie się na liście dozwolonych, frontend nie może jej wywołać przez most JS–Rust. Z jednej strony wymaga to bardziej szczegółowej konfiguracji projektu, z drugiej ułatwia audyt – od razu widać, które „bramki” do systemu są otwarte.

Przechowywanie danych lokalnych i tajemnic

Bez względu na wybraną platformę aplikacje desktopowe gromadzą wrażliwe dane: tokeny API, sesje, klucze szyfrujące. Pytanie brzmi: gdzie i jak są one przechowywane.

W Electronie deweloperzy często sięgają po:

• lokalne pliki JSON lub bazy (SQLite, LokiJS),
• keychain systemowy (macOS), Credential Manager (Windows),
• sejfowe biblioteki JS korzystające z natywnych rozszerzeń.

Tauri eksponuje natywne mechanizmy przechowywania tajemnic przez API dostępne z poziomu Rusta i – w ograniczonej formie – z frontendu. Kombinacja Rust + systemowe keyringi ułatwia trzymanie najbardziej wrażliwych danych poza zasięgiem standardowego JS, który bywa częstym celem ataków XSS.

Aktualizacje i łańcuch dostaw

Bezpieczeństwo to również proces aktualizacji. Electron ma dojrzały ekosystem narzędzi do auto-aktualizacji (np. electron-updater), które potrafią pobierać nowe wersje binarek, weryfikować podpisy, różnicować paczki. Wymaga to jednak własnej infrastruktury aktualizacyjnej lub zewnętrznego serwisu.

Tauri wspiera auto-aktualizacje poprzez własne komponenty, również z podpisem i walidacją. Dodatkową warstwę stanowi tu Rust: kompilowane binarki można podpisać zgodnie ze standardowymi mechanizmami danego systemu (kod podpisany certyfikatem dewelopera), co ułatwia budowanie zaufania w środowiskach korporacyjnych.

Coraz większą uwagę przyciąga kwestia łańcucha dostaw (supply chain). Electron – jako projekt Node’owy – dziedziczy problematykę bezpieczeństwa npm: tysiące zależności, ryzyko wstrzyknięć złośliwego kodu w transitive dependencies. Tauri, choć frontendowo także korzysta z npm, ma po stronie backendu Rust i ekosystem crates.io. To inny zestaw ryzyk, zwykle o mniejszej „gęstości” zależności, ale wymagający równie uważnego monitoringu.

API systemowe, integracja z OS i funkcje „desktopowe”

Zakres i ergonomia dostępnych API

Elektron oferuje szeroką paletę API „out of the box”: okna, menu, tray, powiadomienia, obsługa skrótów globalnych, schowek, drag&drop, integracja z paskiem zadań/dockiem, a także moduły do pracy z systemem plików, procesami czy GPU. Dla dewelopera oznacza to, że wiele funkcji desktopowych dostępnych jest od razu, bez pisania natywnego kodu.

Tauri również udostępnia bogaty zestaw API, ale filozofia jest bardziej modularna i konserwatywna. Wiele funkcji jest doklejanych jako pluginy lub wymaga explicitznego włączenia w konfiguracji. Efekt bywa dwojaki:

• aplikacja nie dźwiga nieużywanych zależności i API,
• konfiguracja projektu bywa bardziej rozbudowana na starcie.

Integracja z menu, trayem i paskiem zadań

Typowe dla aplikacji desktopowych są interakcje z systemowym paskiem zadań czy trayem. Electron pozwala dość szybko zbudować:

• ikony w trayu z menu kontekstowym,
• odznaki (badges) na ikonie docka (macOS),
• postęp na pasku zadań Windows.

W Tauri te scenariusze są realizowane głównie przez oficjalne i społecznościowe pluginy. Warstwa Rusta odpowiada za integrację z natywnym API, natomiast frontend w JS wywołuje odpowiednie komendy. W większości wypadków osiąga się podobny efekt końcowy, choć wymaga to nieco więcej pracy konfiguracyjnej.

Powiadomienia i uprawnienia użytkownika

Na poziomie powiadomień systemowych obie platformy korzystają z natywnych mechanizmów OS. Różnica częściej dotyczy sposobu zarządzania uprawnieniami. Electron przyjmuje model „masz uprawnienia, jeśli użytkownik zainstalował aplikację”, a szczegółowe ustawienia zależą już od systemu operacyjnego.