Petrece suficient timp pe Hacker News sau Reddit și vei întâlni, în cele din urmă, aceeași critică: Electron este greoi, Electron folosește prea multă memorie, iar aplicațiile desktop serioase ar trebui să fie native.
Există un sâmbure de adevăr în această critică. Aplicațiile Electron au, în general, un consum de bază mai mare de resurse, deoarece includ Chromium și Node.js. O aplicație nativă proiectată cu grijă poate folosi mai puțină memorie, poate porni mai repede și se poate integra mai profund cu sistemul său de operare.
Dar această dezbatere se concentrează prea mult asupra calculatorului și prea puțin asupra companiei care dezvoltă software-ul.
Pentru majoritatea utilizatorilor, tehnologia din spatele unei aplicații contează foarte puțin. Îi interesează dacă funcționează, dacă răspunde rapid, dacă erorile sunt remediate și dacă apar în continuare funcționalități utile. Pentru o companie de software, una dintre cele mai importante caracteristici ale unei stive tehnologice este, așadar, ceva ce apare rareori în tabelele de teste comparative: cât de repede poate echipa să dezvolte, să livreze, să învețe și să îmbunătățească produsul?
Pentru multe aplicații desktop moderne, Electron excelează în această privință.
Resursa limitată este timpul inginerilor
Compania idealizată care dezvoltă aplicații desktop native are o echipă excelentă pentru macOS, o altă echipă care dezvoltă aplicația pentru Windows și, poate, încă o echipă care asigură suportul pentru Linux. Fiecare aplicație este optimizată cu grijă pentru platforma sa, iar fiecare inginer înțelege în profunzime sistemul de operare pentru care lucrează.
Majoritatea companiilor nu au acest lux.
Un produs desktop ar putea avea cinci ingineri. Ar putea avea doi. Aceiași ingineri trebuie să dezvolte funcționalități, să remedieze erori, să îmbunătățească performanța, să răspundă clienților, să întrețină infrastructura, să gestioneze schimbările sistemelor de operare și să continue dezvoltarea produsului.
Dezvoltarea nativă face toate acestea mai dificile, deoarece macOS, Windows și Linux sunt platforme cu adevărat diferite. Au cadre de dezvoltare diferite pentru interfețe, API-uri, sisteme de permisiuni, comportamente privind ciclul de viață al aplicațiilor, programe de instalare, mecanisme de actualizare, sisteme de notificări, gestionarea ferestrelor, API-uri de accesibilitate și particularități specifice fiecărei platforme, acumulate de-a lungul anilor.
Electron schimbă această ecuație. Combină Chromium, Node.js și API-uri desktop într-un model comun de aplicație pentru macOS, Windows și Linux. Același inginer TypeScript poate adesea să dezvolte o funcționalitate de la interfață până la logica aplicației și să o livreze pe fiecare platformă desktop. Codul nativ rămâne disponibil atunci când este cu adevărat necesar, dar devine excepția, nu fundația produsului. Electron însuși descrie acest lucru drept unul dintre avantajele sale principale: o singură bază de cod JavaScript pentru toate cele trei platforme desktop majore.
Această diferență se amplifică de-a lungul anilor. Dacă fiecare funcționalitate importantă necesită implementări separate pentru Mac și Windows, compania plătește în mod repetat acest cost suplimentar al platformelor: pentru fiecare funcționalitate, reproiectare, experiment, remediere de erori, îmbunătățire a accesibilității și optimizare a performanței.
Cu Electron, o mare parte din această muncă se face o singură dată.
Electron prioritizează viteza de iterare
Produsele devin rareori excelente pentru că prima implementare a fost perfectă. Devin excelente prin iterații.
O echipă livrează ceva. Clienții îl folosesc. Echipa învață. Modifică funcționalitatea. Mai mulți oameni o folosesc. Devine vizibilă o altă problemă. Echipa o îmbunătățește din nou.
Cu cât ciclul dintre idee, implementare, feedback și îmbunătățire este mai scurt, cu atât produsul se îmbunătățește mai repede.
Electron este deosebit de eficient în scurtarea acestui ciclu, deoarece se bazează pe tehnologii pe care companiile de software le folosesc deja peste tot: JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js și npm.
Asta înseamnă că firmele pot folosi în comun mult mai mult decât codul-sursă. Pot folosi aceiași ingineri, aceleași componente de interfață, instrumente, biblioteci, infrastructură, metode de testare și cunoștințe organizaționale pentru produsele lor web și desktop.
Un inginer frontend nu devine brusc irelevant pentru că firma are nevoie de ajutor cu clientul pentru Windows. Un inginer desktop poate contribui la aplicația web. Un inginer full-stack care folosește TypeScript poate trece de la un produs la altul pe măsură ce prioritățile se schimbă.
Pentru o companie mică sau mijlocie, această flexibilitate poate valora mult mai mult decât economisirea a 100 MB de RAM.
Uită-te cine folosește efectiv Electron
Electron este uneori descris drept o scurtătură pentru companiile care nu vor să investească într-o aplicație desktop „adevărată”. Produsele construite cu el fac acest argument tot mai greu de susținut.
Proiectul Electron însuși evidențiază produse precum Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom și Canva. Acestea nu sunt simple utilitare. Multe se numără printre cele mai sofisticate și mai folosite aplicații de productivitate din lume.
Visual Studio Code este un exemplu deosebit de util. Microsoft și-ar putea construi editorul de cod emblematic cu aproape orice tehnologie Windows dorește, și totuși VS Code folosește Electron pe Windows, macOS și Linux. Include terminale, depanare, servere de limbaj, integrare Git, dezvoltare la distanță, notebook-uri, extensii și editoare puternic personalizate.
Întrebarea interesantă nu este dacă Microsoft ar putea economisi memorie construind trei versiuni native separate. Desigur că ar putea.
Întrebarea mai bună este dacă VS Code ar fi evoluat la fel de repede, ar fi rămas la fel de consecvent între platforme și ar fi dezvoltat un ecosistem atât de mare dacă fiecare funcționalitate majoră ar fi necesitat mai multe implementări separate.
ChatGPT și Claude arată diferența de abordare
Contrastul dintre ChatGPT și Claude este, de asemenea, instructiv.
OpenAI a construit inițial o aplicație nativă dedicată pentru ChatGPT pe macOS. Anthropic, în schimb, a construit Claude Desktop cu Electron și a avut de la început o fundație desktop comună pentru toate platformele.
Această diferență a devenit mai importantă pe măsură ce produsele s-au extins. Claude Desktop a putut continua să adauge funcționalități precum integrări MCP, extensii și Claude Code în aceeași aplicație multiplatformă. Anthropic oferă acum suport pentru Claude Code direct în interfața sa desktop, inclusiv pentru mai multe sesiuni locale și la distanță.
Ulterior, OpenAI și-a orientat și noua strategie desktop multiplatformă către Electron, iar Electron enumeră acum atât ChatGPT, cât și Claude printre aplicațiile Electron importante.
Ar fi exagerat să afirmăm că Electron explică singur diferența de ritm al dezvoltării produselor. Dimensiunea echipei, prioritățile, strategia de produs și organizarea internă contează toate. Dar avantajul arhitectural este clar: o fundație comună multiplatformă face mai ușoară livrarea funcționalităților pe mai multe sisteme de operare, fără întreținerea unor implementări separate.
Acesta este exact tipul de avantaj care devine mai valoros pe măsură ce un produs desktop se dezvoltă.
Evernote a descoperit costul întreținerii unor clienți separați
Evernote este unul dintre cele mai clare exemple istorice ale acestei probleme.
Ani la rând, Evernote a întreținut aplicații diferite pentru Mac, Windows, dispozitive mobile și web. În timp, aceste produse au acumulat comportamente diferite, diferențe de randare, premise moștenite din versiuni vechi și probleme de sincronizare.
În 2020, Evernote și-a reconstruit aplicațiile pentru Windows și Mac pe o bază de cod comună. Compania a declarat că noua fundație va face aplicațiile mai stabile, va permite remedierea mai rapidă a erorilor, va facilita livrarea mai frecventă a funcționalităților și va îmbunătăți sincronizarea între platforme.
Acea migrare nu a fost lipsită de dificultăți, iar unor utilizatori de lungă durată nu le-a plăcut pierderea inițială a funcționalităților specifice platformelor. Dar motivul pentru care Evernote a întreprins o rescriere atât de costisitoare este mai interesant decât problemele migrării în sine.
Odată ce un produs are un editor complex, stocare offline, căutare, atașamente, colaborare, sarcini, calendare și sincronizare complexă, întreținerea mai multor implementări independente devine tot mai costisitoare. Erorile se manifestă diferit. Randarea diferă. Logica de sincronizare interacționează cu arhitecturi locale diferite. Fiecare schimbare importantă a produsului trebuie propagată în mai mulți clienți.
O arhitectură comună nu face problemele dificile să dispară. Îi permite companiei să rezolve mai multe dintre ele o singură dată.
Linux poate fi avantajul cel mai subestimat al Electron
Linux face argumentele în favoarea Electron și mai puternice.
Este dificil să oferi suport adecvat pentru Linux. Spre deosebire de macOS sau Windows, „desktopul Linux” nu este o singură platformă strict controlată. Dezvoltatorii trebuie să gestioneze distribuții, formate de pachete, medii desktop, stive grafice, biblioteci de sistem și protocoale de afișare diferite.
Pentru multe companii de software, decizia rațională din punct de vedere comercial ar fi pur și simplu să nu ofere suport pentru Linux.
Electron schimbă calculele economice.
Deoarece Electron oferă un mediu de execuție comun pentru macOS, Windows și Linux, adăugarea suportului pentru Linux poate fi mult mai ușoară decât întreținerea unei implementări native separate pentru Linux. Acesta este unul dintre motivele pentru care utilizatorii Linux au astăzi acces la multe aplicații desktop importante care, în trecut, poate că nu ar fi primit niciodată un client oficial pentru Linux.
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian și multe alte instrumente pot oferi suport pentru Linux fără să întrețină o aplicație GTK sau Qt complet separată.
Electron preia și o mare parte din complexitatea specifică Linux în locul dezvoltatorilor de aplicații. Un exemplu bun este trecerea de la X11 la Wayland. Cei care întrețin Electron au descris cum tranziția Chromium la Wayland a antrenat, în practică, și aplicațiile Electron, reducând cantitatea de muncă legată de stiva de afișare pe care fiecare echipă de aplicație trebuia să o facă independent.
Fără cadre de dezvoltare precum Electron, multe companii nu ar construi clienți nativi pentru Linux. Ar oferi pur și simplu suport pentru macOS și Windows și i-ar lăsa pe utilizatorii Linux cu o filă de browser.
Probabil că Electron a făcut mai mult pentru software-ul desktop comercial pe Linux decât i se recunoaște.
Chiar și Microsoft alege tot mai des tehnologiile web
Microsoft este probabil cel mai puternic contraexemplu la ideea că software-ul serios pentru Windows ar trebui să folosească întotdeauna cadre native Windows pentru interfețe.
Microsoft controlează Windows. Controlează Win32, .NET, WinUI, WebView2 și o mare parte din platforma pe care dezvoltatorii construiesc. Dacă dezvoltarea complet nativă pentru Windows ar fi întotdeauna răspunsul evident, Microsoft s-ar afla în cea mai bună poziție posibilă pentru a o folosi peste tot.
Nu o face.
Visual Studio Code folosește Electron. Teams rămâne construit în jurul React, TypeScript și Chromium chiar și după ce Microsoft a înlocuit Electron cu o gazdă WebView2 mai bine optimizată. Noul Outlook pentru Windows se bazează, de asemenea, în mare măsură pe tehnologii web, iar Microsoft descrie explicit această arhitectură ca pe o modalitate de a îmbunătăți agilitatea, de a permite livrarea mai rapidă a funcționalităților și de a crea o experiență mai consecventă.
Teams este deosebit de instructiv. Microsoft a vrut să îmbunătățească performanța și să reducă consumul de resurse, așa că a schimbat arhitectura. Dar nu a rescris interfața ca pe o aplicație tradițională nativă pentru Windows.
A păstrat stiva web și a optimizat în jurul ei.
Această distincție contează. Microsoft a decis că avantajele organizaționale ale React, TypeScript și Chromium meritau păstrate chiar și în timp ce îmbunătățea agresiv performanța.
Mai există și o altă lecție aici. Microsoft însuși a introdus de-a lungul anilor multe generații de tehnologii pentru aplicații Windows: Win32, WPF, UWP, WinUI și altele. O companie care alege „Windows nativ” nu alege neapărat o platformă atemporală. Adesea, pariază pe o anumită generație a cadrului de dezvoltare preferat de Microsoft.
În mod oarecum ironic, platforma web a devenit una dintre cele mai stabile platforme disponibile pentru dezvoltarea aplicațiilor.
Recrutarea face parte din arhitectură
Alegerea cadrelor de dezvoltare determină și pe cine poți angaja.
Dezvoltatorii JavaScript și TypeScript reprezintă una dintre cele mai mari comunități de specialiști din industrie. O companie care dezvoltă cu Electron poate recruta din această comunitate, în loc să aibă nevoie de echipe separate de specialiști experimentați în macOS, Windows și Linux.
Specialiștii în dezvoltare nativă rămân valoroși. Produsele desktop serioase au în continuare nevoie de ingineri care înțeleg în profunzime sistemele de operare. Dar Electron schimbă numărul de specialiști de care ai nevoie.
În loc ca cea mai mare parte a aplicației să trebuiască dezvoltată de experți în platforme, poți păstra o cantitate relativ mică de cod de integrare nativă și poți lăsa majoritatea echipei să lucreze la produsul comun.
Acest lucru contează și mai mult atunci când o companie are deja o aplicație web. Componentele React pot fi uneori folosite în comun. Bibliotecile TypeScript pot fi reutilizate. Logica produsului poate fi transferată între web și desktop. Inginerii pot schimba echipele fără să învețe un ecosistem complet diferit.
Și recrutarea devine mai puțin vulnerabilă. Dacă singurul inginer care înțelege în profunzime clientul tău nativ pentru Windows pleacă, înlocuirea acelei expertize poate fi dificilă. Cu Electron, o parte mult mai mare din baza de cod folosește tehnologii familiare restului organizației.
Prin urmare, un cadru de dezvoltare nu determină doar modul în care este randată o interfață. Influențează și modul în care poate fi structurată organizația de inginerie însăși.
Nativ nu înseamnă automat software mai bun
Dezvoltatorii folosesc adesea „nativ” aproape ca sinonim pentru „rapid”.
Nu este.
API-urile native le oferă dezvoltatorilor posibilitatea de a crea o aplicație foarte eficientă. Dacă produsul final chiar atinge acest obiectiv depinde de arhitectură, echipă, buget și volumul de muncă de optimizare pe care compania și-l poate permite.
O aplicație nativă poate fi în continuare lentă, plină de erori, mare consumatoare de memorie, inconsecventă sau prost întreținută.
Mai important, împărțirea unei echipe limitate între mai multe implementări native înseamnă că fiecare implementare primește mai puține ore de muncă din partea inginerilor.
Imaginează-ți că o companie are șase ingineri disponibili pentru produsul său desktop. O opțiune este să îi împartă între Mac și Windows, poate lăsând Linux fără suport. O alta este să aloce aproape toți cei șase ingineri unei singure aplicații Electron comune, care deservește toate cele trei platforme.
Care abordare îi oferă companiei o capacitate mai mare de inginerie pentru a îmbunătăți timpul de pornire, a remedia pierderile de memorie, a rafina interacțiunile, a îmbunătăți accesibilitatea, a reduce închiderile neașteptate și a răspunde utilizatorilor?
Nu este evident că aplicațiile native duc la un produs mai bun.
Acest lucru creează un paradox interesant: un cadru de dezvoltare care consumă ceva mai multe resurse ale calculatorului poate permite unei companii să construiască un produs mai bine optimizat, deoarece consumă mult mai puține resurse de inginerie.
Electron îți oferă o platformă controlată
Electron mai are un avantaj ușor de trecut cu vederea: include mediul de execuție Chromium pentru care aplicația a fost construită și testată.
Asta elimină o variabilă importantă din dezvoltarea multiplatformă.
Cadrele de dezvoltare bazate pe componentele webview ale sistemelor de operare pot produce aplicații mai mici, dar compromisul este că aceeași interfață frontend poate rula pe WebView2 în Windows, WKWebView în macOS și WebKitGTK în Linux. Aceste motoare au capacități, erori, calendare de lansare și comportamente de randare diferite.
Electron face un alt compromis: include mediul de execuție și îl transformă într-o parte a aplicației.
Da, asta ocupă spațiu pe disc.
Dar le oferă dezvoltatorilor o platformă-țintă mult mai consecventă pe trei sisteme de operare foarte diferite.
Consecvența are o valoare enormă pentru inginerie.
Când Electron nu este suficient, poți folosi în continuare cod nativ
Alegerea Electron nu înseamnă renunțarea la accesul la funcționalități native.
Aplicațiile Electron pot folosi module native și cod specific platformei acolo unde este necesar. Asta înseamnă că alegerea arhitecturală nu este, de fapt:
100% nativ sau 100% JavaScript.
Pentru multe produse, un model mai bun este:
cea mai mare parte a aplicației este comună, cu o cantitate mică de cod nativ acolo unde sistemul de operare îl impune cu adevărat.
Codul nativ devine o soluție de rezervă, nu fundația întregului produs.
Pentru multe companii, aceasta este o alocare mult mai bună a efortului de inginerie.
Utilizatorilor le pasă de produse, nu de cadrele de dezvoltare
Există un mic grup de utilizatori cu cunoștințe tehnice avansate care deschid Monitor activitate, observă mai multe procese Chromium și se plâng imediat că o aplicație folosește Electron.
Majoritatea utilizatorilor nu fac asta.
Nu le pasă că Slack folosește Electron. Nu le pasă că VS Code este construit cu tehnologii web. Nu știu ce cadru de dezvoltare folosește Claude. Îi interesează dacă software-ul îi ajută să își facă treaba.
Dacă o aplicație pornește suficient de repede, răspunde prompt, se închide neașteptat doar rareori și rezolvă problema utilizatorului, tehnologia de implementare este în mare parte invizibilă.
Și contrariul este la fel de adevărat. O aplicație nativă nu devine automat un produs bun pentru că folosește Swift sau WinUI.
Software-ul concurează la nivel de produs, nu la nivel de cadru de dezvoltare.
Optimizează compania, nu doar fișierul binar
Electron are costuri reale. Folosește mai mult spațiu pe disc. Consumul său de bază de memorie este de obicei mai mare decât cel al unei aplicații native mici. Cu siguranță există produse pentru care aceste costuri fac din Electron alegerea greșită.
Un mic utilitar pentru bara de meniu probabil nu are nevoie de Chromium. Un driver de dispozitiv cu siguranță nu are. Jocurile, software-ul audio profesional și aplicațiile extrem de sensibile la latență au alte cerințe. Iar dacă produsul tău va rula întotdeauna pe un singur sistem de operare, dezvoltarea nativă devine mult mai ușor de justificat.
Dar o proporție uriașă din software-ul desktop modern nu se încadrează în aceste categorii.
Este vorba despre interfețe complexe conectate la servicii cloud. Trebuie să ruleze pe Windows și macOS, iar utilizatorii se așteaptă tot mai mult și la suport pentru Linux. Trebuie să evolueze continuu. Concurează cu produse care livrează schimbări în fiecare săptămână. Și, de obicei, este construit de o companie cu un număr limitat de ingineri.
Pentru aceste produse, productivitatea dezvoltatorilor face parte din performanța aplicației.
Electron permite unei companii să recruteze dintr-o comunitate mult mai mare de specialiști, să folosească aceiași ingineri pentru web și desktop, să întrețină o singură aplicație principală în loc de mai multe, să reutilizeze ecosistemul JavaScript, să livreze funcționalități mai consecvent pe mai multe sisteme de operare, să ofere suport pentru Linux la un cost care altfel ar fi adesea greu de justificat și să dedice mai mult timp de inginerie îmbunătățirii produsului, în loc să întrețină implementări paralele.
Poți măsura ușor costul Electron în megaocteți.
Costurile alternative sunt mai greu de observat. Apar sub forma unor ingineri suplimentari, implementări duplicate, cicluri de lansare mai lungi, erori specifice platformelor, dificultăți de recrutare, compartimente organizaționale izolate, utilizatori Linux fără suport și funcționalități care ajung la toată lumea cu luni întârziere.
Aceste costuri nu apar în Monitor activitate.
Dar, pentru compania care construiește software-ul, ele pot fi considerabil mai mari.
Scopul dezvoltării software nu este să producă cel mai mic fișier binar.
Este să construiască cel mai bun produs pe care organizația ta îl poate livra, întreține și îmbunătăți continuu.
Pentru o categorie surprinzător de largă de aplicații desktop, Electron rămâne una dintre cele mai eficiente modalități de a face exact acest lucru.