Ha elég időt töltesz a Hacker News vagy a Reddit böngészésével, előbb-utóbb ugyanazzal a kritikával találkozol: az Electron fel van fújva, túl sok memóriát használ, és a komoly asztali alkalmazásoknak natívnak kellene lenniük.
Van némi igazság ebben a kritikában. Az Electron-alkalmazások alapvető erőforrásigénye általában nagyobb, mert a Chromiumot és a Node.js-t is magukkal hozzák. Egy gondosan megtervezett natív alkalmazás kevesebb memóriát használhat, gyorsabban indulhat, és szorosabban integrálódhat az operációs rendszerrel.
Ez a vita azonban túlságosan a számítógépre összpontosít, és nem eléggé a szoftvert fejlesztő vállalatra.
A legtöbb felhasználó számára alig számít az alkalmazás mögött álló technológia. Az érdekli őket, hogy működik-e, gyorsan reagál-e, kijavítják-e a hibákat, és folyamatosan jelennek-e meg hasznos funkciók. Egy szoftvercég számára ezért a technológiai környezet egyik legfontosabb tulajdonsága olyasmi, ami ritkán jelenik meg a teljesítménymérési táblázatokban: milyen gyorsan tudja a csapat fejleszteni, kiadni, a tapasztalatokból tanulva továbbfejleszteni a terméket?
Sok modern asztali alkalmazás esetében az Electron ebben kivételesen jó.
A szűkös erőforrás a fejlesztői idő
Az idealizált, natív asztali szoftvereket készítő vállalatnak kiváló macOS-csapata van, egy másik csapata a Windows-alkalmazást fejleszti, és talán egy harmadik a Linux támogatásával foglalkozik. Minden alkalmazást gondosan optimalizálnak a saját platformjára, és minden fejlesztő mélyrehatóan ismeri azt az operációs rendszert, amelyen dolgozik.
A legtöbb vállalat nem engedheti meg magának ezt a luxust.
Egy asztali terméken lehet, hogy öt fejlesztő dolgozik. Lehet, hogy csak kettő. Ugyanezeknek a fejlesztőknek kell funkciókat készíteniük, hibákat javítaniuk, a teljesítményt növelniük, az ügyfeleknek válaszolniuk, az infrastruktúrát karbantartaniuk, az operációs rendszerek változásait kezelniük, és gondoskodniuk a termék folyamatos fejlődéséről.
A natív fejlesztés ezt megnehezíti, mert a macOS, a Windows és a Linux valóban eltérő platformok. Különböznek a felhasználói felülethez használt keretrendszereik, API-jaik, jogosultsági rendszereik, életciklus-kezelésük, telepítőik, frissítési mechanizmusaik, értesítési rendszereik, ablakkezelésük és akadálymentesítési API-jaik, ráadásul évek alatt felhalmozódott platformspecifikus sajátosságaik vannak.
Az Electron megváltoztatja ezt az egyenletet. A Chromiumot, a Node.js-t és az asztali API-kat egy közös alkalmazásmodellben egyesíti a macOS, a Windows és a Linux rendszereken. Ugyanaz a TypeScript-fejlesztő gyakran a felülettől az alkalmazáslogikáig meg tud valósítani egy funkciót, majd minden asztali platformon kiadhatja azt. A natív kód továbbra is rendelkezésre áll, ha valóban szükség van rá, de a termék alapja helyett kivétellé válik. Maga az Electron is az egyik legfőbb előnyeként említi ezt: egyetlen JavaScript-kódbázis mindhárom fő asztali platformon.
Ez a különbség az évek során összeadódik. Ha minden érdemi funkcióhoz külön Mac- és Windows-megvalósítás kell, a vállalat újra és újra megfizeti ezt a platformadót: minden funkciónál, újratervezésnél, kísérletnél, hibajavításnál, akadálymentesítési fejlesztésnél és teljesítményoptimalizálásnál.
Az Electronnal e munka nagy részét csak egyszer kell elvégezni.
Az Electron az iteráció sebességére optimalizál
A termékek ritkán azért válnak nagyszerűvé, mert az első megvalósítás tökéletes volt. Az ismételt fejlesztési ciklusok teszik őket nagyszerűvé.
A csapat kiad valamit. Az ügyfelek használják. A csapat tanul belőle. Módosítja a funkciót. Többen kezdik használni. Láthatóvá válik egy újabb probléma. A csapat ismét javít rajta.
Minél rövidebb az ötlet, a megvalósítás, a visszajelzés és a továbbfejlesztés közötti ciklus, annál gyorsabban javul a termék.
Az Electron különösen jól rövidíti le ezt a ciklust, mert olyan technológiákra épül, amelyeket a szoftvercégek egyébként is mindenütt használnak: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js és npm.
Ez azt jelenti, hogy a vállalatok jóval többet oszthatnak meg a forráskódnál. A webes és asztali termékeik között megoszthatják a fejlesztőket, a felületi komponenseket, a fejlesztőeszközöket, a könyvtárakat, az infrastruktúrát, a tesztelési módszereket és a szervezetben felhalmozott tudást.
Egy frontendfejlesztő nem válik hirtelen használhatatlanná csak azért, mert a cégnek a Windows-klienshez kell segítség. Egy asztali alkalmazásokat fejlesztő mérnök a webalkalmazáshoz is hozzájárulhat. Egy full-stack TypeScript-fejlesztő a prioritások változásával egyik termékről a másikra válthat.
Egy kis- vagy közepes vállalat számára ez a rugalmasság sokkal többet érhet, mint 100 MB RAM megtakarítása.
Nézzük meg, kik használják ténylegesen az Electront
Az Electront olykor olyan vállalatok kerülőútjaként írják le, amelyek nem hajlandók egy „rendes” asztali alkalmazásba befektetni. Az ezzel készült termékek mellett azonban ezt az érvet egyre nehezebb fenntartani.
Az Electron saját projektje olyan termékeket emel ki, mint a Slack, a Discord, a Signal, a ChatGPT, a Claude, a Visual Studio Code, a Notion, a Docker, a Loom és a Canva. Ezek nem egyszerű segédprogramok. Sok közülük a világ legösszetettebb és legszélesebb körben használt, produktivitást segítő alkalmazásai közé tartozik.
A Visual Studio Code különösen szemléletes példa. A Microsoft gyakorlatilag bármelyik Windows-technológiával elkészíthetné zászlóshajó kódszerkesztőjét, a VS Code mégis Electront használ Windowson, macOS-en és Linuxon. Terminálokat, hibakeresést, nyelvi szervereket, Git-integrációt, távoli fejlesztést, notebookokat, bővítményeket és nagymértékben testreszabott szerkesztőket kínál.
Az érdekes kérdés nem az, hogy a Microsoft megtakaríthatna-e memóriát három különálló natív változat elkészítésével. Természetesen igen.
A jobb kérdés az, hogy a VS Code ugyanolyan gyorsan fejlődött volna-e, ugyanolyan egységes maradt volna-e a platformok között, és kialakult volna-e körülötte ekkora ökoszisztéma, ha minden fontosabb képesség több külön megvalósítást igényelt volna.
A ChatGPT és a Claude megmutatja a megközelítések közötti különbséget
A ChatGPT és a Claude közötti kontraszt is tanulságos.
Az OpenAI kezdetben külön natív macOS-alkalmazást készített a ChatGPT-hez. Az Anthropic ezzel szemben Electronra építette a Claude Desktopot, így már kezdettől fogva közös asztali alapja volt a különböző platformokon.
Ez a különbség a termékek bővülésével egyre fontosabbá vált. A Claude Desktop ugyanabba a platformfüggetlen alkalmazásba tudott folyamatosan új képességeket beépíteni, például MCP-integrációkat, bővítményeket és a Claude Code-ot. Az Anthropic most már közvetlenül az asztali alkalmazásában is támogatja a Claude Code-ot, több helyi és távoli munkamenettel együtt.
Az OpenAI később az újabb, többplatformos asztali fejlesztéseivel szintén az Electron felé fordult, és az Electron ma már a ChatGPT-t és a Claude-ot is a jelentős Electron-alkalmazások között sorolja fel.
Túlzás lenne azt állítani, hogy a termékfejlesztés sebességében mutatkozó különbséget egyedül az Electron magyarázza. A csapat mérete, a prioritások, a termékstratégia és a belső szervezeti felépítés mind számítanak. Az architekturális előny azonban egyértelmű: a közös, platformfüggetlen alap megkönnyíti a funkciók kiadását több operációs rendszerre, külön megvalósítások fenntartása nélkül.
Pontosan az ilyen előnyök válnak egyre értékesebbé, ahogy egy asztali termék növekszik.
Az Evernote megtapasztalta a különálló kliensek fenntartásának költségét
Az Evernote ennek a problémának az egyik legvilágosabb történelmi példája.
Az Evernote éveken át külön alkalmazásokat tartott fenn Macre, Windowsra, mobilra és webre. Idővel ezekben a termékekben eltérő működés, megjelenítési különbségek, örökölt feltételezések és szinkronizációs problémák halmozódtak fel.
2020-ban az Evernote közös kódbázisra építve újraalkotta a Windows- és Mac-alkalmazásait. A vállalat szerint az új alap stabilabbá tette volna az alkalmazásokat, gyorsabb hibajavítást, gyakoribb funkciókiadást és jobb, platformok közötti szinkronizációt tett volna lehetővé.
Ez az átállás nem volt fájdalommentes, és néhány régi felhasználó nehezményezte egyes platformspecifikus funkciók kezdeti elvesztését. Ám az ok, amiért az Evernote vállalta ezt a költséges újraírást, érdekesebb, mint maguk az átállási problémák.
Amikor egy termék már gazdag szerkesztővel, offline tárolással, kereséssel, mellékletekkel, együttműködéssel, feladatokkal, naptárakkal és összetett szinkronizációval rendelkezik, több független megvalósítás fenntartása egyre drágábbá válik. A hibák eltérően jelentkeznek. A megjelenítés különbözik. A szinkronizációs logika különféle helyi architektúrákkal lép kölcsönhatásba. Minden érdemi termékváltoztatást több kliensen is végig kell vezetni.
A közös architektúra nem tünteti el a nehéz problémákat. Lehetővé teszi, hogy a vállalat közülük többet csak egyszer oldjon meg.
A Linux lehet az Electron leginkább alulértékelt előnye
A Linux még erősebbé teszi az Electron melletti érveket.
A Linux megfelelő támogatása nehéz feladat. A macOS-szel vagy a Windowsszal ellentétben az „asztali Linux” nem egyetlen, szigorúan ellenőrzött platform. A fejlesztőknek különböző disztribúciókkal, csomagformátumokkal, asztali környezetekkel, grafikus szoftverrétegekkel, rendszerkönyvtárakkal és megjelenítési protokollokkal kell megbirkózniuk.
Sok szoftvercég számára az észszerű üzleti döntés egyszerűen az lenne, hogy nem támogatja a Linuxot.
Az Electron megváltoztatja a gazdasági mérleget.
Mivel az Electron közös futtatókörnyezetet biztosít macOS-en, Windowson és Linuxon, a Linux-támogatás hozzáadása drámaian könnyebb lehet, mint egy külön natív Linux-megvalósítás fenntartása. Ez az egyik oka annak, hogy a Linux-felhasználók ma számos olyan jelentős asztali alkalmazáshoz hozzáférhetnek, amelyhez korábban talán soha nem készült volna hivatalos Linux-kliens.
A Visual Studio Code, a Slack, a Discord, a Signal, az 1Password, a Postman, az Obsidian és sok más eszköz anélkül támogathatja a Linuxot, hogy teljesen különálló GTK- vagy Qt-alkalmazást kellene fenntartania.
Az Electron az alkalmazásfejlesztők helyett a Linux-specifikus összetettség jelentős részét is kezeli. Jó példa erre az X11-ről a Waylandre történő átállás. Az Electron karbantartói leírták, hogyan vitte gyakorlatilag magával a Chromium Waylandre való átállása az Electron-alkalmazásokat is, csökkentve azt a munkát, amelyet az egyes alkalmazásfejlesztő csapatoknak önállóan kellett elvégezniük a megjelenítési rendszerrel kapcsolatban.
Az Electronhoz hasonló keretrendszerek nélkül sok vállalat nem készítene natív Linux-klienst. Egyszerűen csak a macOS-t és a Windowst támogatná, a Linux-felhasználóknak pedig maradna egy böngészőlap.
Az Electron valószínűleg többet tett a kereskedelmi Linux-asztali szoftverekért, mint amennyi elismerést kap érte.
Még a Microsoft is egyre gyakrabban választ webes technológiát
Talán a Microsoft a legerősebb ellenpélda arra az elképzelésre, hogy a komoly Windows-szoftvereknek mindig natív Windows-felületi keretrendszereket kellene használniuk.
A Microsoft kezében van a Windows. Az ő kezében van a Win32, a .NET, a WinUI, a WebView2 és annak a platformnak a jelentős része, amelyre a fejlesztők építenek. Ha a teljesen natív Windows-fejlesztés mindig a magától értetődő megoldás lenne, a Microsoft volna a lehető legjobb helyzetben ahhoz, hogy mindenütt azt használja.
Mégsem teszi.
A Visual Studio Code Electront használ. A Teams továbbra is Reactre, TypeScriptre és Chromiumra épül, még azután is, hogy a Microsoft az Electront egy jobban optimalizált WebView2-alapú befogadóalkalmazásra cserélte. Az új Windowsos Outlook is nagymértékben támaszkodik a webes technológiára, és a Microsoft kifejezetten úgy írja le ezt az architektúrát, mint amely javítja az agilitást, gyorsabb funkciókiadást tesz lehetővé, és egységesebb élményt teremt.
A Teams különösen tanulságos példa. A Microsoft javítani akarta a teljesítményt és csökkenteni az erőforrás-felhasználást, ezért megváltoztatta az architektúrát. De nem írta újra a felületet hagyományos, natív Windows-alkalmazásként.
Megtartotta a webes technológiai környezetet, és aköré építette az optimalizálást.
Ez a különbség számít. A Microsoft úgy döntött, hogy a React, a TypeScript és a Chromium szervezeti előnyeit érdemes megőrizni akkor is, amikor erőteljesen javítja a teljesítményt.
Van itt egy másik tanulság is. Maga a Microsoft az évek során a Windows-alkalmazástechnológiák számos generációját vezette be: Win32, WPF, UWP, WinUI és mások. Egy „natív Windowst” választó vállalat nem feltétlenül időtálló platformot választ. Gyakran a Microsoft által előnyben részesített keretrendszer valamelyik generációjára teszi a tétjét.
A webes platform némileg ironikus módon az egyik stabilabb alkalmazásfejlesztési célplatformmá vált.
A munkaerő-felvétel az architektúra része
A keretrendszer megválasztása azt is meghatározza, kit tudsz felvenni.
A JavaScript- és TypeScript-fejlesztők az iparág egyik legnagyobb fejlesztői szakemberbázisát alkotják. Egy Electronnal dolgozó vállalat ebből a körből toborozhat ahelyett, hogy tapasztalt macOS-, Windows- és Linux-specialistákból kellene külön csapatokat kialakítania.
A natív fejlesztés szakértői továbbra is értékesek. A komoly asztali termékekhez továbbra is szükség van olyan fejlesztőkre, akik mélyen ismerik az operációs rendszereket. Az Electron azonban megváltoztatja, hány ilyen szakértőre van szükség.
Ahelyett, hogy az alkalmazás nagy részét platformszakértőknek kellene elkészíteniük, viszonylag kis mennyiségű natív integrációs kódot tarthatsz fenn, és a csapat többsége a közös terméken dolgozhat.
Ez még fontosabb, ha a vállalatnak már van webalkalmazása. A React-komponensek olykor megoszthatók. A TypeScript-könyvtárak újrafelhasználhatók. A terméklogika átvihető a webes és az asztali változat között. A fejlesztők anélkül válthatnak csapatot, hogy egy teljesen más ökoszisztémát kellene megtanulniuk.
A munkaerő-utánpótlás is kevésbé válik sérülékennyé. Ha távozik az egyetlen fejlesztő, aki mélyen ismeri a natív Windows-kliensedet, nehéz lehet pótolni ezt a szakértelmet. Az Electron esetében a kódbázis jóval nagyobb része használ a szervezet többi tagja számára is ismerős technológiákat.
Egy keretrendszer tehát nem csupán azt határozza meg, hogyan jelenik meg a felület. Arra is hatással van, hogyan épülhet fel maga a fejlesztői szervezet.
A natív nem jelent automatikusan jobb szoftvert
A fejlesztők gyakran szinte a „gyors” szinonimájaként használják a „natív” szót.
Pedig nem az.
A natív API-k lehetőséget adnak a fejlesztőknek arra, hogy nagyon hatékony alkalmazást készítsenek. Az, hogy a végtermék valóban eléri-e ezt, az architektúrától, a csapattól, a költségvetéstől és a vállalat által megengedhető optimalizálási munka mennyiségétől függ.
Egy natív alkalmazás is lehet lassú, hibás, memóriaigényes, következetlen vagy rosszul karbantartott.
Ennél is fontosabb, hogy ha egy korlátozott létszámú csapatot több natív megvalósítás között osztanak szét, mindegyik megvalósításra kevesebb fejlesztői munkaóra jut.
Képzeljük el, hogy egy vállalatnak hat fejlesztő áll rendelkezésére az asztali termékéhez. Az egyik lehetőség, hogy megosztja őket a Mac és a Windows között, a Linuxot pedig talán nem támogatja. A másik, hogy szinte mind a hat fejlesztőt egyetlen közös Electron-alkalmazáson dolgoztatja, amely mindhárom platformot kiszolgálja.
Melyik megközelítés ad a vállalatnak több fejlesztői kapacitást az indulási idő javítására, a memóriaszivárgások megszüntetésére, az interakciók csiszolására, az akadálymentesítés javítására, az összeomlások csökkentésére és a felhasználói igényekre való reagálásra?
Nem magától értetődő, hogy a natív alkalmazások eredményezik a jobb terméket.
Ez érdekes paradoxont teremt: egy valamivel több gépi erőforrást fogyasztó keretrendszer lehetővé teheti, hogy a vállalat jobban optimalizált terméket készítsen, mert sokkal kevesebb fejlesztői erőforrást igényel.
Az Electron ellenőrzött platformot ad
Az Electronnak van egy másik, könnyen figyelmen kívül hagyható előnye is: azt a Chromium-futtatókörnyezetet szállítja az alkalmazással, amelyre azt fejlesztették, és amellyel tesztelték.
Ez kiiktat egy jelentős változót a többplatformos fejlesztésből.
Az operációs rendszer webes nézeteire épülő keretrendszerekkel kisebb alkalmazások készülhetnek, de ennek az az ára, hogy ugyanaz a frontend Windowson WebView2-n, macOS-en WKWebView-n, Linuxon pedig WebKitGTK-n futhat. Ezeknek a motoroknak eltérő képességeik, hibáik, kiadási ütemezésük és megjelenítési viselkedésük van.
Az Electron más kompromisszumot választ: mellékeli a futtatókörnyezetet, és az alkalmazás részévé teszi.
Igen, ez tárhelybe kerül.
Cserébe azonban jóval egységesebb célkörnyezetet biztosít a fejlesztőknek három nagyon eltérő operációs rendszeren.
Az egységességnek óriási fejlesztési értéke van.
Ha az Electron nem elég, továbbra is használhatsz natív kódot
Az Electron választása nem jelenti azt, hogy lemondasz a natív képességekről.
Az Electron-alkalmazások szükség esetén natív modulokat és platformspecifikus kódot is használhatnak. Ez azt jelenti, hogy az architekturális választás valójában nem ez:
100% natív vagy 100% JavaScript.
Sok termék esetében jobb modell a következő:
az alkalmazás nagy része közös, és csak ott van egy kevés natív kód, ahol az operációs rendszer valóban megköveteli.
A natív kód az egész termék alapja helyett kiegészítő megoldássá válik arra az esetre, ha a közös megközelítés nem elegendő.
Sok vállalat számára ez a fejlesztői munka sokkal jobb elosztását jelenti.
A felhasználókat a termékek érdeklik, nem a keretrendszerek
Van a technikailag tájékozott felhasználóknak egy kis csoportja, amely megnyitja a Tevékenységfigyelőt, észrevesz több Chromium-folyamatot, és azonnal panaszkodni kezd, hogy az alkalmazás Electront használ.
A legtöbb felhasználó nem ilyen.
Nem érdekli őket, hogy a Slack Electront használ. Nem érdekli őket, hogy a VS Code webes technológiákkal készült. Nem tudják, milyen keretrendszert használ a Claude. Az érdekli őket, hogy a szoftver segít-e elvégezni a munkájukat.
Ha egy alkalmazás elég gyorsan indul, gyorsan reagál, ritkán omlik össze, és megoldja a felhasználó problémáját, a megvalósítás technológiája nagyrészt láthatatlan marad.
Ennek a fordítottja ugyanúgy igaz. Egy natív alkalmazás nem válik automatikusan jó termékké attól, hogy Swiftet vagy WinUI-t használ.
A szoftverek a termékek szintjén versenyeznek, nem a keretrendszerek szintjén.
A vállalatot optimalizáld, ne csak a binárist
Az Electronnak valós költségei vannak. Több tárhelyet használ. Az alapvető memóriaigénye általában magasabb, mint egy kis natív alkalmazásé. Egyértelműen vannak olyan termékek, amelyeknél ezek a költségek rossz választássá teszik az Electront.
Egy apró, menüsávban működő segédprogramnak valószínűleg nincs szüksége Chromiumra. Egy eszközillesztőnek biztosan nincs. A játékoknak, a professzionális audioszoftvereknek és a késleltetésre rendkívül érzékeny alkalmazásoknak más követelményeik vannak. Ha pedig a terméked mindig csak egyetlen operációs rendszeren fog futni, sokkal könnyebb indokolni a natív fejlesztést.
A modern asztali szoftverek hatalmas része azonban nem ezekbe a kategóriákba tartozik.
Ezek felhőszolgáltatásokhoz kapcsolódó, összetett felületekből állnak. Windowson és macOS-en kell futniuk, és a felhasználók egyre inkább a Linux-támogatást is elvárják. Folyamatosan fejlődniük kell. Olyan termékekkel versenyeznek, amelyek hetente adnak ki változtatásokat. És általában olyan vállalat készíti őket, amelynek véges számú fejlesztője van.
Ezeknél a termékeknél a fejlesztői produktivitás az alkalmazás teljesítményének része.
Az Electron lehetővé teszi a vállalat számára, hogy jóval nagyobb szakemberbázisból toborozzon, megossza a fejlesztőket a webes és asztali termékek között, több alkalmazás helyett egyetlen elsődleges alkalmazást tartson fenn, újrafelhasználja a JavaScript-ökoszisztémát, következetesebben adjon ki funkciókat több operációs rendszerre, olyan költséggel támogassa a Linuxot, amelyet máskülönben gyakran nehéz lenne indokolni, és több fejlesztői időt fordítson a termék javítására a párhuzamos megvalósítások karbantartása helyett.
Az Electron költségét könnyen megmérheted megabájtokban.
Az alternatíva költségeit nehezebb észrevenni. Többletfejlesztők, megkettőzött megvalósítások, hosszabb kiadási ciklusok, platformspecifikus hibák, toborzási nehézségek, elszigetelten működő szervezeti egységek, támogatás nélkül maradó Linux-felhasználók és mindenkihez csak hónapokkal később eljutó funkciók formájában jelentkeznek.
Ezek a költségek nem jelennek meg a Tevékenységfigyelőben.
A szoftvert készítő vállalat számára azonban lényegesen nagyobbak lehetnek.
A szoftverfejlesztés célja nem az, hogy a lehető legkisebb bináris állományt állítsuk elő.
Hanem az, hogy a lehető legjobb olyan terméket készítsük el, amelyet a szervezetünk ki tud adni, fenn tud tartani, és folyamatosan tovább tud fejleszteni.
Az asztali alkalmazások meglepően nagy csoportjánál az Electron továbbra is az egyik leghatékonyabb módja pontosan ennek.