Electron og Chromium Embedded Framework (CEF) er to veletablerede teknologier til at integrere Chromium i desktopapplikationer. Begge gør det muligt for udviklere at bygge software, der viser moderne websteder og webgrænseflader på tværs af macOS, Windows og Linux. De tjener dog grundlæggende forskellige formål.
Electron er et komplet framework til desktopapplikationer, der kombinerer Chromium, Node.js og operativsystemets native API'er. Udviklere kan bygge hele applikationer med JavaScript, TypeScript, HTML og CSS uden at have omfattende erfaring med native programmering. CEF er derimod et framework til at indlejre Chromium i eksisterende eller nye applikationer, som typisk er skrevet i C++ eller andre native programmeringssprog.
Begge teknologier anvendes i vid udstrækning i produktionssoftware. Electron ligger til grund for applikationer som Visual Studio Code, Slack, Discord og Notion, mens CEF bruges i produkter som Spotify, Steam og OBS Studio. Hos WebCatalog har vi valgt Electron til at bygge vores desktopapplikationer på tværs af platforme.
Hvad er så forskellene, og hvornår giver det mening at vælge den ene frem for den anden?
Electron vs. CEF i overblik
Selvom både Electron og CEF bruger Chromium, er der væsentlige forskelle i deres arkitektur, udvikleroplevelse og tilsigtede anvendelser.
| Egenskab | Electron | Chromium Embedded Framework (CEF) |
|---|---|---|
| Først introduceret | 2013 | 2008 |
| Primært formål | Opbygning af komplette desktopapps | Indlejring af Chromium i andre applikationer |
| Browsermotor | Chromium | Chromium |
| Primære programmeringssprog | JavaScript, TypeScript | C, C++ med tredjepartsbindinger |
| Node.js inkluderet | Ja | Nej |
| Native integration | Electron-API'er og native Node.js-moduler | Direkte integration med native kode |
| Applikationsstruktur | Hovedproces og renderingsprocesser | Værtsapplikation med Chromium-underprocesser |
| Offscreen-rendering | Mulig via tilpassede løsninger | Indbygget API-understøttelse |
| Applikationsstørrelse | Generelt stor | Afhænger af integrationen, men Chromium fylder meget |
| Ydeevne | Afhænger af applikationen | Afhænger af applikationen og integrationen |
| Understøttelse på tværs af platforme | macOS, Windows, Linux | macOS, Windows, Linux |
| Økosystem til pakning | Electron Forge, electron-builder | Håndteres typisk af værtsapplikationen |
| Bedst egnet til | JavaScript-baserede desktopapps | Native apps, der kræver indlejret webindhold |
Den vigtigste forskel er, at Electron tilbyder et applikationsframework, mens CEF tilbyder et framework til indlejring af en browser. De er ikke nødvendigvis direkte alternativer til hinanden, fordi de opererer på forskellige abstraktionsniveauer.
Arkitektur: Komplet framework vs. indlejret browser
Electron kombinerer Chromium og Node.js i et samlet kørselsmiljø til applikationer. Udviklere opretter en hovedproces, der håndterer applikationsvinduer, livscyklushændelser og native funktionalitet, mens renderingsprocesser håndterer den webbaserede grænseflade.
Denne arkitektur gør det muligt for udviklere at skrive størstedelen af deres applikationer med velkendte JavaScript- og TypeScript-værktøjer. Electron tilbyder API'er til at oprette vinduer, administrere browsersessioner, håndtere menuer, vise notifikationer, tilgå systemdialoger og integrere med operativsystemet.
CEF har en anden tilgang. I stedet for at tilbyde et komplet framework til desktopapplikationer gør det udviklere i stand til at integrere Chromium i en applikation, som de selv bygger og styrer.
For eksempel kan en udvikler, der bygger en native C++-applikation, bruge CEF til at vise webindhold i et eksisterende applikationsvindue. Den omgivende grænseflade, applikationens livscyklus, baggrundstjenester og anden native funktionalitet forbliver under udviklerens kontrol.
CEF tilbyder API'er til at administrere browserinstanser, navigation, indlæsning af ressourcer, afvikling af JavaScript og kommunikation mellem browseren og den native applikation. Det bruger også Chromiums flerprocesarkitektur med separate processer til rendering og anden browserfunktionalitet.
Denne forskel påvirker, hvordan udviklere strukturerer deres applikationer. Med Electron er applikationen generelt bygget op omkring Chromium og Node.js. Med CEF er Chromium typisk én komponent i en større applikation.
CEF kan også bruges til at bygge applikationer, hvis grænseflader primært er webbaserede, men udviklerne skal selv implementere mere af den omgivende applikationsinfrastruktur.
En interessant historisk detalje er, at tidlige versioner af Electron og NW.js brugte CEF. Electron gik senere over til en mere direkte integration med Chromium, fordi CEF's abstraktion gjorde visse funktioner, især dyb Node.js-integration, vanskelige at implementere.
For udviklere, der ønsker et komplet framework til at bygge desktopapplikationer med webteknologier, giver Electron generelt et mere ligetil udgangspunkt. For udviklere, der allerede har en native applikation og vil tilføje webfunktionalitet, kan CEF være det mere naturlige valg.
Udvikleroplevelse: JavaScript vs. native udvikling
En af Electrons største fordele er den lave adgangstærskel. Udviklere, der kender til moderne webudvikling, kan bruge deres eksisterende kompetencer til at bygge desktopapplikationer uden at lære C++ eller platformspecifikke UI-frameworks.
Electrons integration med Node.js giver adgang til et stort økosystem af pakker til filsystemoperationer, netværk, databaser, baggrundsprocesser og anden funktionalitet. Populære frontendteknologier som React, Vue, Svelte og Angular kan bruges uden væsentlige arkitektoniske ændringer.
CEF er primært designet omkring C- og C++-API'er. Selvom der findes tredjepartsbindinger til sprog som C#, Java, Python og Delphi, skal udviklere stadig forstå den native applikations arkitektur og CEF's krav til processer, tråde og livscyklus.
For et team, der allerede vedligeholder en native applikation, kan dette være en fordel snarere end en ulempe. CEF gør det muligt for udviklere at indføre en moderne webgrænseflade uden at omskrive eksisterende native kode eller tage et helt nyt applikationsframework i brug.
For et JavaScript-fokuseret team, der starter på en ny desktopapplikation, kræver CEF dog generelt mere opsætning og arbejde med native integration.
Forskellen gælder også værktøjerne. Electron nyder godt af veletablerede værktøjer som Electron Forge og electron-builder, der forenkler pakning, kodesignering, distribution og opdateringer af applikationer. CEF tilbyder binære distributioner og eksempler, men udviklerne er typisk selv ansvarlige for at integrere frameworket i deres egne build- og udrulningssystemer.
Det gør ikke CEF mindre kapabelt. Det afspejler blot dets formål som en komponent, der kan indlejres, snarere end en komplet platform til applikationsudvikling.
Ydeevne, hukommelsesforbrug og applikationsstørrelse
Da både Electron og CEF bruger Chromium, fjerner ingen af dem automatisk det ekstra ressourceforbrug, der er forbundet med at køre en moderne browsermotor.
Begge teknologier kan bruge flere processer til rendering, GPU-acceleration, netværk og anden browserfunktionalitet. Hukommelsesforbruget og CPU-forbruget afhænger i høj grad af det viste indhold, antallet af aktive browserinstanser, og hvordan applikationen administrerer sine ressourcer.
CEF kan give større fleksibilitet, når det integreres i en eksisterende native applikation. Udviklere kan nøjes med at bruge Chromium til de dele af grænsefladen, der kræver webteknologier, og implementere anden funktionalitet direkte i native kode.
For eksempel kan en grafikapplikation bruge CEF til et indstillingspanel eller en indlejret webgrænseflade, mens renderingsmotoren, dokumentbehandlingen og anden ydelseskritisk funktionalitet forbliver native.
Electron-applikationer kan også afvikle native kode via Node.js-udvidelser, eksterne processer eller native moduler. Electrons arkitektur er dog generelt rettet mod at bygge selve applikationen med webteknologier.
En særligt nyttig funktion i CEF er offscreen-rendering. I stedet for at vise webindhold i et traditionelt browservindue kan CEF rendere indhold til buffere, som værtsapplikationen selv behandler og viser. Dette er værdifuldt for applikationer som spilmotorer, streamingsoftware og værktøjer med tilpassede renderingssystemer.
Electron kan understøtte specialiserede renderingsforløb via yderligere integrationer, men CEF stiller offscreen-rendering til rådighed som en veletableret del af sit indlejrings-API.
For udviklere, der vurderer ydeevne, omfatter de mest nyttige målinger:
- Opstartstid: Hvor hurtigt applikationen bliver klar til brug.
- Hukommelsesforbrug: Ressourceforbrug med repræsentativt browserindhold og native funktionalitet.
- CPU-forbrug: Ydeevne under rendering, navigation og baggrundsoperationer.
- Applikationsstørrelse: Downloadstørrelse og diskforbrug efter installation.
- Renderingskrav: Om applikationen har brug for almindelige vinduer eller tilpasset offscreen-rendering.
Det er også vigtigt at skelne mellem CEF og frameworks baseret på systemets webviews. CEF inkluderer Chromium i stedet for at være afhængigt af den browsermotor, som operativsystemet har installeret. Derfor giver et skift fra Electron til CEF ikke automatisk en markant mindre applikation.
Udviklere, der primært ønsker mindre applikationspakker, kan overveje alternativer som Tauri, der bruger systemets webviews.
Hverken Electron eller CEF bør betragtes som entydigt hurtigere uden benchmarkmålinger af en konkret implementering.
Sikkerhed og browseropdateringer
Både Electron og CEF bygger på Chromiums browserarkitektur og sikkerhedsmekanismer, men udviklerne er ansvarlige for at konfigurere deres applikationer korrekt.
Electron tilbyder funktioner som sandboxing af renderingsprocesser, kontekstisolering og IPC-baseret kommunikation mellem privilegeret applikationsfunktionalitet og webindhold. Sikkerhedsdokumentationen anbefaler at begrænse adgangen til Node.js, validere IPC-meddelelser omhyggeligt og behandle indhold, der indlæses fra eksterne kilder, som ikke-betroet.
CEF understøtter også Chromiums flerprocesarkitektur og sikkerhedsisolering. Da CEF integreres i en applikation, som styres af udvikleren, er værtsapplikationen dog ansvarlig for at beslutte, hvilke browserfunktioner, tilladelser og native funktioner der skal stilles til rådighed.
CEF understøtter JavaScript-bindinger og native kommunikation, så udviklere kan forbinde webindhold med applikationens funktionalitet. Disse grænseflader skal designes omhyggeligt, især når der vises tredjepartswebsteder.
| Sikkerhedshensyn | Electron | CEF |
|---|---|---|
| Chromium-sandboxing | Understøttet | Understøttet |
| Privilegeret native adgang | Node.js- og Electron-API'er | Værtsapplikationens native API'er |
| Kommunikation fra JavaScript til native kode | Preload-scripts og IPC | V8-bindinger og procesmeddelelser |
| Isolering af eksternt indhold | Sandboxing af renderingsprocesser og kontekstisolering | Chromiums procesisolering og værtsapplikationens kontrolmekanismer |
| Sikkerhedsopdateringer til browseren | Opgradering af Electron-versionen | Opgradering af CEF-versionen |
| Ansvar for applikationens sikkerhed | Applikationsudvikleren | Applikationsudvikleren |
Et andet vigtigt hensyn er vedligeholdelse af browseren. Både Electron og CEF distribuerer generelt deres eget Chromium-kørselsmiljø, så udviklerne skal udsende applikationsopdateringer, når sikkerhedsrettelser bliver tilgængelige.
CEF tilbyder udgivelsesgrene, der følger Chromium, og binære distributioner, som forenkler denne proces. Electron vedligeholder tilsvarende udgivelser, der indeholder opdateringer til Chromium og Node.js.
Ingen af tilgangene fjerner helt behovet for løbende vedligeholdelse. Applikationer, der bruger ældre Chromium-versioner, kan fortsat være udsat for sårbarheder, som allerede er rettet i Chromium-projektet.
For teams, der bygger software til visning af vilkårlige websteder, bør sikkerhedsvedligeholdelse betragtes som en væsentlig del af applikationens livscyklus snarere end en lejlighedsvis opgave.
Udbredelse: Store applikationer, der bruger Electron og CEF
Både Electron og CEF er meget udbredte i produktionssoftware, men de bruges på forskellige måder.
Electron er særligt synligt blandt udbredte desktopapplikationer til produktivitet, kommunikation og udvikling. Microsoft bruger Electron til Visual Studio Code, og andre velkendte Electron-produkter omfatter Slack, Discord, Notion, Figma, Signal Desktop og GitHub Desktop.
CEF bruges også af store softwarevirksomheder, især når webgrænseflader skal integreres i applikationer med en eksisterende native arkitektur.
Eksempler omfatter:
| Applikation | Teknologi | Typisk anvendelse |
|---|---|---|
| Visual Studio Code | Electron | Kodeeditor på tværs af platforme |
| Slack | Electron | Teamkommunikation |
| Discord | Electron | Kommunikations- og fællesskabsplatform |
| Notion | Electron | Noter og produktivitet |
| Figma Desktop | Electron | Designapplikation |
| Spotify Desktop | CEF | Webbaseret grænseflade i desktopklienten |
| Steam | CEF | Indlejrede webgrænseflader i desktopklienten |
| OBS Studio | CEF | Browserkilder, overlays og browserpaneler |
Spotifys brug af CEF er særligt veldokumenteret. På deres officielle open source-side offentliggør de CEF- og Chromium-versionerne, der er knyttet til udgivelser af Spotify Desktop.
OBS Studio er et andet tydeligt eksempel på, hvorfor udviklere vælger CEF. Dets obs-browser-integration bruger CEF til at tilbyde browserkilder, så brugere kan vise webbaserede overlays og andet indhold i streamingscener. CEF er en komponent i OBS Studio snarere end det framework, der bruges til at bygge hele applikationen.
Steam bruger også Chromium-baserede indlejrede webkomponenter i sin desktopklient og integrerer dermed webgrænseflader med sin bredere native applikationsinfrastruktur.
Disse eksempler illustrerer forskellen mellem teknologierne. Electron bruges ofte til at bygge hele desktopapplikationen, mens CEF ofte bruges til at indføre webfunktionalitet i applikationer, der allerede har omfattende native komponenter.
CEF bør ikke betragtes som et ukendt eller forældet alternativ. Det blev grundlagt i 2008, før Electron, og har i mange år været anvendt i vid udstrækning i kommerciel software. Dets lange historie og fortsatte brug i store produkter viser, at indlejring af Chromium fortsat er en vigtig tilgang til desktopudvikling.
Electron har i mellemtiden opbygget et særligt stærkt økosystem omkring JavaScript-baserede desktopapplikationer. Den brede udbredelse, de veletablerede værktøjer og deltagelsen fra store teknologivirksomheder gør det attraktivt for teams, der bygger nye produkter med webteknologier.
De to frameworks har forskellige styrker, fordi de er rettet mod forskellige arkitektoniske krav.
Hvorfor vi vælger Electron hos WebCatalog
Hos WebCatalog har vi valgt Electron som grundlag for vores desktopapplikationer på tværs af platforme, fordi det passer godt til vores produkters krav.
WebCatalog giver brugere mulighed for at omdanne websteder til desktopapplikationer, administrere flere konti uafhængigt af hinanden og organisere applikationer på tværs af macOS, Windows og Linux. Vores software skal understøtte websteder, som er skabt af tusindvis af forskellige udviklere, med forskellige godkendelsessystemer, lagringsmekanismer, browser-API'er og JavaScript-frameworks.
Både Electron og CEF tilbyder et ensartet Chromium-kørselsmiljø, hvilket er vigtigt for kompatibiliteten. I modsætning til frameworks baseret på systemets webviews giver de os mulighed for at bruge en kendt Chromium-version på tværs af de desktopplatforme, vi understøtter.
WebCatalog er dog ikke primært en native applikation, der har brug for en indlejret browserkomponent. Browserfunktionalitet er central for vores produkt. Vi har brug for omfattende kontrol over vinduer, sessioner, lagring, tilladelser, navigation og applikationens adfærd gennem hele livscyklussen.
Electron tilbyder modne API'er til disse behov. Grænsefladerne BrowserWindow, webContents og session gør det muligt for os at bygge browserlignende funktionalitet med JavaScript og TypeScript. Vedvarende sessionspartitioner er særligt vigtige, fordi de giver brugerne mulighed for at opretholde uafhængige login-sessioner for flere konti på samme websted.
CEF tilbyder også API'er til at administrere browserinstanser, anmodninger, lagring og native integration. I princippet kunne mange af de samme funktioner implementeres med CEF. Det ville dog kræve, at vi selv byggede og vedligeholdt mere native infrastruktur.
Electrons integration med Node.js passer også til vores teknologistak. Vi kan implementere en stor del af logikken i vores desktopapplikationer med TypeScript, dele kode på tværs af produkter og drage fordel af JavaScript-økosystemet.
Udvikling på tværs af platforme er et andet hensyn. WebCatalog understøtter macOS, Windows og Linux, herunder platformspecifik pakning af applikationer, integrationer og systemadfærd. Electrons veletablerede API'er og distributionsværktøjer reducerer mængden af native kode, vi skal vedligeholde.
Vi anerkender, at Electron medfører ekstra ressourceforbrug. Når Chromium medfølger, øges applikationsstørrelsen, og browserbaserede applikationer kræver omhyggelig ressourcestyring. I stedet for at erstatte Electron har vi fokuseret på at forbedre den måde, vi bruger det på.
For eksempel indførte vi APFS-kloner for at reducere diskforbruget for genererede Mac-applikationer, hvilket reducerer overflødig lagring uden at give afkald på Chromium-kompatibilitet.
Vores beslutning betyder ikke, at Electron er bedre end CEF i alle situationer. Hvis WebCatalog primært var en native applikation med nogle få indlejrede webgrænseflader, kunne CEF være et fremragende valg. Men fordi vores produkt grundlæggende er bygget op omkring webapplikationer og browserfunktionalitet, giver Electron et mere produktivt fundament, der er lettere at vedligeholde.
Hvor CEF har fordelen
Selvom Electron er vores foretrukne valg hos WebCatalog, har CEF væsentlige fordele for applikationer, der kræver en dybere integration med native software.
CEF er særligt attraktivt, når udviklere allerede har en veletableret C++-applikation og vil indføre moderne webgrænseflader uden at erstatte deres eksisterende arkitektur.
Understøttelsen af offscreen-rendering er en anden væsentlig fordel. Applikationer som streamingsoftware og spilmotorer kan have brug for at rendere webindhold direkte i tilpassede grafikpipelines frem for i almindelige desktopvinduer. CEF tilbyder veletablerede API'er til disse anvendelser.
CEF giver også udviklere omfattende kontrol over browserintegrationen. De kan tilpasse håndtering af anmodninger, navigation, JavaScript-bindinger, indlæsning af ressourcer og den måde, browserinstanser interagerer med native applikationskomponenter på.
For teams med stærke kompetencer inden for native udvikling kan denne fleksibilitet opveje Electrons bekvemmelighed.
CEF er værd at overveje, når man skal:
- Tilføje webgrænseflader til en eksisterende native applikation. Udviklere kan bevare deres nuværende applikationsarkitektur og indlejre Chromium, hvor der er behov for det.
- Bygge software med særlige renderingskrav. Offscreen-rendering gør det muligt at integrere webindhold i grafikpipelines og specialiserede grænseflader.
- Integrere tæt med native C++-funktionalitet. CEF stiller native API'er til rådighed og giver detaljeret kontrol over browserens adfærd.
- Vedligeholde en veletableret CEF-applikation. En migrering til Electron kan medføre omfattende arkitektoniske ændringer uden væsentlige fordele.
- Kombinere native grænseflader og webgrænseflader. Udviklere kan bruge Chromium til udvalgte dele af en applikation og samtidig bevare native UI-komponenter andre steder.
CEF kræver dog, at man påtager sig et større ansvar for applikationsinfrastrukturen. Udviklere kan være nødt til selv at implementere pakning, opdatering, vinduesstyring og platformspecifikke integrationer.
For teams, der allerede er rustet til at vedligeholde native applikationer, kan dette være helt rimeligt. For webfokuserede teams, der bygger et nyt desktopprodukt, kan det medføre unødvendig kompleksitet.
Electron vs. CEF: Hvad skal du vælge?
Begge teknologier er modne, udvikles aktivt og kan understøtte avanceret desktopsoftware. Det bedste valg afhænger primært af, om du bygger en ny desktopapplikation omkring webteknologier eller indlejrer webfunktionalitet i en eksisterende native applikation.
| Din prioritet | Bedre udgangspunkt | Hvorfor |
|---|---|---|
| Ny desktopapp med JavaScript eller TypeScript | Electron | Komplet applikationsframework |
| Eksisterende native C++-applikation | CEF | Integreres i native arkitektur |
| Minimal native udvikling | Electron | Node.js- og JavaScript-API'er |
| Indlejring af webindhold i native vinduer | CEF | Designet specifikt til indlejring |
| Offscreen-rendering og tilpassede grafikpipelines | CEF | Dedikerede renderings-API'er |
| Omfattende værktøjer til pakning og opdatering af desktopapps | Electron | Veletableret distributionsøkosystem |
| Direkte integration med native C++-kode | CEF | Native C- og C++-grænseflader |
| Ensartet Chromium på tværs af desktopplatforme | Begge | Begge inkluderer Chromium |
| Kompleks administration af browsersessioner | Begge | Begge tilbyder funktioner til browseradministration |
| Små applikationspakker | Ingen har en iboende fordel | Begge distribuerer Chromium |
| Eksisterende JavaScript-udviklingsteam | Electron | Velkendt udviklingsstak |
| Eksisterende CEF-baseret produkt | CEF | Undgå unødvendig migrering |
For de fleste webudviklere, der starter på en ny desktopapplikation til flere platforme, er Electron generelt det mest praktiske valg. Det tilbyder den applikationsarkitektur, de native integrationer, udviklingsværktøjer og det distributionsøkosystem, der er nødvendige for at bygge et komplet produkt uden at udvikle alt fra bunden.
CEF er ofte det bedste valg for udviklere, der allerede har en native applikation eller har brug for specialiserede muligheder for browserindlejring. Dets fleksibilitet og direkte native integration gør det særligt nyttigt til software som spilmotorer, streamingværktøjer, industrielle applikationer og komplekse native produkter med indlejrede webgrænseflader.
Ingen af teknologierne er i sig selv hurtigere eller mere sikker. Disse egenskaber afhænger i høj grad af applikationen, dens arkitektur og kvaliteten af implementeringen.
Afsluttende tanker
Electron og Chromium Embedded Framework deler den samme underliggende browserteknologi, men de løser forskellige problemer.
Electron er designet til at gøre udvikling af desktopapplikationer tilgængelig for webudviklere. Det kombinerer Chromium, Node.js og native desktop-API'er i et framework, der giver teams mulighed for at bygge avancerede applikationer med JavaScript og TypeScript.
CEF er designet til at indlejre Chromium i andre applikationer. Det giver kontrol på et lavere niveau over browserintegrationen og er særligt værdifuldt for native applikationer, der har brug for webbaserede grænseflader eller specialiserede renderingsfunktioner.
Begge har bevist deres værdi i store softwareprodukter i drift. Electron ligger til grund for applikationer som Visual Studio Code, Slack, Discord og Notion, mens CEF bruges i produkter som Spotify, Steam og OBS Studio.
Hos WebCatalog har vi valgt Electron, fordi vores produkter grundlæggende er bygget op omkring browserfunktionalitet. Dets ensartede Chromium-kørselsmiljø, modne API'er til browseradministration og JavaScript-økosystem gør det muligt for os effektivt at udvikle og vedligeholde desktopapplikationer på tværs af platforme.
CEF er fortsat et fremragende valg for udviklere, der arbejder med native applikationer, især når Chromium skal indlejres i en eksisterende arkitektur frem for at fungere som fundament for hele produktet.
Valget afhænger i sidste ende af, hvad du bygger. Hvis du vil skabe en komplet desktopapplikation med webteknologier, er Electron som regel det bedste udgangspunkt. Hvis du vil tilføje Chromium til en native applikation, er CEF sandsynligvis det mest passende værktøj.
