Electron och Tauri är två populära ramverk för att bygga skrivbordsapplikationer med webbteknik. Båda gör det möjligt för utvecklare att använda HTML, CSS, JavaScript och moderna frontendramverk för att skapa applikationer för macOS, Windows och Linux. Däremot har de i grunden olika sätt att köra dessa applikationer.
Electron paketerar Chromium och Node.js med varje applikation, vilket ger en enhetlig webbläsarmotor och körmiljö på olika operativsystem. Tauri använder en lättare lösning med operativsystemets befintliga webbvy tillsammans med en Rust-baserad backend. Denna arkitekturskillnad påverkar applikationsstorlek, minnesanvändning, prestanda, säkerhet, kompatibilitet och utvecklarnas produktivitet.
Tauri presenteras ofta som ett modernare och mer lättviktigt alternativ till Electron. Även om det har verkliga fördelar, särskilt när det gäller applikationsstorlek och resursförbrukning, är Electron fortfarande ett starkt val för många typer av skrivbordsprogram. Stora applikationer som Visual Studio Code, Slack, Discord, Notion och Figma använder Electron. På WebCatalog har vi också valt Electron som grund för våra plattformsoberoende skrivbordsapplikationer.
Vilket ramverk ska du då välja? Det är mer användbart att förstå avvägningarna än att utse något av ramverken till vinnare.
Electron kontra Tauri i korthet
Innan vi går in på de tekniska skillnaderna kommer här en jämförelse av de två ramverken utifrån viktiga egenskaper.
| Egenskap | Electron | Tauri |
|---|---|---|
| Webbläsarmotor | Medföljande Chromium | Systemets webbvy |
| Backend | Node.js | Rust |
| Applikationsstorlek | Generellt större | Generellt mindre |
| Grundläggande minnesanvändning | Generellt högre | Generellt lägre |
| Enhetlighet mellan plattformar | Hög | Varierar mellan plattformar |
| JavaScript-ekosystem | Omfattande stöd för Node.js | JavaScript i frontend, plattformsspecifika API:er via insticksmoduler och kommandon |
| Säkerhetsmodell | Chromiums sandlådemiljö, kontextisolering, IPC | Rust-backend, kapabiliteter, IPC |
| Skrivbordsplattformar | macOS, Windows, Linux | macOS, Windows, Linux |
| Mobilstöd | Inget officiellt stöd | Android och iOS |
| Bäst lämpat för | Komplexa, Chromium-beroende skrivbordsappar | Lättviktiga appar och verktyg med nära integration med operativsystemet |
Dessa skillnader beror främst på ett arkitekturval: att antingen paketera en webbläsarmotor med applikationen eller förlita sig på den som operativsystemet tillhandahåller.
Arkitektur: medföljande Chromium kontra systemets webbvy
Den största skillnaden mellan Electron och Tauri är hur de renderar webbinnehåll. Electron innehåller en egen Chromium-motor, vilket innebär att applikationer använder i stort sett samma webbläsarteknik i macOS, Windows och Linux. Utvecklare kan förlita sig på en viss Chromium-version och de webb-API:er den stöder, oavsett vilket operativsystem användarna har installerat.
Tauri använder i stället den webbvy som varje operativsystem tillhandahåller. Det minskar avsevärt mängden programvara som behöver paketeras med en applikation, men innebär också att samma applikation kan köras med olika webbläsarmotorer beroende på plattform.
| Plattform | Electron | Tauri |
|---|---|---|
| macOS | Chromium | WKWebView (WebKit) |
| Windows | Chromium | WebView2 (Chromium) |
| Linux | Chromium | WebKitGTK |
| Android | Stöds inte officiellt | Android WebView |
| iOS | Stöds inte officiellt | WKWebView |
För applikationer med enkla gränssnitt kan dessa skillnader ha liten praktisk betydelse. De flesta moderna frontendramverk fungerar bra i både Chromium och WebKit. Applikationer som är beroende av specifika webbläsar-API:er, komplexa renderingsbeteenden eller avancerade webbfunktioner kan däremot stöta på kompatibilitetsproblem.
Med Electron kan utvecklare testa mot en känd Chromium-version och distribuera samma version till användarna. Med Tauri måste de ta hänsyn till skillnader mellan webbläsarmotorer och potentiellt olika versioner av systemets webbvy. Detta blir särskilt viktigt vid felsökning av problem som bara uppstår i vissa operativsystem eller Linuxdistributioner.
Ingen av lösningarna är i sig överlägsen. Tauri minskar dupliceringen genom att utnyttja programvara som redan finns installerad på datorn, medan Electron accepterar en större applikationsstorlek i utbyte mot mer kontroll och större enhetlighet.
Applikationsstorlek, minnesanvändning och prestanda
En av Tauris tydligaste fördelar är applikationsstorleken. Eftersom Electron paketerar Chromium och Node.js kan även relativt enkla Electron-applikationer ta upp hundratals megabyte diskutrymme. Tauri-applikationer kan vara dramatiskt mindre eftersom de förlitar sig på systemets webbvy i stället för att inkludera en komplett webbläsarmotor i applikationspaketet.
Tauri kan också ha lägre grundläggande minnesförbrukning, särskilt för lättviktiga applikationer med minimal bakgrundsbearbetning. Dess Rust-backend är effektiv, och det behöver inte hålla i gång en separat, medföljande körmiljö för webbläsaren. För små verktyg, anteckningsprogram och applikationer med relativt enkla gränssnitt kan dessa fördelar vara betydande.
Mindre applikationer är dock inte nödvändigtvis snabbare applikationer. Både Electron och Tauri använder i slutändan webbläsarmotorer för att rendera sina gränssnitt, och frontendprestandan beror fortfarande i hög grad på applikationskoden. En ineffektiv React-komponent, en resurskrävande JavaScript-operation eller en minnesläcka förblir ett problem oavsett ramverk.
Det finns också en viktig skillnad mellan applikationsstorlek och total resursförbrukning. Tauri eliminerar inte webbläsarmotorn, utan använder helt enkelt en som operativsystemet tillhandahåller. I Windows innebär det att förlita sig på WebView2, som vanligtvis finns tillgängligt i moderna Windowsinstallationer. I macOS och Linux innebär det att förlita sig på respektive WebKit-implementation.
För en meningsfull prestandajämförelse bör utvecklare mäta:
- Applikationsstorlek: Nedladdningsstorlek och diskutrymme efter installation.
- Starttid: Hur snabbt applikationen blir interaktiv.
- Minnesanvändning i vila: Minnesförbrukning när applikationen är öppen men inaktiv.
- Minnes- och CPU-användning vid aktivitet: Resursförbrukning vid realistiska arbetsbelastningar.
- Responsivitet: Renderingsprestanda och fördröjning vid användarinteraktioner.
Resultaten beror på applikationen. Tauri har ofta en fördel för lättviktiga applikationer, medan Electrons enhetliga Chromium-miljö kan göra komplexa applikationer enklare att testa och optimera på olika plattformar.
Utvecklarupplevelse och säkerhet
Electron har en betydande fördel för team som redan har erfarenhet av JavaScript och TypeScript. Integrationen med Node.js ger tillgång till ett moget ekosystem av bibliotek för filsystemsåtgärder, nätverkskommunikation, databaser, bakgrundsprocesser och operativsystemsfunktioner. Utvecklare kan bygga avancerade skrivbordsapplikationer utan att nödvändigtvis behöva införa ytterligare ett programmeringsspråk i sin teknikstack.
Tauri använder Rust för sin systemnära backend, vilket ger utmärkt prestanda, minnessäkerhet och starka garantier vid kompilering. Utvecklare kan fortfarande bygga sina gränssnitt med React, Vue, Svelte eller andra JavaScript-ramverk, och Tauri tillhandahåller insticksmoduler och JavaScript-API:er för många vanliga systemnära åtgärder.
Att implementera funktioner som ligger utanför dessa API:er kan dock kräva att man skriver Rust-kod eller plattformsspecifik kod. För team som redan är bekväma med Rust kan detta vara en fördel. För team som främst arbetar med TypeScript kan det innebära ytterligare komplexitet.
Säkerhet är ett annat område där de två ramverken använder olika metoder. Tauri tillhandahåller ett kapabilitetsbaserat behörighetssystem som är utformat för att begränsa vilka systemnära åtgärder frontendkoden kan komma åt. Electron erbjuder Chromiums sandlådemiljö, kontextisolering och kontroller för att begränsa åtkomsten till Node.js och andra privilegierade API:er.
Båda ramverken kan ligga till grund för säkra applikationer när de konfigureras korrekt, och båda kan utsätta användare för sårbarheter när utvecklare ger alltför omfattande behörigheter eller hanterar opålitligt innehåll på ett osäkert sätt.
En viktig skillnad gäller säkerhetsuppdateringar. Electron-utvecklare ansvarar för att uppdatera den medföljande Chromium-körmiljön och distribuera nya applikationsversioner när säkerhetsfixar blir tillgängliga. Tauri förlitar sig i allmänhet på uppdateringar från operativsystemet eller webbvy-leverantören för säkerhetskorrigeringar i webbläsarmotorn. Det minskar en del av applikationsutvecklarnas underhållsansvar, även om tillgången till uppdateringar beror på användarens operativsystem och installerade webbvy.
I slutändan beror säkerheten mer på hur en applikation utformas och underhålls än på vilket ramverk den använder. Att välja Tauri gör inte automatiskt en applikation säker, precis som valet av Electron inte automatiskt gör den osäker.
Varför stora företag fortsätter att använda Electron
Trots återkommande kritik mot applikationsstorleken och resursförbrukningen är Electron fortfarande ett populärt val för stora programvaruprodukter. Några av de mest använda skrivbordsapplikationerna är byggda med Electron, vilket visar att arkitekturen kan hantera komplex programvara som används av miljontals människor.
Exempel är:
| Företag | Applikation |
|---|---|
| Microsoft | Visual Studio Code |
| Salesforce | Slack |
| Discord | Discord |
| Notion | Notion |
| Figma | Figma |
| Signal | Signal Desktop |
| GitHub | GitHub Desktop |
| OpenAI | ChatGPT Desktop |
Dessa applikationer fyller mycket olika syften, från programvaruutveckling och kommunikation till design och produktivitet. Gemensamt för dem är behovet av att erbjuda avancerade skrivbordsupplevelser samtidigt som de drar nytta av webbteknik.
Electron erbjuder ett moget ekosystem, en enhetlig Chromium-körmiljö och möjligheten att kombinera webbgränssnitt med operativsystemets inbyggda funktioner. Den utbredda användningen innebär också att utvecklare kan dra nytta av många års dokumentation, bibliotek med öppen källkod, felsökningsverktyg och lösningar på vanliga problem.
För stora applikationer kan utvecklingsproduktivitet och underhållbarhet vara viktigare än att minimera installationspaketets storlek. Ytterligare hundra megabyte diskutrymme kan vara en acceptabel avvägning om det minskar komplexiteten i utvecklingen för flera plattformar och gör applikationen enklare att underhålla.
Det betyder inte att Electron alltid är rätt val, eller att alla företag valde det av samma skäl. Den fortsatta användningen i stora produktionsapplikationer visar dock att Electron fortfarande är ett praktiskt och väletablerat alternativ snarare än en föråldrad teknik som utvecklare automatiskt bör ersätta.
Du kan se fler exempel i Electrons officiella appgalleri.
Varför vi väljer Electron på WebCatalog
På WebCatalog använder vi Electron för att bygga plattformsoberoende skrivbordsapplikationer, och vi anser att det fortfarande är rätt ramverk för just våra krav.
WebCatalog låter användare omvandla webbplatser till skrivbordsapplikationer, hålla flera konton inloggade oberoende av varandra och organisera sina applikationer i macOS, Windows och Linux. Till skillnad från en konventionell skrivbordsapplikation, där utvecklarna kontrollerar frontend och kan optimera den för en viss miljö, behöver vi stödja en stor variation av webbplatser som vi inte har kontroll över.
Dessa webbplatser kan använda olika autentiseringssystem, lagringsmekanismer, mediefunktioner, webbläsar-API:er och JavaScript-ramverk. En webbplats som fungerar korrekt i Chromium kan bete sig annorlunda i WebKit, och att upprätthålla kompatibilitet med flera webbläsarmotorer skulle medföra ytterligare tekniska utmaningar.
Electrons enhetliga Chromium-körmiljö hjälper oss att undvika mycket av denna komplexitet. Den gör att vi kan erbjuda en förutsägbar webbläsarmiljö på de skrivbordsplattformar som stöds, i stället för att förlita oss på olika systemwebbvyer.
Electron tillhandahåller också mogna API:er för att hantera webbläsarsessioner, kakor, lagring, behörigheter och navigering. Möjligheterna till sessionspartitionering är särskilt värdefulla för WebCatalog eftersom de låter användare ha flera oberoende inloggningssessioner för samma webbplats.
Tauri kan också visa externa webbplatser, och liknande funktionalitet kan implementeras med dess webbvy-API:er, insticksmoduler eller plattformsspecifika integrationer. Skillnaden är att Electron ger en mer enhetlig grund för applikationer som bygger på webbläsarfunktionalitet, särskilt när de behöver stödja godtyckliga tredjepartstjänster.
Linuxstödet förstärker denna fördel. Linuxdistributioner varierar avsevärt när det gäller tillgängliga systembibliotek, skrivbordsmiljöer och programvaruversioner. Electrons medföljande Chromium-körmiljö eliminerar en stor källa till variation, medan Tauri-applikationer måste ta hänsyn till den WebKitGTK-miljö som finns tillgänglig i varje distribution som stöds.
Denna enhetlighet har ett pris. Electron-applikationer är större, och utvecklare måste hantera resursförbrukningen noggrant. På WebCatalog söker vi ständigt efter sätt att minska denna extra belastning. Vi har till exempel infört APFS-kloner för att minska diskanvändningen för genererade Mac-applikationer, vilket visar att vissa av Electrons nackdelar kan hanteras utan att man överger ramverket.
Vårt beslut grundar sig inte på en övertygelse om att Electron alltid är bättre än Tauri. Det grundar sig på kraven för vår produkt. För WebCatalog är webbläsarkompatibilitet, enhetligt beteende i olika operativsystem och mogna funktioner för sessionshantering mer värdefulla än att minimera applikationsstorleken.
Där Tauri har fördelen
Trots att vi föredrar Electron på WebCatalog finns det många situationer där Tauri kan vara ett bättre val. För lättviktiga skrivbordsverktyg är mindre applikationspaket och lägre grundläggande resursförbrukning övertygande fördelar. Applikationer som främst visar sin egen frontend, har relativt enkla krav på systemnära funktioner och inte är beroende av en viss webbläsarmotor kan ha stor nytta av Tauris arkitektur.
Tauri är också attraktivt för utvecklare som föredrar Rust eller vill dela systemnära applikationslogik mellan plattformar. Sedan Tauri 2 har ramverket officiellt stöd för Android och iOS utöver operativsystem för skrivbordet. Electron är däremot främst utformat för skrivbordsutveckling och har inget officiellt stöd för mobila plattformar.
En annan aspekt är underhåll. Electrons enhetliga körmiljö förenklar kompatibilitetstester, men kräver också att applikationsutvecklarna underhåller och uppdaterar de Chromium-versioner som följer med applikationerna. Tauri överlåter mer av detta ansvar till operativsystemet, vilket kan minska underhållsbördan för vissa applikationer. Utvecklare kan dock behöva lägga ytterligare arbete på att testa olika webbvy-implementationer och lösa plattformsspecifika problem.
Den totala utvecklingskostnaden är viktigare än något enskilt prestandatest. Ett ramverk som sparar minne men kräver betydligt mer utvecklingsarbete är kanske inte det effektivaste valet för ett visst team. På samma sätt kan det vara onödigt att skicka med en stor Chromium-körmiljö för ett enkelt verktyg när Tauri kan utföra samma uppgift med färre resurser.
Electron kontra Tauri: vilket ska du välja?
Båda ramverken kan användas för att bygga skrivbordsapplikationer för produktion, men de är optimerade för olika prioriteringar.
| Din prioritering | Bättre utgångspunkt | Varför |
|---|---|---|
| Liten nedladdnings- och installationsstorlek | Tauri | Använder systemets webbvy |
| Låg grundläggande resursförbrukning | Tauri | Lättviktig systemnära backend |
| Enhetlig rendering på olika skrivbordsplattformar | Electron | Samma Chromium-motor följer med |
| Omfattande Node.js-integration | Electron | Inbyggd Node.js-körmiljö |
| Rust-baserade systemnära funktioner | Tauri | Rust är det primära backendspråket |
| Visning av godtyckliga tredjepartswebbplatser | Electron | Förutsägbar Chromium-miljö |
| Komplex hantering av webbläsarsessioner | Electron | Mogna API:er för sessioner och partitioner |
| Utveckling för skrivbord och mobil | Tauri | Officiellt stöd för skrivbord och mobil |
| Minimala kompatibilitetstester mellan webbläsare | Electron | En enhetlig motor på olika skrivbordsplattformar |
Detta är allmänna rekommendationer snarare än absoluta regler. Electron kan användas för att bygga effektiva applikationer, medan Tauri kan ligga till grund för avancerad programvara. Det bästa valet beror på produktens krav och teamets befintliga kompetens.
För team som bygger avancerade skrivbordsapplikationer förtjänar Electrons etablerade ekosystem och dokumenterade framgångar att tas på allvar. Att Microsoft, Slack, Discord och andra stora programvaruutvecklare använder ramverket visar att det kan uppfylla höga krav i produktionsmiljö.
Samtidigt erbjuder Tauri ett övertygande alternativ för projekt som prioriterar mindre binärfiler, lägre grundläggande resursförbrukning, Rust-integration eller gemensam utveckling för skrivbord och mobil.
Avslutande tankar
Debatten om Electron kontra Tauri reduceras ofta till en enkel jämförelse: Electron är stort, medan Tauri är litet. Men den mer betydelsefulla skillnaden är den mellan en medföljande, enhetlig körmiljö och ett lättviktigt ramverk som integreras med de webbvykomponenter som systemet tillhandahåller.
Electron prioriterar enhetlighet mellan plattformar, integration med JavaScript-ekosystemet och omfattande kontroll över webbläsarfunktioner. Tauri prioriterar mindre applikationspaket, effektiv systemnära exekvering och närmare integration med operativsystemets webbvyer.
På WebCatalog har vi valt Electron, precis som många stora programvaruföretag har gjort för sina skrivbordsapplikationer. Vi värdesätter dess mogna ekosystem, enhetliga Chromium-körmiljö och omfattande webbläsarfunktioner. Dessa fördelar hjälper oss att bygga och underhålla en produkt som stöder ett brett utbud av webbplatser i flera operativsystem.
Det gör inte Tauri till ett dåligt val. För lättviktiga verktyg eller applikationer med andra krav kan dess fördelar väga tyngre än Electrons.
Det bästa ramverket är inte nödvändigtvis det som har den minsta körbara filen eller den lägsta minnesanvändningen. Det är det som gör det möjligt för ditt team att bygga, underhålla och förbättra applikationen på det mest effektiva sättet.
