De Electron val: waarom veel desktop-apps niet aanvoelen zoals desktop-apps horen aan te voelen

Wees even eerlijk met jezelf.

Je hebt een desktop-app gedownload en het voelt... vreemd. Alles werkt, technisch gezien, maar er is iets dat niet klopt. De tekst is te klein. Het venster gedraagt zich niet zoals andere apps. Het slurpt RAM alsof het gratis is. Grote kans dat je een Electron-app hebt geïnstalleerd.

Wat is Electron eigenlijk?

Voor wie het niet kent: Electron is een framework waarmee ontwikkelars desktop-apps kunnen bouwen met webtechnologieën. HTML, CSS, JavaScript. Dezelfde stuff waar websites van gemaakt worden. De belofte is verleidelijk: je webdevelopers kunnen nu desktop-apps bouwen met dezelfde code. Geen aparte codebases meer voor Windows, macOS en Linux. Voor startups en teams met weinig resources klinkt dat als een droom.

Maar wat de marketing niet vertelt.

De Trenchcoat

Ik vind het altijd een briljante omschrijving: een Electron-app is een webbrowser in een trenchcoat die doet alsof het native software is. En het is niet eens overdreven.

Onder dat glanzende desktop-laagje draai je in wezen een complete Chromium-browser. Een complete JavaScript-engine, een complete rendering engine, en alle overhead die daarbij komt kijken.

Het resultaat? Een e-mailclient die meer RAM vreet dan een videospel. Een notities-app die drie seconden nodig heeft om op te starten. Een "lichtgewicht" hulpprogramma dat in je dock zit te slurpen alsof het cryptocurrency aan het minen is.

Waarom de webversie vaak beter werkt

Hier wordt ik chagrijnig van. In veel gevallen is de webversie van een applicatie gewoon beter dan de desktopvariant. Dezelfde code, dezelfde functies, maar toch voelt de browserversie sneller, responsiever, correcter.

Waarom? Omdat webbrowsers decennialang geoptimaliseerd zijn. Browserbouwers concurreren fel op snelheid. De web rendering componenten van je besturingssysteem ontvangen beveiligingsupdates automatisch via systeemupdates. Maar Electron-apps leveren hun eigen gebundelde Chromium-versie, bevroren in de tijd totdat de ontwikkelaar besluit te updaten — als ze dat al doen.

Dit is niet alleen theorie. Beveiligingsonderzoekers hebben talloze gevallen gedocumenteerd waarbij Electron-apps bekende kwetsbaarheden meeleverden in hun gebundelde Chromium-onderdelen. Die webbrowser waar je dit op leest? Die heeft zich waarschijnlijk drie keer bijgewerkt sinds je begon met lezen. Die Electron-app op je bureaublad? Die draait misschien code van twee jaar oud.

De Bruikbaarheidsbelasting

Laten we het hebben over bruikbaarheid. Bij een native macOS- of Windows-app verwacht je bepaald gedrag. Dat Cmd+Scroll tekst inkadert. Dat vensters soepel resizen. Dat sneltoetsen consistent werken met andere apps die je gebruikt.

Electron-apps breken deze verwachtingen vaak. Niet omdat ontwikkelaars niet geven — velen wel — maar omdat ze werken binnen een framework dat nooit ontworpen is om native gedrag te repliceren. Het is alsof je een vis vraagt om in een boom te klimmen en je dan afvraagt waarom hij moe is.

Ik ben de tel kwijtgeraakt hoe vaak ik door instellingen heb moeten graven om tekst leesbaar te krijgen in een Electron-app, heen en weer gaand om te checken of mijn wijzigingen überhaupt werkten. Op het web zou ik gewoon Ctrl+ indrukken of mijn trackpad knijpen. Maar blijkbaar is dat te geavanceerd voor sommige desktop-apps.

WebViews: het middenweg waar niemand gelukkig mee is

Dus wat is het alternatief? Sommige ontwikkelaars grijpen naar WebViews — systeemniveau-componenten die webcontent renderen met de eigen rendering engine van het besturingssysteem. Het is efficiënter dan Electron omdat de web engine gedeeld wordt door alle apps en beveiligingsupdates ontvangt via het OS.

Maar WebViews hebben hun eigen problemen. Verschillende besturingssystemen gebruiken verschillende web engines. Je app kan er anders uitzien op Windows versus macOS versus Linux. Die "write once, run anywhere"-belofte begint barsten te vertonen.

De eerlijke waarheid? Er is geen perfecte oplossing. Native apps bieden de beste prestaties en gebruikerservaring maar vereisen aparte codebases voor elk platform. Electron biedt ontwikkelgemak ten koste van resourcegebruik en beveiliging. WebViews delen het verschil op een onhandige manier.

Wat moet je doen?

Als ontwikkelaar van desktop-apps: evalueer dan oprecht of Electron de juiste keuze is. Denk aan je gebruikers. Denk aan de ontwikkelaar die straks op social media over je app kan posten en het omschrijft als "een webbrowser in een trenchcoat." Denk eraan dat "het werkt op mijn machine" een heel nieuwe betekenis krijgt als je een complete browser meelevert met je code.

Als gebruiker: voel je niet schuldig om te klagen over die trage Electron-app. Je frustratie is terecht. De geheugenbelasting, de inconsistentie in de interface, de tekst die te klein is om te lezen — dit zijn geen kleine ergernissen. Het zijn echte impacts op je workflow, en ze verdienen aandacht.

Uiteindelijk zouden we tools moeten bouwen die zowel ontwikkelaars als gebruikers respecteren. Soms betekent dat kiezen voor gemak. Soms betekent dat de extra moeite doen om dingen goed te doen. De vraag is niet of Electron goed of slecht is — het is of het de juiste keuze is voor wat je probeert te bouwen.

Die trenchcoat-metafoor werkt omdat het fundamenteel over vermomming gaat. Electron-apps voelen vaak alsof ze doen alsof ze iets zijn wat ze niet zijn. Misschien is het tijd om te stoppen met doen alsof en te beginnen met software bouwen die weet wat het wil zijn.