Vietä tarpeeksi aikaa Hacker Newsissä tai Redditissä, niin törmäät lopulta samaan kritiikkiin: Electron on raskas, Electron käyttää liikaa muistia, ja vakavasti otettavien työpöytäsovellusten pitäisi olla natiiveja.
Kritiikissä on jonkin verran perää. Electron-sovellusten perusresurssitarve on yleensä suurempi, koska niiden mukana toimitetaan Chromium ja Node.js. Huolellisesti suunniteltu natiivisovellus voi käyttää vähemmän muistia, käynnistyä nopeammin ja integroitua syvemmin käyttöjärjestelmäänsä.
Mutta tässä keskustelussa keskitytään liikaa tietokoneeseen ja liian vähän ohjelmistoa kehittävään yritykseen.
Useimmille käyttäjille sovelluksen taustalla olevalla teknologialla on tuskin merkitystä. Heitä kiinnostaa, toimiiko se, tuntuuko se reagoivan nopeasti, korjataanko virheet ja tuleeko siihen jatkuvasti hyödyllisiä ominaisuuksia. Ohjelmistoyritykselle yksi teknologiapinon tärkeimmistä ominaisuuksista onkin asia, jota suorituskykyvertailujen taulukoissa harvoin näkyy: kuinka nopeasti tiimi pystyy rakentamaan ja julkaisemaan tuotetta, oppimaan ja parantamaan sitä?
Monissa nykyaikaisissa työpöytäsovelluksissa Electron on tässä poikkeuksellisen hyvä.
Niukka resurssi on kehittäjien aika
Ihanteellisella natiiveja työpöytäsovelluksia kehittävällä yrityksellä on erinomainen macOS-tiimi, toinen tiimi rakentamassa Windows-sovellusta ja kenties vielä yksi tiimi huolehtimassa Linux-tuesta. Jokainen sovellus on optimoitu huolellisesti alustalleen, ja jokainen kehittäjä tuntee syvällisesti käyttöjärjestelmän, jonka parissa työskentelee.
Useimmilla yrityksillä ei ole tähän ylellisyyteen varaa.
Työpöytätuotteen parissa saattaa työskennellä viisi kehittäjää. Tai kaksi. Samojen kehittäjien on rakennettava ominaisuuksia, korjattava virheitä, parannettava suorituskykyä, vastattava asiakkaille, ylläpidettävä infrastruktuuria, mukauduttava käyttöjärjestelmien muutoksiin ja vietävä tuotetta eteenpäin.
Natiivikehitys tekee tästä vaikeampaa, koska macOS, Windows ja Linux ovat aidosti erilaisia alustoja. Niillä on erilaiset käyttöliittymäkehykset, rajapinnat, käyttöoikeusjärjestelmät, sovelluksen elinkaaren toimintatavat, asennusohjelmat, päivitysmekanismit, ilmoitusjärjestelmät, ikkunanhallinta, saavutettavuusrajapinnat ja vuosien saatossa kertyneet alustakohtaiset erikoisuudet.
Electron muuttaa tätä yhtälöä. Se yhdistää Chromiumin, Node.js:n ja työpöytärajapinnat yhteiseksi sovellusmalliksi macOS:lle, Windowsille ja Linuxille. Sama TypeScript-kehittäjä voi usein rakentaa ominaisuuden käyttöliittymästä sovelluslogiikkaan asti ja julkaista sen kaikille työpöytäalustoille. Natiivikoodia voi edelleen käyttää silloin, kun sitä todella tarvitaan, mutta siitä tulee poikkeus tuotteen perustan sijaan. Electron itse kuvaa tätä yhdeksi keskeisistä eduistaan: yksi JavaScript-koodipohja kaikille kolmelle tärkeimmälle työpöytäalustalle.
Tämän eron vaikutukset kumuloituvat vuosien mittaan. Jos jokainen merkittävä ominaisuus vaatii erilliset Mac- ja Windows-toteutukset, yritys maksaa tätä alustalisää yhä uudelleen: jokaisesta ominaisuudesta, uudelleensuunnittelusta, kokeilusta, virheenkorjauksesta, saavutettavuusparannuksesta ja suorituskyvyn optimoinnista.
Electronilla suuri osa tästä työstä tehdään vain kerran.
Electron optimoi kehityskierrosten nopeutta
Tuotteista tulee harvoin erinomaisia siksi, että ensimmäinen toteutus oli täydellinen. Niistä tulee erinomaisia toistuvien kehityskierrosten kautta.
Tiimi julkaisee jotakin. Asiakkaat käyttävät sitä. Tiimi oppii. Se muuttaa ominaisuutta. Yhä useammat käyttävät sitä. Toinen ongelma tulee näkyviin. Tiimi parantaa sitä jälleen.
Mitä lyhyempi kierros ideasta toteutukseen, palautteeseen ja parannukseen on, sitä nopeammin tuote kehittyy.
Electron on poikkeuksellisen hyvä lyhentämään tätä kierrosta, koska se rakentuu teknologioille, joita ohjelmistoyritykset käyttävät jo kaikkialla: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js ja npm.
Tämä tarkoittaa, että yritykset voivat jakaa paljon muutakin kuin lähdekoodia. Ne voivat hyödyntää samoja kehittäjiä, käyttöliittymäkomponentteja, työkaluja, kirjastoja, infrastruktuuria, testausmenetelmiä ja organisaation osaamista verkko- ja työpöytätuotteissaan.
Frontend-kehittäjän osaaminen ei yhtäkkiä muutu hyödyttömäksi, kun yritys tarvitsee apua Windows-asiakassovelluksen kanssa. Työpöytäkehittäjä voi osallistua verkkosovelluksen kehittämiseen. Full stack -TypeScript-kehittäjä voi siirtyä tuotteesta toiseen prioriteettien muuttuessa.
Pienelle tai keskisuurelle yritykselle tämä joustavuus voi olla paljon arvokkaampaa kuin 100 megatavun säästö RAM-muistissa.
Katso, ketkä Electronia oikeasti käyttävät
Electronia kuvataan joskus oikotieksi yrityksille, jotka eivät halua investoida ”kunnolliseen” työpöytäsovellukseen. Sillä rakennetut tuotteet tekevät tästä väitteestä yhä vaikeammin puolustettavan.
Electron-projekti itse nostaa esiin tuotteita kuten Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom ja Canva. Nämä eivät ole yksinkertaisia apuohjelmia. Monet niistä kuuluvat maailman kehittyneimpiin ja käytetyimpiin tuottavuussovelluksiin.
Visual Studio Code on erityisen hyödyllinen esimerkki. Microsoft voisi rakentaa lippulaivakoodieditorinsa käytännössä millä tahansa haluamallaan Windows-teknologialla, mutta silti VS Code käyttää Electronia Windowsissa, macOS:ssä ja Linuxissa. Se sisältää päätteitä, virheenjäljityksen, kielipalvelimia, Git-integraation, etäkehityksen, muistikirjoja, laajennuksia ja pitkälle räätälöityjä editoreita.
Kiinnostava kysymys ei ole se, voisiko Microsoft säästää muistia rakentamalla kolme erillistä natiiviversiota. Tietenkin voisi.
Parempi kysymys on, olisiko VS Code kehittynyt yhtä nopeasti, säilynyt yhtä yhtenäisenä eri alustoilla ja kasvattanut ympärilleen yhtä suuren ekosysteemin, jos jokainen merkittävä toiminto olisi vaatinut useita erillisiä toteutuksia.
ChatGPT ja Claude havainnollistavat lähestymistapojen eroa
Myös ChatGPT:n ja Clauden välinen ero on opettavainen.
OpenAI rakensi ChatGPT:lle aluksi oman natiivin macOS-sovelluksen. Anthropic puolestaan rakensi Claude Desktopin Electronin päälle, joten sillä oli alusta lähtien yhteinen työpöytäsovelluksen perusta eri alustoille.
Tämän eron merkitys kasvoi tuotteiden laajentuessa. Claude Desktopiin voitiin lisätä jatkuvasti toimintoja, kuten MCP-integraatioita, laajennuksia ja Claude Code, samaan monialustaiseen sovellukseen. Anthropic tukee nyt Claude Codea suoraan työpöytäsovelluksessaan, mukaan lukien useita paikallisia ja etäistuntoja.
Myöhemmin myös OpenAI alkoi suunnata uudempaa monialustaista työpöytäkehitystään Electroniin, ja Electron listaa nyt sekä ChatGPT:n että Clauden tunnettujen Electron-sovellusten joukkoon.
Olisi liioittelua väittää, että Electron yksin selittää eron tuotekehityksen vauhdissa. Tiimin koko, prioriteetit, tuotestrategia ja sisäinen organisaatio vaikuttavat kaikki. Arkkitehtuurin etu on silti selvä: yhteinen monialustainen perusta helpottaa ominaisuuksien julkaisemista eri käyttöjärjestelmille ilman erillisten toteutusten ylläpitoa.
Juuri tällainen etu muuttuu entistä arvokkaammaksi työpöytätuotteen kasvaessa.
Evernote oppi, mitä erillisten asiakassovellusten ylläpito maksaa
Evernote on yksi selkeimmistä historiallisista esimerkeistä tästä ongelmasta.
Evernote ylläpiti vuosien ajan erillisiä sovelluksia Macille, Windowsille, mobiililaitteille ja verkkoon. Ajan myötä tuotteisiin kertyi erilaisia toimintatapoja, eroja sisällön esittämisessä, vanhoihin ratkaisuihin perustuvia oletuksia ja synkronointiongelmia.
Vuonna 2020 Evernote rakensi Windows- ja Mac-sovelluksensa uudelleen yhteisen koodipohjan varaan. Yrityksen mukaan uusi perusta tekisi sovelluksista vakaampia, mahdollistaisi virheiden nopeamman korjaamisen, tihentäisi uusien ominaisuuksien julkaisutahtia ja parantaisi alustojen välistä synkronointia.
Siirtymä ei ollut kivuton, ja jotkut pitkäaikaiset käyttäjät eivät pitäneet siitä, että alustakohtaisia ominaisuuksia aluksi katosi. Mutta syy siihen, miksi Evernote ryhtyi näin kalliiseen uudelleenkirjoitukseen, on kiinnostavampi kuin itse siirtymän ongelmat.
Kun tuotteessa on monipuolinen editori, offline-tallennus, haku, liitteet, yhteistyöominaisuuksia, tehtäviä, kalentereita ja monimutkainen synkronointi, useiden itsenäisten toteutusten ylläpito käy yhä kalliimmaksi. Virheet ilmenevät eri tavoin. Sisältö piirtyy eri tavalla. Synkronointilogiikka toimii yhdessä erilaisten paikallisten arkkitehtuurien kanssa. Jokainen merkittävä tuotemuutos on vietävä useaan asiakassovellukseen.
Yhteinen arkkitehtuuri ei saa vaikeita ongelmia katoamaan. Sen avulla yritys voi ratkaista useampia niistä vain kerran.
Linux voi olla Electronin aliarvostetuin etu
Linux tekee Electronin puolesta puhuvista perusteluista vielä vahvempia.
Linuxin kunnollinen tukeminen on vaikeaa. Toisin kuin macOS tai Windows, ”Linux-työpöytä” ei ole yksi tiukasti hallittu alusta. Kehittäjien on huomioitava erilaiset jakelut, pakettimuodot, työpöytäympäristöt, grafiikkapinot, järjestelmäkirjastot ja näyttöprotokollat.
Monille ohjelmistoyrityksille järkevä liiketoimintapäätös olisi yksinkertaisesti jättää Linux tukematta.
Electron muuttaa taloudellisia edellytyksiä.
Koska Electron tarjoaa yhteisen suoritusympäristön macOS:lle, Windowsille ja Linuxille, Linux-tuen lisääminen voi olla huomattavasti helpompaa kuin erillisen natiivin Linux-toteutuksen ylläpito. Tämä on yksi syy siihen, miksi Linux-käyttäjillä on nykyään käytettävissään monia merkittäviä työpöytäsovelluksia, joille ei aiemmin ehkä olisi koskaan tehty virallista Linux-asiakassovellusta.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian ja monet muut työkalut voivat tukea Linuxia ylläpitämättä kokonaan erillistä GTK- tai Qt-sovellusta.
Electron myös hoitaa suuren osan Linux-kohtaisesta monimutkaisuudesta sovelluskehittäjien puolesta. Hyvä esimerkki on siirtymä X11:stä Waylandiin. Electronin ylläpitäjät ovat kuvanneet, kuinka Chromiumin siirtyminen Waylandiin toi käytännössä Electron-sovellukset mukanaan ja vähensi näyttöjärjestelmään liittyvää työtä, jota kunkin sovellustiimin piti tehdä erikseen.
Ilman Electronin kaltaisia ohjelmistokehyksiä monet yritykset eivät rakentaisi natiiveja Linux-asiakassovelluksia. Ne vain tukisivat macOS:ää ja Windowsia ja jättäisivät Linux-käyttäjät selainvälilehden varaan.
Electron on luultavasti tehnyt kaupallisten Linux-työpöytäohjelmistojen hyväksi enemmän kuin sille annetaan tunnustusta.
Jopa Microsoft valitsee yhä useammin verkkoteknologian
Microsoft on kenties vahvin vastaesimerkki ajatukselle, että vakavasti otettavan Windows-ohjelmiston pitäisi aina käyttää natiiveja Windows-käyttöliittymäkehyksiä.
Microsoft hallitsee Windowsia. Se hallitsee Win32:ta, .NETiä, WinUI:ta, WebView2:ta ja suurta osaa alustasta, jonka päälle kehittäjät rakentavat. Jos täysin natiivi Windows-kehitys olisi aina ilmiselvä vastaus, Microsoftilla olisi parhaat mahdolliset edellytykset käyttää sitä kaikkialla.
Se ei tee niin.
Visual Studio Code käyttää Electronia. Teams rakentuu edelleen Reactin, TypeScriptin ja Chromiumin varaan, vaikka Microsoft korvasi Electronin paremmin optimoidulla WebView2-isäntäsovelluksella. Myös uusi Outlook for Windows tukeutuu vahvasti verkkoteknologiaan, ja Microsoft kuvaa tätä arkkitehtuuria nimenomaan keinoksi parantaa ketteryyttä, nopeuttaa ominaisuuksien toimittamista ja luoda yhtenäisempi käyttökokemus.
Teams on erityisen opettavainen esimerkki. Microsoft halusi parantaa suorituskykyä ja vähentää resurssien kulutusta, joten se muutti arkkitehtuuria. Se ei kuitenkaan kirjoittanut käyttöliittymää uudelleen perinteiseksi natiiviksi Windows-sovellukseksi.
Se säilytti verkkoteknologiapinon ja optimoi sen ympärillä.
Tämä ero on olennainen. Microsoft päätti, että Reactin, TypeScriptin ja Chromiumin organisatoriset edut kannatti säilyttää samalla, kun suorituskykyä parannettiin määrätietoisesti.
Tässä on toinenkin opetus. Microsoft itse on tuonut vuosien mittaan käyttöön useita Windows-sovellusteknologian sukupolvia: Win32:n, WPF:n, UWP:n, WinUI:n ja muita. ”Natiivin Windowsin” valitseva yritys ei välttämättä valitse ajatonta alustaa. Usein se lyö vetoa Microsoftin suosiman ohjelmistokehyksen yhden sukupolven puolesta.
Verkkoalustasta on hieman ironisesti tullut yksi vakaammista tarjolla olevista sovellusten kohdealustoista.
Rekrytointi on osa arkkitehtuuria
Ohjelmistokehysten valinnat määrittävät myös sen, keitä voit palkata.
JavaScript- ja TypeScript-kehittäjät muodostavat yhden alan suurimmista kehittäjien osaajapooleista. Electronilla rakentava yritys voi rekrytoida tästä joukosta sen sijaan, että tarvitsisi erilliset tiimit kokeneita macOS-, Windows- ja Linux-asiantuntijoita.
Natiivikehityksen asiantuntijat ovat edelleen arvokkaita. Vaativat työpöytätuotteet tarvitsevat yhä kehittäjiä, jotka ymmärtävät käyttöjärjestelmiä syvällisesti. Mutta Electron muuttaa sitä, kuinka monta asiantuntijaa tarvitaan.
Sen sijaan, että suurimman osan sovelluksesta pitäisi olla alustakohtaisten asiantuntijoiden rakentama, voit pitää natiivin integraatiokoodin määrän suhteellisen pienenä ja antaa tiimin enemmistön työskennellä yhteisen tuotteen parissa.
Tämä on vielä tärkeämpää silloin, kun yrityksellä on jo verkkosovellus. React-komponentteja voidaan joskus käyttää yhteisesti. TypeScript-kirjastoja voidaan hyödyntää uudelleen. Tuotelogiikka voi siirtyä verkon ja työpöydän välillä. Kehittäjät voivat vaihtaa tiimiä opettelematta kokonaan erilaista ekosysteemiä.
Myös rekrytoinnin haavoittuvuus vähenee. Jos ainoa natiivin Windows-asiakassovelluksesi syvällisesti tunteva kehittäjä lähtee, hänen osaamisensa korvaaminen voi olla vaikeaa. Electronilla paljon suurempi osa koodipohjasta käyttää muulle organisaatiolle tuttuja teknologioita.
Ohjelmistokehys ei siis määrää pelkästään sitä, miten käyttöliittymä piirretään. Se vaikuttaa siihen, miten itse kehitysorganisaatio voidaan rakentaa.
Natiivi ei automaattisesti tarkoita parempaa ohjelmistoa
Kehittäjät käyttävät usein sanaa ”natiivi” melkein sanan ”nopea” synonyymina.
Sitä se ei ole.
Natiivit rajapinnat antavat kehittäjille mahdollisuuden luoda erittäin tehokkaan sovelluksen. Se, saavuttaako lopputuote tämän todella, riippuu arkkitehtuurista, tiimistä, budjetista ja siitä, kuinka paljon yrityksellä on varaa panostaa optimointityöhön.
Natiivisovellus voi silti olla hidas, virhealtis, muistisyöppö, epäyhtenäinen tai huonosti ylläpidetty.
Vielä tärkeämpää on, että rajallisen tiimin jakaminen usean natiivin toteutuksen kesken tarkoittaa, että jokainen toteutus saa vähemmän kehittäjien työtunteja.
Kuvittele, että yrityksellä on kuusi kehittäjää käytettävissä työpöytätuotteeseensa. Yksi vaihtoehto on jakaa heidät Macin ja Windowsin kesken ja kenties jättää Linux ilman tukea. Toinen on antaa lähes kaikkien kuuden työskennellä yhden yhteisen Electron-sovelluksen parissa, joka palvelee kaikkia kolmea alustaa.
Kumpi lähestymistapa antaa yritykselle enemmän kehityskapasiteettia lyhentää käynnistysaikaa, korjata muistivuotoja, hioa vuorovaikutusta, parantaa saavutettavuutta, vähentää kaatumisia ja reagoida käyttäjien tarpeisiin?
Ei ole itsestään selvää, että natiivisovelluksista syntyy parempi tuote.
Tästä syntyy kiinnostava paradoksi: ohjelmistokehys, joka kuluttaa jonkin verran enemmän koneen resursseja, voi auttaa yritystä rakentamaan paremmin optimoidun tuotteen, koska se kuluttaa huomattavasti vähemmän kehitysresursseja.
Electron antaa hallitun alustan
Electronilla on myös toinen helposti huomaamatta jäävä etu: sen mukana toimitetaan se Chromium-suoritusympäristö, jota vasten sovellus on rakennettu ja testattu.
Tämä poistaa yhden merkittävän muuttujan monialustaisesta kehityksestä.
Käyttöjärjestelmän webview-komponentteihin perustuvat ohjelmistokehykset voivat tuottaa pienempiä sovelluksia, mutta vastineeksi sama frontend saattaa toimia Windowsissa WebView2:n, macOS:ssä WKWebView’n ja Linuxissa WebKitGTK:n päällä. Näillä moottoreilla on erilaiset ominaisuudet, virheet, julkaisuaikataulut ja renderöintikäyttäytyminen.
Electron tekee toisenlaisen kompromissin: se paketoi suoritusympäristön mukaan ja tekee siitä osan sovellusta.
Kyllä, se vie levytilaa.
Mutta se antaa kehittäjille huomattavasti yhtenäisemmän kohdealustan kolmessa hyvin erilaisessa käyttöjärjestelmässä.
Yhtenäisyydellä on valtava arvo kehitystyössä.
Kun Electron ei riitä, voit silti käyttää natiivikoodia
Electronin valitseminen ei tarkoita natiiviominaisuuksista luopumista.
Electron-sovellukset voivat tarvittaessa käyttää natiiveja moduuleja ja alustakohtaista koodia. Arkkitehtuurivalinta ei siis oikeastaan ole:
100 % natiivia tai 100 % JavaScriptiä.
Monille tuotteille parempi malli on:
suurin osa sovelluksesta yhteistä koodia ja pieni määrä natiivikoodia siellä, missä käyttöjärjestelmä sitä aidosti vaatii.
Natiivikoodista tulee varareitti koko tuotteen perustan sijaan.
Monille yrityksille tämä on huomattavasti parempi tapa kohdentaa kehitystyötä.
Käyttäjiä kiinnostavat tuotteet, eivät ohjelmistokehykset
On olemassa pieni joukko teknisesti valveutuneita käyttäjiä, jotka avaavat Järjestelmän valvonnan, huomaavat useita Chromium-prosesseja ja valittavat heti siitä, että sovellus käyttää Electronia.
Useimmat käyttäjät eivät tee niin.
Heitä ei kiinnosta, että Slack käyttää Electronia. Heitä ei kiinnosta, että VS Code on rakennettu verkkoteknologioilla. He eivät tiedä, mitä ohjelmistokehystä Claude käyttää. Heitä kiinnostaa, auttaako ohjelmisto heitä saamaan työnsä tehtyä.
Jos sovellus käynnistyy riittävän nopeasti, tuntuu reagoivan nopeasti, kaatuu harvoin ja ratkaisee käyttäjän ongelman, toteutusteknologia on suurelta osin näkymätön.
Myös päinvastainen pitää paikkansa. Natiivisovelluksesta ei automaattisesti tule hyvää tuotetta siksi, että se käyttää Swiftiä tai WinUI:ta.
Ohjelmistot kilpailevat tuotteina, eivät ohjelmistokehysten tasolla.
Optimoi yritys, älä vain ohjelmatiedostoa
Electronilla on todellisia kustannuksia. Se käyttää enemmän levytilaa. Sen perusmuistinkulutus on yleensä suurempi kuin pienen natiivisovelluksen. On ehdottomasti tuotteita, joissa nämä kustannukset tekevät Electronista väärän valinnan.
Pieni valikkorivin apuohjelma ei luultavasti tarvitse Chromiumia. Laiteajuri ei varmasti tarvitse. Peleillä, ammattimaisilla ääniohjelmistoilla ja erittäin viiveherkillä sovelluksilla on erilaiset vaatimukset. Ja jos tuotteesi toimii aina vain yhdessä käyttöjärjestelmässä, natiivikehitys on paljon helpompi perustella.
Mutta valtava osa nykyaikaisista työpöytäohjelmistoista ei kuulu näihin luokkiin.
Ne koostuvat monimutkaisista käyttöliittymistä, jotka ovat yhteydessä pilvipalveluihin. Niiden on toimittava Windowsissa ja macOS:ssä, ja yhä useammin käyttäjät odottavat myös Linux-tukea. Niiden on kehityttävä jatkuvasti. Ne kilpailevat tuotteiden kanssa, jotka julkaisevat muutoksia joka viikko. Ja yleensä niitä rakentaa yritys, jolla on rajallinen määrä kehittäjiä.
Näissä tuotteissa kehittäjien tuottavuus on osa sovelluksen suorituskykyä.
Electron antaa yritykselle mahdollisuuden rekrytoida paljon suuremmasta osaajajoukosta, käyttää samoja kehittäjiä verkko- ja työpöytätuotteissa, ylläpitää yhtä pääsovellusta useiden sijaan, hyödyntää JavaScript-ekosysteemiä, julkaista ominaisuuksia eri käyttöjärjestelmille yhtenäisemmin, tukea Linuxia kustannuksilla, joita olisi muuten usein vaikea perustella, ja käyttää enemmän kehitysaikaa tuotteen parantamiseen rinnakkaisten toteutusten ylläpidon sijaan.
Electronin kustannukset on helppo mitata megatavuina.
Vaihtoehdon kustannuksia on vaikeampi nähdä. Ne näkyvät lisäkehittäjinä, päällekkäisinä toteutuksina, pidempinä julkaisusykleinä, alustakohtaisina virheinä, rekrytointivaikeuksina, organisaation siiloina, ilman tukea jäävinä Linux-käyttäjinä ja ominaisuuksina, joiden saapuminen kaikille kestää kuukausia pidempään.
Nämä kustannukset eivät näy Järjestelmän valvonnassa.
Mutta ohjelmistoa rakentavalle yritykselle ne voivat olla huomattavasti suurempia.
Ohjelmistokehityksen tavoitteena ei ole tuottaa pienintä ohjelmatiedostoa.
Tavoitteena on rakentaa paras tuote, jonka organisaatiosi pystyy julkaisemaan, ylläpitämään ja jota se pystyy jatkuvasti parantamaan.
Yllättävän laajassa joukossa työpöytäsovelluksia Electron on edelleen yksi tehokkaimmista tavoista tehdä juuri niin.