Electron og Chromium Embedded Framework (CEF) er to etablerte teknologier for å integrere Chromium i skrivebordsapplikasjoner. Begge lar utviklere bygge programvare som viser moderne nettsteder og nettgrensesnitt på macOS, Windows og Linux. De har imidlertid grunnleggende forskjellige formål.
Electron er et komplett rammeverk for skrivebordsapplikasjoner som kombinerer Chromium, Node.js og operativsystemets innebygde API-er. Utviklere kan bygge hele applikasjoner med JavaScript, TypeScript, HTML og CSS uten å trenge omfattende erfaring med nativ programmering. CEF er derimot et rammeverk for å bygge inn Chromium i eksisterende eller nye applikasjoner, vanligvis skrevet i C++ eller andre språk for nativ utvikling.
Begge teknologiene er mye brukt i produksjonsprogramvare. Electron ligger til grunn for applikasjoner som Visual Studio Code, Slack, Discord og Notion, mens CEF brukes i produkter som Spotify, Steam og OBS Studio. Hos WebCatalog har vi valgt Electron for å bygge skrivebordsapplikasjonene våre på tvers av plattformer.
Så hva er forskjellene, og når er det fornuftig å bruke den ene fremfor den andre?
Electron vs. CEF i korte trekk
Selv om både Electron og CEF bruker Chromium, er det betydelige forskjeller i arkitektur, utvikleropplevelse og tiltenkte bruksområder.
| Egenskap | Electron | Chromium Embedded Framework (CEF) |
|---|---|---|
| Først introdusert | 2013 | 2008 |
| Hovedformål | Bygge komplette skrivebordsapper | Bygge inn Chromium i andre applikasjoner |
| Nettlesermotor | Chromium | Chromium |
| Primære språk | JavaScript, TypeScript | C, C++, med tredjepartsbindinger |
| Node.js inkludert | Ja | Nei |
| Nativ integrasjon | Electron-API-er og native Node.js-moduler | Direkte integrasjon med nativ kode |
| Applikasjonsstruktur | Hovedprosess og gjengivelsesprosesser | Vertsapplikasjon med Chromium-underprosesser |
| Gjengivelse utenfor skjermen | Mulig gjennom tilpassede løsninger | Innebygd API-støtte |
| Applikasjonsstørrelse | Vanligvis stor | Avhenger av integrasjonen, men Chromium tar betydelig plass |
| Ytelse | Avhenger av applikasjonen | Avhenger av applikasjonen og integrasjonen |
| Støtte på tvers av plattformer | macOS, Windows, Linux | macOS, Windows, Linux |
| Økosystem for pakking | Electron Forge, electron-builder | Håndteres vanligvis av vertsapplikasjonen |
| Best egnet for | JavaScript-baserte skrivebordsapper | Native apper som trenger innebygd nettinnhold |
Den viktigste forskjellen er at Electron tilbyr et applikasjonsrammeverk, mens CEF tilbyr et rammeverk for innbygging av en nettleser. De er ikke nødvendigvis direkte alternativer til hverandre, fordi de opererer på ulike abstraksjonsnivåer.
Arkitektur: komplett rammeverk vs. innebygd nettleser
Electron kombinerer Chromium og Node.js i ett samlet kjøremiljø for applikasjoner. Utviklere oppretter en hovedprosess som håndterer applikasjonsvinduer, livssyklushendelser og nativ funksjonalitet, mens gjengivelsesprosesser håndterer det nettbaserte grensesnittet.
Denne arkitekturen lar utviklere skrive det meste av applikasjonene sine med velkjente JavaScript- og TypeScript-verktøy. Electron tilbyr API-er for å opprette vinduer, administrere nettleserøkter, håndtere menyer, vise varsler, få tilgang til systemdialoger og integrere med operativsystemet.
CEF har en annen tilnærming. I stedet for å tilby et komplett rammeverk for skrivebordsapplikasjoner lar det utviklere integrere Chromium i en applikasjon de bygger og kontrollerer selv.
En utvikler som bygger en nativ C++-applikasjon, kan for eksempel bruke CEF til å vise nettinnhold i et eksisterende applikasjonsvindu. Grensesnittet rundt, applikasjonens livssyklus, bakgrunnstjenester og annen nativ funksjonalitet forblir under utviklerens kontroll.
CEF tilbyr API-er for å håndtere nettleserinstanser, navigasjon, ressursinnlasting, JavaScript-kjøring og kommunikasjon mellom nettleseren og den native applikasjonen. Det bruker også Chromiums flerprosessarkitektur, med separate prosesser for gjengivelse og annen nettleserfunksjonalitet.
Denne forskjellen påvirker hvordan utviklere strukturerer applikasjonene sine. Med Electron bygges applikasjonen vanligvis rundt Chromium og Node.js. Med CEF er Chromium som regel én komponent i en større applikasjon.
CEF kan også brukes til å bygge applikasjoner med hovedsakelig nettbaserte grensesnitt, men utviklerne må selv implementere mer av applikasjonsinfrastrukturen rundt.
En interessant historisk detalj er at tidlige versjoner av Electron og NW.js brukte CEF. Electron gikk etter hvert over til å integrere mer direkte med Chromium fordi CEFs abstraksjon gjorde enkelte funksjoner vanskelige å implementere, særlig dyp integrasjon med Node.js.
For utviklere som ønsker et komplett rammeverk for å bygge skrivebordsapplikasjoner med webteknologier, gir Electron som regel et enklere utgangspunkt. For utviklere som allerede har en nativ applikasjon og ønsker å legge til nettfunksjonalitet, kan CEF være det mer naturlige valget.
Utvikleropplevelse: JavaScript vs. nativ utvikling
En av Electrons største fordeler er den lave terskelen for å komme i gang. Utviklere som kjenner moderne webutvikling, kan bruke ferdighetene de allerede har, til å bygge skrivebordsapplikasjoner uten å lære C++ eller plattformspesifikke rammeverk for brukergrensesnitt.
Electrons integrasjon med Node.js gir tilgang til et stort økosystem av pakker for filsystemoperasjoner, nettverkskommunikasjon, databaser, bakgrunnsprosesser og annen funksjonalitet. Populære frontend-teknologier som React, Vue, Svelte og Angular kan brukes uten vesentlige arkitekturendringer.
CEF er primært utformet rundt C- og C++-API-er. Selv om det finnes tredjepartsbindinger for språk som C#, Java, Python og Delphi, må utviklere fortsatt forstå den native applikasjonens arkitektur og CEFs krav til prosesser, tråder og livssyklus.
For et team som allerede vedlikeholder en nativ applikasjon, kan dette være en fordel snarere enn en ulempe. CEF lar utviklere innføre et moderne nettgrensesnitt uten å skrive om eksisterende nativ kode eller ta i bruk et helt nytt applikasjonsrammeverk.
For et JavaScript-orientert team som starter på en ny skrivebordsapplikasjon, krever CEF derimot vanligvis mer oppsett og arbeid med nativ integrasjon.
Forskjellen gjelder også verktøyene. Electron drar nytte av etablerte verktøy som Electron Forge og electron-builder, som forenkler pakking, kodesignering, applikasjonsdistribusjon og oppdateringer. CEF tilbyr binærdistribusjoner og eksempler, men utviklere er vanligvis selv ansvarlige for å integrere rammeverket i egne bygg- og utrullingssystemer.
Dette betyr ikke at CEF har færre muligheter. Det gjenspeiler ganske enkelt formålet som en komponent som kan bygges inn, snarere enn en komplett plattform for applikasjonsutvikling.
Ytelse, minnebruk og applikasjonsstørrelse
Fordi både Electron og CEF bruker Chromium, fjerner ingen av dem automatisk den ekstra ressursbruken som følger med å kjøre en moderne nettlesermotor.
Begge teknologiene kan bruke flere prosesser for gjengivelse, GPU-akselerasjon, nettverkskommunikasjon og annen nettleserfunksjonalitet. Minneforbruk og CPU-bruk avhenger i stor grad av innholdet som vises, antallet aktive nettleserinstanser og hvordan applikasjonen håndterer ressursene sine.
CEF kan gi større fleksibilitet når det integreres i en eksisterende nativ applikasjon. Utviklere kan bruke Chromium bare for de delene av grensesnittet som trenger webteknologier, mens annen funksjonalitet implementeres direkte i nativ kode.
En grafikkapplikasjon kan for eksempel bruke CEF til et innstillingspanel eller et innebygd nettgrensesnitt, mens gjengivelsesmotoren, dokumentbehandlingen og annen ytelsessensitiv funksjonalitet forblir nativ.
Electron-applikasjoner kan også kjøre nativ kode gjennom Node.js-tillegg, eksterne prosesser eller native moduler. Electrons arkitektur er imidlertid generelt innrettet mot å bygge selve applikasjonen med webteknologier.
En spesielt nyttig funksjon i CEF er gjengivelse utenfor skjermen. I stedet for å vise nettinnhold i et tradisjonelt nettleservindu kan CEF gjengi innhold i buffere som vertsapplikasjonen behandler og viser selv. Dette er verdifullt for applikasjoner som spillmotorer, strømmeprogramvare og verktøy med tilpassede gjengivelsessystemer.
Electron kan støtte spesialiserte arbeidsflyter for gjengivelse gjennom ekstra integrasjoner, men CEF tilbyr gjengivelse utenfor skjermen som en etablert del av API-et for innbygging.
For utviklere som vurderer ytelse, er disse målingene blant de mest nyttige:
- Oppstartstid: Hvor raskt applikasjonen blir klar til bruk.
- Minnebruk: Ressursforbruk med representativt nettleserinnhold og nativ funksjonalitet.
- CPU-bruk: Ytelse under gjengivelse, navigasjon og bakgrunnsoperasjoner.
- Applikasjonsstørrelse: Nedlastingsstørrelse og diskbruk etter installasjon.
- Krav til gjengivelse: Om applikasjonen trenger vanlige vinduer eller tilpasset gjengivelse utenfor skjermen.
Det er også viktig å skille CEF fra rammeverk basert på systemets webvisninger. CEF inkluderer Chromium i stedet for å basere seg på nettlesermotoren som er installert av operativsystemet. Å bytte fra Electron til CEF gir derfor ikke automatisk en dramatisk mindre applikasjon.
Utviklere som først og fremst er opptatt av mindre applikasjonspakker, kan vurdere alternativer som Tauri, som bruker webvisninger levert av systemet.
Verken Electron eller CEF bør regnes som entydig raskere uten ytelsestesting av en faktisk implementasjon.
Sikkerhet og nettleseroppdateringer
Både Electron og CEF bygger på Chromiums nettleserarkitektur og sikkerhetsmekanismer, men utviklere er ansvarlige for å konfigurere applikasjonene sine på riktig måte.
Electron tilbyr funksjoner som sandkasseisolering av gjengivelsesprosesser, kontekstisolering og IPC-basert kommunikasjon mellom privilegert applikasjonsfunksjonalitet og nettinnhold. Sikkerhetsdokumentasjonen anbefaler å begrense tilgangen til Node.js, validere IPC-meldinger nøye og behandle innhold som lastes fra eksterne kilder, som ikke-klarert.
CEF støtter også Chromiums flerprosessarkitektur og sikkerhetsisolering. Fordi CEF integreres i en applikasjon som styres av utvikleren, er imidlertid vertsapplikasjonen ansvarlig for å avgjøre hvilke nettleserfunksjoner, tillatelser og native funksjoner som skal gjøres tilgjengelige.
CEF støtter JavaScript-bindinger og kommunikasjon med nativ kode, slik at utviklere kan koble nettinnhold til applikasjonsfunksjonalitet. Disse grensesnittene må utformes nøye, særlig når tredjepartsnettsteder skal vises.
| Sikkerhetshensyn | Electron | CEF |
|---|---|---|
| Chromiums sandkasseisolering | Støttes | Støttes |
| Privilegert nativ tilgang | Node.js og Electron-API-er | Vertsapplikasjonens native API-er |
| Kommunikasjon fra JavaScript til nativ kode | Forhåndslastingsskript og IPC | V8-bindinger og meldingsutveksling mellom prosesser |
| Isolering av eksternt innhold | Sandkasseisolering av gjengivelsesprosesser og kontekstisolering | Chromiums prosessisolering og vertsapplikasjonens kontrollmekanismer |
| Sikkerhetsoppdateringer for nettleseren | Oppgradering av Electron-versjonen | Oppgradering av CEF-versjonen |
| Ansvar for applikasjonssikkerhet | Applikasjonsutvikleren | Applikasjonsutvikleren |
Et annet viktig hensyn er vedlikehold av nettleseren. Både Electron og CEF distribuerer vanligvis sitt eget Chromium-kjøremiljø, så utviklere må sende ut applikasjonsoppdateringer når sikkerhetsrettinger blir tilgjengelige.
CEF tilbyr utgivelsesgrener som følger Chromium, og binærdistribusjoner som forenkler denne prosessen. Electron vedlikeholder tilsvarende utgivelser som inkluderer oppdateringer av Chromium og Node.js.
Ingen av tilnærmingene fjerner behovet for løpende vedlikehold fullstendig. Applikasjoner som bruker eldre Chromium-versjoner, kan fortsatt være utsatt for sårbarheter som allerede er rettet i Chromium-prosjektet.
For team som bygger programvare som viser vilkårlige nettsteder, bør sikkerhetsvedlikehold behandles som en viktig del av applikasjonens livssyklus, ikke som en sporadisk oppgave.
Utbredelse: store applikasjoner som bruker Electron og CEF
Både Electron og CEF er mye brukt i produksjon, men bruksmønstrene er forskjellige.
Electron er særlig synlig blant utbredte skrivebordsapplikasjoner for produktivitet, kommunikasjon og utvikling. Microsoft bruker Electron til Visual Studio Code, og andre kjente Electron-produkter omfatter Slack, Discord, Notion, Figma, Signal Desktop og GitHub Desktop.
CEF brukes også av store programvareselskaper, særlig ved integrasjon av nettgrensesnitt i applikasjoner med eksisterende nativ arkitektur.
Eksempler inkluderer:
| Applikasjon | Teknologi | Typisk bruk |
|---|---|---|
| Visual Studio Code | Electron | Koderedigeringsprogram på tvers av plattformer |
| Slack | Electron | Teamkommunikasjon |
| Discord | Electron | Plattform for kommunikasjon og fellesskap |
| Notion | Electron | Notater og produktivitet |
| Figma Desktop | Electron | Designapplikasjon |
| Spotify Desktop | CEF | Nettbasert grensesnitt i skrivebordsklienten |
| Steam | CEF | Innebygde nettgrensesnitt i skrivebordsklienten |
| OBS Studio | CEF | Nettleserkilder, overlegg og dokkpaneler med nettleserinnhold |
Spotify er et særlig godt dokumentert eksempel på bruk av CEF. Selskapets offisielle side for åpen kildekode oppgir CEF- og Chromium-versjonene som er knyttet til utgivelser av Spotify Desktop.
OBS Studio gir et annet tydelig eksempel på hvorfor utviklere velger CEF. Programmets obs-browser-integrasjon bruker CEF til å tilby nettleserkilder, slik at brukere kan vise nettbaserte overlegg og annet innhold i strømmescener. CEF er en komponent i OBS Studio, ikke rammeverket som brukes til å bygge hele applikasjonen.
Steam bruker også Chromium-baserte, innebygde nettkomponenter i skrivebordsklienten og integrerer nettgrensesnitt med den øvrige native applikasjonsinfrastrukturen.
Disse eksemplene illustrerer forskjellen mellom teknologiene. Electron brukes ofte til å bygge hele skrivebordsapplikasjonen, mens CEF ofte brukes til å innføre nettfunksjonalitet i applikasjoner som allerede har omfattende native komponenter.
CEF bør ikke betraktes som et lite kjent eller utdatert alternativ. Prosjektet ble startet i 2008, før Electron, og har vært mye brukt i kommersiell programvare i mange år. Den lange historien og den fortsatte bruken i store produkter viser at innbygging av Chromium fortsatt er en viktig tilnærming til skrivebordsutvikling.
Electron har på sin side bygget opp et spesielt sterkt økosystem rundt JavaScript-baserte skrivebordsapplikasjoner. Den brede utbredelsen, de etablerte verktøyene og deltakelsen fra store teknologiselskaper gjør det attraktivt for team som bygger nye produkter med webteknologier.
De to rammeverkene har ulike styrker fordi de retter seg mot ulike arkitekturkrav.
Hvorfor vi velger Electron hos WebCatalog
Hos WebCatalog har vi valgt Electron som grunnlag for skrivebordsapplikasjonene våre på tvers av plattformer, fordi det passer godt til kravene produktene våre stiller.
WebCatalog lar brukere gjøre nettsteder om til skrivebordsapplikasjoner, administrere flere kontoer uavhengig av hverandre og organisere applikasjoner på macOS, Windows og Linux. Programvaren vår må støtte nettsteder laget av tusenvis av forskjellige utviklere, med ulike autentiseringssystemer, lagringsmekanismer, nettleser-API-er og JavaScript-rammeverk.
Både Electron og CEF tilbyr et ensartet Chromium-kjøremiljø, noe som er viktig for kompatibiliteten. I motsetning til rammeverk basert på systemets webvisninger lar de oss bruke en kjent Chromium-versjon på tvers av skrivebordsplattformene vi støtter.
WebCatalog er imidlertid ikke først og fremst en nativ applikasjon som trenger en innebygd nettleserkomponent. Nettleserfunksjonalitet er sentralt i produktet vårt. Vi trenger omfattende kontroll over vinduer, økter, lagring, tillatelser, navigasjon og hvordan applikasjonen oppfører seg gjennom livssyklusen.
Electron tilbyr modne API-er for disse behovene. Grensesnittene BrowserWindow, webContents og session lar oss bygge nettleserlignende funksjonalitet med JavaScript og TypeScript. Vedvarende øktpartisjoner er spesielt viktige fordi de lar brukere opprettholde uavhengige innloggingsøkter for flere kontoer på samme nettsted.
CEF tilbyr også API-er for håndtering av nettleserinstanser, forespørsler, lagring og nativ integrasjon. I prinsippet kunne mange av de samme funksjonene implementeres med CEF. Det ville imidlertid kreve at vi bygget og vedlikeholdt mer nativ infrastruktur selv.
Electrons integrasjon med Node.js passer også godt til teknologistakken vår. Vi kan implementere mye av logikken i skrivebordsapplikasjonene med TypeScript, dele kode på tvers av produkter og dra nytte av JavaScript-økosystemet.
Utvikling på tvers av plattformer er et annet hensyn. WebCatalog støtter macOS, Windows og Linux, inkludert plattformspesifikk applikasjonspakking, integrasjoner og systematferd. Electrons etablerte API-er og distribusjonsverktøy reduserer mengden nativ kode vi må vedlikeholde.
Vi erkjenner at Electron medfører ekstra ressursbruk. Å inkludere Chromium øker applikasjonsstørrelsen, og nettleserbaserte applikasjoner krever nøye ressursstyring. I stedet for å erstatte Electron har vi fokusert på å forbedre hvordan vi bruker det.
Vi tok for eksempel i bruk APFS-kloner for å redusere diskbruken til genererte Mac-applikasjoner, noe som reduserte redundant lagring uten å gi avkall på Chromium-kompatibilitet.
Valget vårt betyr ikke at Electron er bedre enn CEF i alle sammenhenger. Hvis WebCatalog først og fremst var en nativ applikasjon med noen få innebygde nettgrensesnitt, kunne CEF vært et utmerket valg. Men fordi produktet vårt grunnleggende er bygget rundt webapplikasjoner og nettleserfunksjonalitet, gir Electron et mer produktivt og vedlikeholdsvennlig fundament.
Der CEF har fordelen
Selv om Electron er vårt foretrukne valg hos WebCatalog, har CEF viktige fordeler for applikasjoner som krever tettere integrasjon med nativ programvare.
CEF er særlig attraktivt når utviklere allerede har en etablert C++-applikasjon og ønsker å innføre moderne nettgrensesnitt uten å erstatte den eksisterende arkitekturen.
Støtten for gjengivelse utenfor skjermen er en annen betydelig fordel. Applikasjoner som strømmeprogramvare og spillmotorer kan trenge å gjengi nettinnhold direkte i tilpassede grafikkpipeliner i stedet for i vanlige skrivebordsvinduer. CEF tilbyr etablerte API-er for disse bruksområdene.
CEF gir også utviklere stor kontroll over nettleserintegrasjonen. De kan tilpasse håndtering av forespørsler, navigasjon, JavaScript-bindinger, ressursinnlasting og hvordan nettleserinstanser samhandler med native applikasjonskomponenter.
For team med solid kompetanse innen nativ utvikling kan denne fleksibiliteten veie tyngre enn fordelene ved hvor enkelt Electron er å bruke.
CEF er verdt å vurdere når man skal:
- Legge til nettgrensesnitt i en eksisterende nativ applikasjon. Utviklere kan beholde den nåværende applikasjonsarkitekturen og bygge inn Chromium der det er nødvendig.
- Bygge programvare med spesielle krav til gjengivelse. Gjengivelse utenfor skjermen gjør det mulig å integrere nettinnhold i grafikkpipeliner og spesialiserte grensesnitt.
- Integrere tett med nativ C++-funksjonalitet. CEF tilbyr native API-er og gir detaljert kontroll over nettleserens oppførsel.
- Vedlikeholde en etablert CEF-applikasjon. Migrering til Electron kan medføre betydelige arkitekturendringer uten vesentlige fordeler.
- Kombinere native og nettbaserte grensesnitt. Utviklere kan bruke Chromium i utvalgte deler av en applikasjon og beholde native brukergrensesnittkomponenter andre steder.
CEF innebærer et større ansvar for applikasjonsinfrastrukturen. Utviklere kan måtte implementere egne løsninger for pakking, oppdatering, vindushåndtering og plattformspesifikke integrasjoner.
For team som allerede er rustet til å vedlikeholde native applikasjoner, kan dette være helt rimelig. For weborienterte team som bygger et nytt skrivebordsprodukt, kan det medføre unødvendig kompleksitet.
Electron vs. CEF: Hva bør du velge?
Begge teknologiene er modne, videreutvikles aktivt og kan brukes til å bygge avansert skrivebordsprogramvare. Det beste valget avhenger først og fremst av om du bygger en ny skrivebordsapplikasjon rundt webteknologier eller bygger inn nettfunksjonalitet i en eksisterende nativ applikasjon.
| Din prioritet | Beste utgangspunkt | Hvorfor |
|---|---|---|
| Ny skrivebordsapp med JavaScript eller TypeScript | Electron | Komplett applikasjonsrammeverk |
| Eksisterende nativ C++-applikasjon | CEF | Integreres i nativ arkitektur |
| Minimalt med nativ utvikling | Electron | Node.js og JavaScript-API-er |
| Innbygging av nettinnhold i native vinduer | CEF | Utviklet spesielt for innbygging |
| Gjengivelse utenfor skjermen og tilpassede grafikkpipeliner | CEF | Dedikerte API-er for gjengivelse |
| Omfattende verktøy for pakking og oppdatering av skrivebordsapper | Electron | Etablert distribusjonsøkosystem |
| Direkte integrasjon med nativ C++-kode | CEF | Native C- og C++-grensesnitt |
| Ensartet Chromium på tvers av skrivebordsplattformer | Begge | Begge inkluderer Chromium |
| Kompleks håndtering av nettleserøkter | Begge | Begge tilbyr funksjoner for nettleseradministrasjon |
| Små applikasjonspakker | Ingen har en iboende fordel | Begge distribuerer Chromium |
| Eksisterende JavaScript-utviklingsteam | Electron | Velkjent utviklingsstakk |
| Eksisterende CEF-basert produkt | CEF | Unngår unødvendig migrering |
For de fleste webutviklere som starter på en ny skrivebordsapplikasjon for flere plattformer, er Electron vanligvis det mest praktiske valget. Det tilbyr applikasjonsarkitekturen, de native integrasjonene, utviklingsverktøyene og distribusjonsøkosystemet som trengs for å bygge et komplett produkt uten å utvikle alt fra bunnen av.
CEF er ofte det beste alternativet for utviklere som allerede har en nativ applikasjon eller trenger spesialiserte muligheter for innbygging av nettlesere. Fleksibiliteten og den direkte native integrasjonen gjør det særlig nyttig for programvare som spillmotorer, strømmeverktøy, industrielle applikasjoner og komplekse native produkter med innebygde nettgrensesnitt.
Ingen av teknologiene er i seg selv raskere eller sikrere. Disse egenskapene avhenger i stor grad av applikasjonen, arkitekturen og kvaliteten på implementasjonen.
Avsluttende tanker
Electron og Chromium Embedded Framework deler den samme underliggende nettleserteknologien, men de løser forskjellige problemer.
Electron er utviklet for å gjøre utvikling av skrivebordsapplikasjoner tilgjengelig for webutviklere. Det kombinerer Chromium, Node.js og native skrivebords-API-er i et rammeverk som lar team bygge avanserte applikasjoner med JavaScript og TypeScript.
CEF er utviklet for å bygge inn Chromium i andre applikasjoner. Det gir kontroll over nettleserintegrasjonen på et lavere nivå og er særlig verdifullt for native applikasjoner som trenger nettbaserte grensesnitt eller spesialiserte gjengivelsesfunksjoner.
Begge har vist sin verdi i store programvareprodukter i produksjon. Electron ligger til grunn for applikasjoner som Visual Studio Code, Slack, Discord og Notion, mens CEF brukes i produkter som Spotify, Steam og OBS Studio.
Hos WebCatalog har vi valgt Electron fordi produktene våre grunnleggende er bygget rundt nettleserfunksjonalitet. Det ensartede Chromium-kjøremiljøet, de modne API-ene for nettleseradministrasjon og JavaScript-økosystemet lar oss utvikle og vedlikeholde skrivebordsapplikasjoner på tvers av plattformer på en effektiv måte.
CEF er fortsatt et utmerket valg for utviklere som jobber med native applikasjoner, særlig når Chromium skal bygges inn i en eksisterende arkitektur i stedet for å være fundamentet for hele produktet.
Valget avhenger til syvende og sist av hva du bygger. Hvis du vil lage en komplett skrivebordsapplikasjon med webteknologier, er Electron vanligvis det beste utgangspunktet. Hvis du vil legge til Chromium i en nativ applikasjon, er CEF sannsynligvis det mest egnede verktøyet.
