Problemet med at give web-apps en jakke

Lad os være ærlige et øjeblik. Du har downloadet et desktop-program, og det føles... forkert. Alt virker teknisk set, men der er noget, der bare er en smule skørt. Teksten er for lille. Vinduet opfører sig ikke som andre programmer. Det æder din RAM som om det var gået af mode. Tillykke, du har sandsynligvis installeret en Electron-app.

For dem der ikke kender til det: Electron er et framework, der lader udviklere bygge desktop-applikationer med web-teknologier – HTML, CSS og JavaScript. Løftet er fristende: dine webudviklere kan nu bygge desktop-apps med den samme kode. Ingen grund til at lære native kodebaser for Windows, macOS og Linux hver for sig. Det lyder som en drøm for små startups og teams med begrænsede ressourcer.

Men her er det, som marketingfolkene ikke fortæller dig.

Trenchcoaten

Jeg elsker den måde en udvikler beskrev Electron-apps: webbrowsere i en trenchcoat, der prøver at udgive sig for at være native software. Det er ikke forkert. Inde under det skinnende desktop-cover kører du i bund og grund en hel Chromium-browserinstans. Det betyder en hel JavaScript-motor, en hel rendering-motor og alt det overhead, der følger med begge dele.

Resultatet? En e-mail-klient der bruger mere RAM end et videospil. En note-app der tager tre sekunder om at åbne. Et "lightweight" værktøj der sidder i din dock og æder ressourcer som om det miner kryptovaluta.

Når websider slår desktop-apps

Her kommer det virkelig irriterende. I mange tilfælde er webversionen af et program faktisk bedre end dens Electron-desktopmodpart. Samme kodebase, samme funktioner – men alligevel føles browser-versionen mere kvik, mere responsiv, mere... rigtig.

Hvorfor? Fordi webbrowsere har haft årtier til at blive optimeret. Browser-producenter konkurrerer benhårdt på performance. Din operating systems web-renderingskomponenter modtager sikkerhedsopdateringer automatisk gennem systemopdateringer. Men Electron-apps sender deres egen bundtede Chromium-version med, frosset i tid indtil udvikleren beslutter sig for at opdatere – hvis de altså gør det.

Dette er ikke bare en teoretisk bekymring. Sikkerhedsforskere har dokumenteret adskillige tilfælde, hvor Electron-apps er sendt på gaden med kendte sårbarheder i deres bundtede Chromium-komponenter. Den webbrowser du læser dette i? Den har sandsynligvis opdateret sig selv tre gange siden du begyndte at læse. Den Electron-app på dit desktop? Den kører måske kode fra to år siden.

Usability-skatten

Lad os snakke om brugervenlighed. Når du bruger et native macOS- eller Windows-program, forventer du bestemte ting. Du forventer at Cmd+Scroll zoomer teksten. Du forventer at vinduerne resize'er glat. Du forventer at tastaturgenveje fungerer konsistent med andre apps du bruger.

Electron-apps bryder ofte disse forventninger. Ikke fordi udviklerne er ligeglade – mange af dem er faktisk ikke – men fordi de arbejder inden for et framework, der aldrig var designet til at reproducere native opførsel. Det er som at bede en fisk om at klatre i et træ og så undre sig over at den er træt.

Jeg har mistet counten over hvor mange gange, jeg har skullet rode i indstillingsmenuer for bare at gøre teksten læsbar i en Electron-app, frem og tilbage for at tjekke om mine ændringer faktisk virkede. På nettet ville jeg bare trykke Ctrl+ eller klemme på mit trackpad. Men tilsyneladende er det for avanceret for visse desktop-applikationer.

WebViews: Mellemvejen ingen er tilfreds med

Så hvad er alternativet? Nogle udviklere tyr til WebViews – system-level komponenter der renderer webindhold ved hjælp af operativsystemets egen renderingmotor. Det er mere effektivt end Electron fordi webmotoren er delt på tværs af alle apps og modtager sikkerhedsopdateringer gennem OS'et.

Men WebViews kommer med deres egne hovedpiner. Forskellige operativsystemer bruger forskellige webmotorer. Din app kan se en smule anderledes ud på Windows versus macOS versus Linux. Det der "skriv én gang, kør hvor som helst"-løfte begynder at slå revner.

Den ærlige sandhed? Der er ingen perfekt løsning. Native apps giver den bedste performance og brugeroplevelse, men kræver separate kodebaser for hver platform. Electron giver udviklings-bekvemmelighed på bekostning af ressourceforbrug og sikkerhed. WebViews deler forskellen akavet.

Hvad skal du gøre?

Hvis du er en udvikler der bygger desktop-applikationer, opfordrer jeg dig til at evaluere ærligt om Electron er det rigtige valg. Tænk over dine brugere. Tænk over at en udvikler på sociale medier måske vil beskrive din app som "en webbrowser i en trenchcoat." Tænk over at "det virker på min maskine" får en helt ny betydning, når du sender en hel browser med din kode.

Hvis du er bruger, så lad være med at føle skyld over at klage over den langsomme Electron-app. Din frustration er valid. Skatten på hukommelsen, den inkonsistente brugerflade, teksten der er for lille til at læse – det her er ikke småklager. Det er reelle påvirkninger af din arbejdsgang, og de fortjener at blive adresseret.

I sidste ende bør vi bygge værktøjer der respekterer både udviklere og brugere. Nogle gange betyder det at vælge bekvemmelighed. Nogle gange betyder det at lægge det ekstra arbejde i at gøre tingene ordentligt. Spørgsmålet er ikke om Electron er godt eller dårligt – det er om det er det rigtige valg for det du prøver at opnå.

Trenchcoat-metaforen virker, fordi den i bund og grund handler om forklædning. Electron-apps føles ofte som om de prøver at være noget de ikke er. Måske er det tid til at holde op med at forstille os og begynde at bygge software, der ved hvad det vil være.