Provedite dovoljno vremena na Hacker Newsu ili Redditu i prije ili poslije naići ćete na istu kritiku: Electron je glomazan, Electron troši previše memorije, a ozbiljne aplikacije za stolna računala trebale bi biti nativne.
U toj kritici ima istine. Aplikacije temeljene na Electronu u pravilu imaju veću osnovnu potrošnju resursa jer uključuju Chromium i Node.js. Pažljivo razvijena nativna aplikacija može trošiti manje memorije, brže se pokretati i dublje se integrirati s operacijskim sustavom.
No ta se rasprava previše usredotočuje na računalo, a premalo na tvrtku koja razvija softver.
Većini korisnika tehnologija na kojoj se aplikacija temelji gotovo uopće nije važna. Važno im je radi li, reagira li brzo, ispravljaju li se pogreške i pojavljuju li se redovito korisne značajke. Za softversku tvrtku jedno od najvažnijih svojstava tehnološkog skupa stoga je nešto što se rijetko pojavljuje u tablicama usporednih mjerenja: koliko brzo tim može razvijati, isporučivati, učiti i unapređivati proizvod?
Za mnoge moderne aplikacije za stolna računala Electron je u tome iznimno dobar.
Oskudan resurs je vrijeme inženjera
Idealizirana tvrtka koja razvija nativne aplikacije za stolna računala ima izvrstan tim za macOS, drugi tim koji razvija aplikaciju za Windows i možda još jedan tim koji podržava Linux. Svaka je aplikacija pažljivo optimizirana za svoju platformu, a svaki inženjer temeljito razumije operacijski sustav na kojem radi.
Većina tvrtki nema taj luksuz.
Na proizvodu za stolna računala možda radi pet inženjera. Možda samo dva. Ti isti inženjeri moraju razvijati značajke, ispravljati pogreške, poboljšavati performanse, odgovarati korisnicima, održavati infrastrukturu, nositi se s promjenama operacijskih sustava i nastaviti unapređivati proizvod.
Nativni razvoj to otežava jer su macOS, Windows i Linux uistinu različite platforme. Imaju različite okvire za korisnička sučelja, API-je, sustave dozvola, ponašanje tijekom životnog ciklusa aplikacije, instalacijske programe, mehanizme ažuriranja, sustave obavijesti, upravljanje prozorima, API-je za pristupačnost i godinama nagomilane specifičnosti pojedinih platformi.
Electron mijenja tu računicu. Objedinjuje Chromium, Node.js i API-je za stolna računala u zajednički aplikacijski model za macOS, Windows i Linux. Isti inženjer koji radi u TypeScriptu često može razviti značajku od sučelja do aplikacijske logike i isporučiti je na svakoj platformi za stolna računala. Nativni kod ostaje dostupan kada je uistinu potreban, ali postaje iznimka umjesto temelja proizvoda. Sam Electron to opisuje kao jednu od svojih ključnih prednosti: jednu bazu JavaScript koda za sve tri glavne platforme za stolna računala.
Ta se razlika tijekom godina kumulativno povećava. Ako svaka značajnija značajka zahtijeva zasebnu implementaciju za Mac i Windows, tvrtka taj dodatni trošak platformi plaća uvijek iznova: za svaku značajku, redizajn, eksperiment, ispravak pogreške, poboljšanje pristupačnosti i optimizaciju performansi.
Uz Electron velik dio tog posla obavlja se samo jednom.
Electron je usmjeren na brzinu iteracija
Proizvodi rijetko postaju izvrsni zato što je prva implementacija bila savršena. Izvrsni postaju kroz iteracije.
Tim nešto isporuči. Korisnici to upotrebljavaju. Tim uči. Mijenja značajku. Koristi je više ljudi. Postaje vidljiv još jedan problem. Tim je ponovno poboljšava.
Što je kraći ciklus između ideje, implementacije, povratnih informacija i poboljšanja, to proizvod brže postaje bolji.
Electron je posebno dobar u skraćivanju tog ciklusa jer se temelji na tehnologijama koje softverske tvrtke već upotrebljavaju posvuda: JavaScriptu, TypeScriptu, HTML-u, CSS-u, Reactu, Chromiumu, Node.js-u i npm-u.
To znači da tvrtke između svojih web-proizvoda i proizvoda za stolna računala mogu dijeliti mnogo više od izvornog koda. Mogu dijeliti inženjere, komponente korisničkog sučelja, razvojne alate, biblioteke, infrastrukturu, pristupe testiranju i znanje unutar organizacije.
Frontend inženjer ne postaje odjednom neupotrebljiv zato što tvrtki treba pomoć s klijentskom aplikacijom za Windows. Inženjer koji radi na aplikacijama za stolna računala može pridonositi web-aplikaciji. Full-stack inženjer koji radi u TypeScriptu može prelaziti s jednog proizvoda na drugi kako se prioriteti mijenjaju.
Maloj ili srednjoj tvrtki ta fleksibilnost može vrijediti mnogo više od uštede 100 MB RAM-a.
Pogledajte tko zapravo koristi Electron
Electron se ponekad opisuje kao prečac za tvrtke koje ne žele ulagati u „pravu” aplikaciju za stolna računala. Proizvodi izgrađeni na njemu čine taj argument sve teže obranjivim.
Sam projekt Electron ističe proizvode poput Slacka, Discorda, Signala, ChatGPT-a, Claudea, Visual Studio Codea, Notiona, Dockera, Looma i Canve. To nisu jednostavni uslužni programi. Mnogi od njih ubrajaju se među najsofisticiranije i najčešće korištene aplikacije za produktivnost na svijetu.
Visual Studio Code posebno je koristan primjer. Microsoft bi svoj vodeći uređivač koda mogao razviti s praktički bilo kojom tehnologijom za Windows koju poželi, no VS Code ipak koristi Electron na Windowsu, macOS-u i Linuxu. Uključuje terminale, otklanjanje pogrešaka, jezične poslužitelje, integraciju s Gitom, udaljeni razvoj, bilježnice, proširenja i visoko prilagođene uređivače.
Zanimljivo pitanje nije bi li Microsoft mogao uštedjeti memoriju razvojem triju zasebnih nativnih verzija. Naravno da bi mogao.
Bolje je pitanje bi li se VS Code razvijao jednako brzo, ostao jednako dosljedan na svim platformama i razvio tako velik ekosustav da je svaka važna mogućnost zahtijevala nekoliko zasebnih implementacija.
ChatGPT i Claude pokazuju razliku u pristupu
Poučna je i razlika između ChatGPT-a i Claudea.
OpenAI je u početku za ChatGPT razvio zasebnu nativnu aplikaciju za macOS. Anthropic je, s druge strane, razvio Claude Desktop na Electronu i od početka imao zajednički temelj za aplikaciju za stolna računala na različitim platformama.
Ta je razlika postajala važnija kako su se proizvodi širili. Claude Desktop mogao je nastaviti dodavati mogućnosti poput integracija s MCP-om, proširenja i Claude Codea u istu višeplatformsku aplikaciju. Anthropic sada podržava Claude Code izravno unutar svoje aplikacije za stolna računala, uključujući više lokalnih i udaljenih sesija.
OpenAI je kasnije i svoj noviji smjer višeplatformskog razvoja za stolna računala usmjerio prema Electronu, a Electron sada navodi i ChatGPT i Claude među istaknutim aplikacijama koje ga koriste.
Bilo bi pretjerano tvrditi da samo Electron objašnjava razliku u brzini razvoja proizvoda. Veličina tima, prioriteti, strategija proizvoda i unutarnja organizacija također su važni. No arhitekturna je prednost jasna: zajednički višeplatformski temelj olakšava isporuku značajki na različitim operacijskim sustavima bez održavanja zasebnih implementacija.
Upravo takva prednost postaje sve vrednija kako proizvod za stolna računala raste.
Evernote je spoznao cijenu održavanja zasebnih klijentskih aplikacija
Evernote je jedan od najjasnijih povijesnih primjera tog problema.
Godinama je Evernote održavao različite aplikacije za Mac, Windows, mobilne uređaje i web. S vremenom su se u tim proizvodima nagomilale razlike u ponašanju i prikazu, naslijeđene pretpostavke te problemi sa sinkronizacijom.
Evernote je 2020. ponovno izgradio svoje aplikacije za Windows i Mac oko zajedničke baze koda. Tvrtka je izjavila da će novi temelj aplikacije učiniti stabilnijima, omogućiti brže ispravljanje pogrešaka i češću isporuku značajki te poboljšati sinkronizaciju između platformi.
Ta migracija nije prošla bezbolno, a nekim se dugogodišnjim korisnicima nije svidio početni gubitak značajki specifičnih za pojedine platforme. No razlog zbog kojeg se Evernote upustio u tako skupo ponovno pisanje aplikacija zanimljiviji je od samih problema migracije.
Kad proizvod ima napredan uređivač, izvanmrežnu pohranu, pretraživanje, privitke, suradnju, zadatke, kalendare i složenu sinkronizaciju, održavanje nekoliko neovisnih implementacija postaje sve skuplje. Pogreške se manifestiraju različito. Prikaz se razlikuje. Logika sinkronizacije djeluje u različitim lokalnim arhitekturama. Svaka značajnija promjena proizvoda mora se prenijeti kroz nekoliko klijentskih aplikacija.
Zajednička arhitektura ne uklanja teške probleme. Ona tvrtki omogućuje da veći dio njih riješi samo jednom.
Linux je možda najpodcjenjenija prednost Electrona
Linux dodatno jača argumente u korist Electrona.
Pružiti kvalitetnu podršku za Linux teško je. Za razliku od macOS-a ili Windowsa, „Linux za stolna računala” nije jedna strogo kontrolirana platforma. Programeri se moraju nositi s različitim distribucijama, formatima paketa, radnim okruženjima, grafičkim slojevima, sistemskim bibliotekama i protokolima prikaza.
Za mnoge softverske tvrtke racionalna poslovna odluka bila bi jednostavno ne podržavati Linux.
Electron mijenja ekonomsku računicu.
Budući da Electron pruža zajedničko izvršno okruženje za macOS, Windows i Linux, dodavanje podrške za Linux može biti znatno lakše od održavanja zasebne nativne implementacije za Linux. To je jedan od razloga zašto korisnici Linuxa danas imaju pristup mnogim velikim aplikacijama za stolna računala koje u prošlosti možda nikada ne bi dobile službenu klijentsku aplikaciju za Linux.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian i mnogi drugi alati mogu podržavati Linux bez održavanja potpuno zasebne aplikacije temeljene na GTK-u ili Qt-u.
Electron također preuzima velik dio složenosti specifične za Linux umjesto razvojnih timova aplikacija. Dobar primjer je prelazak s X11 na Wayland. Održavatelji Electrona opisali su kako je Chromiumov prelazak na Wayland praktički povukao sa sobom i Electronove aplikacije, smanjujući količinu posla na slojevima sustava za prikaz koji je svaki aplikacijski tim morao samostalno obaviti.
Bez okvira poput Electrona mnoge tvrtke ne bi razvijale nativne klijentske aplikacije za Linux. Jednostavno bi podržavale macOS i Windows, a korisnicima Linuxa ostavile karticu u pregledniku.
Electron je vjerojatno učinio više za komercijalni softver za stolna računala s Linuxom nego što mu se priznaje.
Čak i Microsoft sve češće bira web-tehnologiju
Microsoft je možda najsnažniji protuprimjer ideji da bi ozbiljan softver za Windows uvijek trebao koristiti nativne okvire za korisničko sučelje Windowsa.
Microsoft kontrolira Windows. Kontrolira Win32, .NET, WinUI, WebView2 i velik dio platforme na kojoj programeri razvijaju softver. Kad bi potpuno nativni razvoj za Windows uvijek bio očit odgovor, Microsoft bi bio u najboljem mogućem položaju da ga svugdje koristi.
No ne koristi ga.
Visual Studio Code koristi Electron. Teams se i dalje temelji na Reactu, TypeScriptu i Chromiumu čak i nakon što je Microsoft zamijenio Electron optimiziranijim domaćinskim okruženjem temeljenim na WebView2. Novi Outlook za Windows također se uvelike oslanja na web-tehnologiju, a Microsoft tu arhitekturu izričito opisuje kao način povećanja agilnosti, omogućavanja brže isporuke značajki i stvaranja dosljednijeg korisničkog iskustva.
Teams je posebno poučan primjer. Microsoft je želio poboljšati performanse i smanjiti potrošnju resursa pa je promijenio arhitekturu. No nije ponovno napisao korisničko sučelje kao tradicionalnu nativnu aplikaciju za Windows.
Zadržao je web-tehnološki skup i optimizirao aplikaciju oko njega.
Ta je razlika važna. Microsoft je zaključio da organizacijske prednosti Reacta, TypeScripta i Chromiuma vrijedi sačuvati čak i uz intenzivno poboljšavanje performansi.
Ovdje postoji još jedna pouka. Sam Microsoft tijekom godina uveo je mnoge generacije tehnologija za Windows aplikacije: Win32, WPF, UWP, WinUI i druge. Tvrtka koja bira „nativni Windows” ne bira nužno bezvremensku platformu. Često se kladi na jednu generaciju Microsoftova preferiranog okvira.
Pomalo ironično, web-platforma postala je jedno od stabilnijih dostupnih ciljnih okruženja za aplikacije.
Zapošljavanje je dio arhitekture
Izbor okvira određuje i koga možete zaposliti.
Programeri koji rade u JavaScriptu i TypeScriptu čine jednu od najvećih skupina inženjerskih talenata u industriji. Tvrtka koja razvija pomoću Electrona može zapošljavati iz te skupine umjesto da joj trebaju zasebni timovi iskusnih stručnjaka za macOS, Windows i Linux.
Stručnjaci za nativni razvoj i dalje su vrijedni. Ozbiljni proizvodi za stolna računala i dalje trebaju inženjere koji temeljito razumiju operacijske sustave. No Electron mijenja broj stručnjaka koji su vam potrebni.
Umjesto da zahtijevate da većinu aplikacije izgrade stručnjaci za pojedine platforme, možete zadržati relativno malu količinu koda za nativnu integraciju i prepustiti većini tima rad na zajedničkom proizvodu.
To je još važnije kada tvrtka već ima web-aplikaciju. Komponente Reacta ponekad se mogu dijeliti. Biblioteke TypeScripta mogu se ponovno koristiti. Logika proizvoda može se prenositi između weba i stolnih računala. Inženjeri mogu mijenjati timove bez učenja potpuno drukčijeg ekosustava.
Zapošljavanje također postaje manje osjetljivo na odlaske. Ako ode jedini inženjer koji temeljito razumije vašu nativnu klijentsku aplikaciju za Windows, nadomjestiti tu stručnost može biti teško. Uz Electron mnogo veći dio baze koda koristi tehnologije poznate ostatku organizacije.
Okvir stoga ne određuje samo način na koji se sučelje prikazuje. Utječe i na to kako se može strukturirati sama inženjerska organizacija.
Nativno ne znači automatski bolji softver
Programeri često koriste riječ „nativno” gotovo kao sinonim za „brzo”.
To nije isto.
Nativni API-ji daju programerima priliku da stvore vrlo učinkovitu aplikaciju. Hoće li konačni proizvod to doista postići ovisi o arhitekturi, timu, proračunu i količini optimizacijskog rada koju si tvrtka može priuštiti.
Nativna aplikacija i dalje može biti spora, puna pogrešaka, trošiti mnogo memorije, biti nedosljedna ili loše održavana.
Još važnije, podjela ograničenog tima na nekoliko nativnih implementacija znači da svaka implementacija dobiva manje inženjerskih radnih sati.
Zamislite da tvrtka ima šest inženjera na raspolaganju za svoj proizvod za stolna računala. Jedna je mogućnost podijeliti ih između Maca i Windowsa, možda ostavljajući Linux bez podrške. Druga je angažirati gotovo svih šest inženjera na jednoj zajedničkoj Electron aplikaciji koja služi svim trima platformama.
Koji pristup tvrtki daje veći inženjerski kapacitet za ubrzavanje pokretanja, uklanjanje curenja memorije, dotjerivanje interakcija, poboljšanje pristupačnosti, smanjenje rušenja i odgovaranje korisnicima?
Nije očito da nativne aplikacije daju bolji proizvod.
To stvara zanimljiv paradoks: okvir koji troši nešto više računalnih resursa može tvrtki omogućiti da izgradi bolje optimiziran proizvod jer troši mnogo manje inženjerskih resursa.
Electron vam daje kontroliranu platformu
Electron ima još jednu prednost koju je lako previdjeti: isporučuje izvršno okruženje Chromiuma za koje je aplikacija razvijena i na kojem je testirana.
Time se uklanja velika varijabla iz višeplatformskog razvoja.
Okviri temeljeni na komponentama za web-prikaz operacijskih sustava mogu proizvesti manje aplikacije, no kompromis je u tome što se isto frontend sučelje može izvoditi na WebView2 na Windowsu, WKWebViewu na macOS-u i WebKitGTK-u na Linuxu. Ti pogoni imaju različite mogućnosti, pogreške, rasporede izdavanja i ponašanje pri prikazu.
Electron bira drukčiji kompromis: uključiti izvršno okruženje u paket i učiniti ga dijelom aplikacije.
Da, to zauzima prostor na disku.
No programerima daje mnogo dosljednije ciljno okruženje na trima vrlo različitim operacijskim sustavima.
Dosljednost ima golemu inženjersku vrijednost.
Kad Electron nije dovoljan, i dalje možete koristiti nativni kod
Odabir Electrona ne znači odricanje od pristupa nativnim mogućnostima.
Electron aplikacije mogu koristiti nativne module i kod specifičan za platformu kada je to potrebno. To znači da arhitekturni izbor zapravo nije:
100 % nativno ili 100 % JavaScript.
Za mnoge proizvode bolji je model:
većina aplikacije je zajednička, uz malu količinu nativnog koda ondje gdje ga operacijski sustav uistinu zahtijeva.
Nativni kod postaje rezervni izlaz umjesto temelja cijelog proizvoda.
Za mnoge tvrtke to je mnogo bolja raspodjela inženjerskog rada.
Korisnicima su važni proizvodi, a ne okviri
Postoji mala skupina tehnički potkovanih korisnika koji otvore Activity Monitor, primijete nekoliko Chromiumovih procesa i odmah se požale da aplikacija koristi Electron.
Većina korisnika to ne radi.
Nije im važno što Slack koristi Electron. Nije im važno što je VS Code izgrađen web-tehnologijama. Ne znaju koji okvir koristi Claude. Važno im je pomaže li im softver da obave svoj posao.
Ako se aplikacija pokreće dovoljno brzo, reagira brzo, rijetko se ruši i rješava korisnikov problem, tehnologija implementacije uglavnom je nevidljiva.
Jednako vrijedi i obrnuto. Nativna aplikacija ne postaje automatski dobar proizvod zato što koristi Swift ili WinUI.
Softver se natječe na razini proizvoda, a ne na razini okvira.
Optimizirajte tvrtku, a ne samo binarnu datoteku
Electron ima stvarne troškove. Zauzima više prostora na disku. Njegova osnovna potrošnja memorije obično je veća od one male nativne aplikacije. Svakako postoje proizvodi za koje ti troškovi čine Electron pogrešnim izborom.
Sićušnom uslužnom programu u traci izbornika Chromium vjerojatno nije potreban. Upravljačkom programu za uređaj sigurno nije. Igre, profesionalni audiosoftver i aplikacije iznimno osjetljive na latenciju imaju drukčije zahtjeve. A ako će se vaš proizvod uvijek izvoditi samo na jednom operacijskom sustavu, nativni razvoj postaje mnogo lakše opravdati.
No golem udio modernog softvera za stolna računala ne pripada tim kategorijama.
Čine ga složena sučelja povezana s uslugama u oblaku. Mora raditi na Windowsu i macOS-u, a korisnici sve više očekuju i podršku za Linux. Mora se neprestano razvijati. Natječe se s proizvodima koji isporučuju promjene svaki tjedan. I obično ga razvija tvrtka s ograničenim brojem inženjera.
Za takve proizvode produktivnost programera dio je performansi aplikacije.
Electron tvrtki omogućuje zapošljavanje iz mnogo većeg kruga talenata, dijeljenje inženjera između weba i stolnih računala, održavanje jedne glavne aplikacije umjesto više njih, ponovno korištenje JavaScript ekosustava, dosljedniju isporuku značajki na različitim operacijskim sustavima, podršku za Linux uz trošak koji bi inače često bilo teško opravdati te ulaganje više inženjerskog vremena u poboljšanje proizvoda umjesto u održavanje paralelnih implementacija.
Trošak Electrona lako možete izmjeriti u megabajtima.
Troškove alternative teže je vidjeti. Pojavljuju se u obliku dodatnih inženjera, dupliciranih implementacija, duljih ciklusa izdavanja, pogrešaka specifičnih za platformu, poteškoća pri zapošljavanju, organizacijskih silosa, korisnika Linuxa bez podrške i značajki kojima trebaju mjeseci više da stignu do svih.
Ti troškovi nisu vidljivi u Activity Monitoru.
No za tvrtku koja razvija softver mogu biti znatno veći.
Cilj razvoja softvera nije proizvesti najmanju binarnu datoteku.
Cilj je izgraditi najbolji proizvod koji vaša organizacija može isporučivati, održavati i neprestano unapređivati.
Za iznenađujuće velik broj aplikacija za stolna računala Electron ostaje jedan od najučinkovitijih načina da se postigne upravo to.