Den där appen som bara känns... fel

Låt mig ställa en fråga: hur många gånger har du laddat ner en desktop-app och tänkt att något inte stämmer? Den fungerar tekniskt, ingen tvekan om det. Men texten är pytteliten. Fönstret beter sig konstigt. Minnesanvändningen? Låt oss inte ens prata om den.

Jo, du har antagligen installerat en Electron-app.

Vad är Electron egentligen?

För den som inte känner till det: Electron är ett ramverk som låter utvecklare bygga desktop-appar med vanliga webbtekniker — HTML, CSS och JavaScript. Löftet är lockande. Dina webbutvecklare kan plötsligt bygga skrivbordsprogram utan att behöva lära sig native kod för Windows, macOS och Linux separat. Drömmen för startups med tajt budget och små team.

Men här kommer grejen: marknadsföringen berättar inte hela historien.

Webbläsaren i skrynklig rock

En utvecklare beskrev det briljant: Electron-appar är webbläsare förklädda till native programvara. Och det är svårt att argumentera emot.

Under den polerade ytan kör du i praktiken en fullständig Chromium-instans. En komplett JavaScript-motor, en komplett renderingmotor, och all overhead som följer med. Resultatet? En e-postklient som äter mer RAM än ett videospel. En anteckningsapp som tar tre sekunder på sig att starta. En "轻" (lätthinkad) verktygsprogramvara som sitter i aktivitetsfältet och tuggar resurser som om den bryter kryptovaluta.

Ironin: webbversionen fungerar bättre

Här blir det riktigt intressant. I många fall är webbversionen av samma applikation bättre än desktop-motsvarigheten. Samma kodbas, samma funktioner — men på något sätt känns webbversionen snabbare, mer responsiv, mer... rätt.

Varför? Jo, webbläsare har haft decennier på sig att optimeras. Tillverkarna tävlar hårt om prestanda. Operativsystemets webbkomponenter får säkerhetsuppdateringar automatiskt. Men Electron-appar levererar sin egen paketerade Chromium-version, fastfrusen i tiden tills utvecklaren bestämmer sig för att uppdatera — om de nu någonsin gör det.

Det här är inget teoretiskt problem. Säkerhetsforskare har dokumenterat åtskilliga fall där Electron-appar skeppats med kända sårbarheter i sina inbundlade Chromium-komponenter. Webbläsaren du läser detta i? Den har förmodligen uppdaterat sig tre gånger sedan du började läsa. Den Electron-appen på ditt skrivbord? Den kanske kör kod från två år tillbaka.

Usability-skatten

Låt oss prata om användbarhet. När du använder en native macOS- eller Windows-applikation förväntar du dig vissa beteenden. Du förväntar dig att Cmd+Scroll zoomar text. Att fönster storleksändras mjukt. Att tangentbordsgenvägar fungerar konsekvent med andra appar.

Electron-appar bryter ofta dessa förväntningar. Inte för att utvecklarna inte bryr sig — många gör det — utan för att de arbetar inom ett ramverk som aldrig designades för att replikera native beteende. Det är som att be en fisk klättra i träd och sedan undra varför den är utmattad.

Jag har förlorat räkningen på hur många gånger jag behövt gräva genom inställningsmenyer bara för att göra text läsbar i en Electron-app, fram och tillbaka för att kontrollera om mina ändringar faktiskt fungerade. På webben? Ctrl+ eller nyp i trackpaden. Men det är visst för avancerat för vissa skrivbordsprogram.

WebViews: kompromissen ingen är nöjd med

Så vad är alternativet? Vissa utvecklare vänder sig till WebViews — systemkomponenter som renderar webbinnehåll med operativsystemets egen renderingmotor. Det är mer effektivt än Electron eftersom webbmotorn delas mellan alla appar och får säkerhetsuppdateringar via operativsystemet.

Men WebViews har sina egna bekymmer. Olika operativsystem använder olika webbmotorer. Din app kan se något annorlunda ut på Windows jämfört med macOS jämfört med Linux. Det där "skriv en gång, kör överallt"-löftet börjar spricka.

Den ärliga sanningen? Det finns ingen perfekt lösning. Native appar ger bäst prestanda och användarupplevelse men kräver separata kodbaser för varje plattform. Electron ger utvecklingsbekvämlighet till priset av resursanvändning och säkerhet. WebViews delar upp skillnaden på ett klumpigt sätt.

Vad borde du göra?

Om du är utvecklare som bygger skrivbordsapplikationer: utvärdera ärligt om Electron är rätt val. Tänk på dina användare. Tänk på att en utvecklare som pratar om din app på sociala medier kanske beskriver den som "en webbläsare i rock". Tänk på att "det fungerar på min maskin" får en helt ny betydelse när du skeppar en hel webbläsare med din kod.

Om du är användare: skämmes inte för att klaga på den seg Electron-appen. Din frustration är befogad. Minnesskatten, den inkonsistenta UI:n, texten för liten för att läsa — det här är inga småproblem. De påverkar ditt arbetsflöde på riktigt och förtjänar att adresseras.

I slutändan borde vi bygga verktyg som respekterar både utvecklare och användare. Ibland betyder det att välja bekvämlighet. Ibland betyder det att lägga ner extra arbete för att göra saker ordentligt. Frågan är inte om Electron är bra eller dåligt — det är om det är rätt val för det du försöker åstadkomma.

Slutord

Rock-metaforen fungerar för att den i grunden handlar om förklädnad. Electron-appar försöker ofta vara något de inte är. Kanske är det dags att sluta förklä oss och börja bygga programvara som vet vad den vill vara.

• Och ja, ironiskt nog är detta blogginlägg skrivet i ett webbaserat gränssnitt. Vissa verktyg fungerar helt enkelt bäst på det sätt de var designade för. *