Az Electron és a Chromium Embedded Framework (CEF) két bevált technológia a Chromium asztali alkalmazásokba történő integrálására. Mindkettő lehetővé teszi a fejlesztők számára, hogy modern webhelyeket és webes felületeket megjelenítő szoftvereket készítsenek macOS, Windows és Linux rendszerekre. Ugyanakkor alapvetően eltérő célokat szolgálnak.
Az Electron egy teljes körű asztali alkalmazáskeretrendszer, amely egyesíti a Chromiumot, a Node.js-t és az operációs rendszer natív API-jait. A fejlesztők JavaScript, TypeScript, HTML és CSS használatával teljes alkalmazásokat építhetnek anélkül, hogy széles körű natív programozási tapasztalatra lenne szükségük. A CEF ezzel szemben olyan keretrendszer, amellyel a Chromium meglévő vagy új, jellemzően C++ vagy más natív nyelven írt alkalmazásokba ágyazható be.
Mindkét technológiát széles körben használják éles környezetben működő szoftverekben. Az Electronra épül például a Visual Studio Code, a Slack, a Discord és a Notion, míg a CEF-et olyan termékek használják, mint a Spotify, a Steam és az OBS Studio. A WebCatalognál az Electront választottuk többplatformos asztali alkalmazásaink fejlesztéséhez.
Mik tehát a különbségek, és mikor érdemes az egyiket választani a másik helyett?
Electron és CEF: rövid áttekintés
Bár az Electron és a CEF egyaránt a Chromiumot használja, jelentősen különböznek architektúrájuk, a fejlesztői élmény és a tervezett felhasználási területek tekintetében.
| Jellemző | Electron | Chromium Embedded Framework (CEF) |
|---|---|---|
| Első megjelenés | 2013 | 2008 |
| Elsődleges cél | Teljes asztali alkalmazások fejlesztése | A Chromium beágyazása más alkalmazásokba |
| Böngészőmotor | Chromium | Chromium |
| Elsődleges nyelvek | JavaScript, TypeScript | C, C++, külső nyelvi kötésekkel |
| Tartalmazza a Node.js-t | Igen | Nem |
| Natív integráció | Electron API-k és natív Node.js-modulok | Közvetlen integráció natív kóddal |
| Alkalmazásstruktúra | Főfolyamat és megjelenítőfolyamatok | Gazdaalkalmazás Chromium-alfolyamatokkal |
| Képernyőn kívüli renderelés | Egyedi megoldásokkal lehetséges | Beépített API-támogatás |
| Alkalmazásméret | Általában nagy | Az integrációtól függ, de a Chromium jelentős méretű |
| Teljesítmény | Az alkalmazástól függ | Az alkalmazástól és az integrációtól függ |
| Többplatformos támogatás | macOS, Windows, Linux | macOS, Windows, Linux |
| Csomagolási ökoszisztéma | Electron Forge, electron-builder | Jellemzően a gazdaalkalmazás kezeli |
| Leginkább erre alkalmas | JavaScript-alapú asztali alkalmazások | Beágyazott webes tartalmat igénylő natív alkalmazások |
A legfontosabb különbség az, hogy az Electron alkalmazáskeretrendszert, a CEF pedig böngészőbeágyazási keretrendszert biztosít. Nem feltétlenül helyettesítik közvetlenül egymást, mivel eltérő absztrakciós szinteken működnek.
Architektúra: teljes keretrendszer vagy beágyazott böngésző
Az Electron egységes alkalmazás-futtatókörnyezetben egyesíti a Chromiumot és a Node.js-t. A fejlesztők létrehoznak egy főfolyamatot, amely az alkalmazásablakokat, az életciklus-eseményeket és a natív funkciókat kezeli, míg a megjelenítőfolyamatok a webalapú felületről gondoskodnak.
Ez az architektúra lehetővé teszi, hogy a fejlesztők alkalmazásaik nagy részét a már ismert JavaScript- és TypeScript-eszközökkel írják meg. Az Electron API-kat biztosít ablakok létrehozásához, böngésző-munkamenetek és menük kezeléséhez, értesítések megjelenítéséhez, rendszer-párbeszédablakok eléréséhez és az operációs rendszerrel való integrációhoz.
A CEF más megközelítést alkalmaz. Ahelyett, hogy teljes asztali alkalmazáskeretrendszert nyújtana, lehetővé teszi a fejlesztők számára, hogy a Chromiumot egy saját maguk által felépített és vezérelt alkalmazásba integrálják.
Egy natív C++-alkalmazást készítő fejlesztő például a CEF segítségével jeleníthet meg webes tartalmat egy meglévő alkalmazásablakon belül. A környező felület, az alkalmazás életciklusa, a háttérszolgáltatások és más natív funkciók továbbra is a fejlesztő irányítása alatt maradnak.
A CEF API-kat biztosít a böngészőpéldányok, a navigáció, az erőforrás-betöltés, a JavaScript-végrehajtás, valamint a böngésző és a natív alkalmazás közötti kommunikáció kezeléséhez. Emellett a Chromium többfolyamatos architektúráját használja, külön folyamatokkal a megjelenítéshez és más böngészőfunkciókhoz.
Ez a különbség befolyásolja az alkalmazások felépítését. Electron esetén az alkalmazás általában a Chromium és a Node.js köré épül. CEF esetén a Chromium jellemzően egy nagyobb alkalmazás egyik összetevője.
A CEF olyan alkalmazások készítésére is használható, amelyek felülete elsősorban webalapú, de a fejlesztőknek az alkalmazást körülvevő infrastruktúra nagyobb részét kell saját maguknak megvalósítaniuk.
Érdekes történeti részlet, hogy az Electron és az NW.js korai verziói a CEF-et használták. Az Electron végül áttért a Chromiummal való közvetlenebb integrációra, mert a CEF absztrakciója bizonyos funkciók, különösen a mély Node.js-integráció megvalósítását megnehezítette.
Azoknak a fejlesztőknek, akik teljes keretrendszert keresnek webes technológiákra épülő asztali alkalmazások fejlesztéséhez, az Electron általában egyszerűbb kiindulópontot kínál. Azok számára viszont, akiknek már van natív alkalmazásuk, és azt szeretnék webes funkciókkal bővíteni, a CEF lehet a természetesebb választás.
Fejlesztői élmény: JavaScript vagy natív fejlesztés
Az Electron egyik legnagyobb előnye a könnyű elsajátíthatóság. A modern webfejlesztésben jártas fejlesztők meglévő tudásukat felhasználva készíthetnek asztali alkalmazásokat anélkül, hogy meg kellene tanulniuk a C++-t vagy a platformspecifikus felületfejlesztési keretrendszereket.
Az Electron Node.js-integrációja csomagok hatalmas ökoszisztémájához biztosít hozzáférést fájlrendszerműveletekhez, hálózati kommunikációhoz, adatbázisokhoz, háttérfolyamatokhoz és más funkciókhoz. Az olyan népszerű frontend-technológiák, mint a React, a Vue, a Svelte és az Angular, jelentős architekturális változtatások nélkül használhatók.
A CEF elsősorban C- és C++-API-kra épül. Bár léteznek külső nyelvi kötések például C#, Java, Python és Delphi nyelvekhez, a fejlesztőknek így is érteniük kell a natív alkalmazás architektúráját, valamint a CEF folyamatokra, szálkezelésre és életciklusra vonatkozó követelményeit.
Egy natív alkalmazást már karbantartó csapat számára ez inkább előny lehet, mint hátrány. A CEF lehetővé teszi modern webes felület bevezetését a meglévő natív kód újraírása vagy egy teljesen új alkalmazáskeretrendszer átvétele nélkül.
Egy új asztali alkalmazás fejlesztésébe kezdő, JavaScriptre összpontosító csapat számára viszont a CEF általában több kezdeti beállítást és natív integrációs munkát igényel.
A különbség az eszköztárra is kiterjed. Az Electron olyan bevált eszközökre támaszkodhat, mint az Electron Forge és az electron-builder, amelyek leegyszerűsítik a csomagolást, a kódaláírást, az alkalmazásterjesztést és a frissítéseket. A CEF bináris kiadásokat és példákat biztosít, de a fejlesztők általában maguk felelnek a keretrendszer saját build- és telepítési rendszereikbe történő integrálásáért.
Ez nem jelenti azt, hogy a CEF kevesebbre lenne képes. Egyszerűen azt tükrözi, hogy beágyazható összetevőnek készült, nem pedig teljes alkalmazásfejlesztési platformnak.
Teljesítmény, memóriahasználat és alkalmazásméret
Mivel az Electron és a CEF egyaránt a Chromiumot használja, egyik sem szünteti meg automatikusan a modern böngészőmotor futtatásával járó erőforrástöbbletet.
Mindkét technológia több folyamatot is használhat a megjelenítéshez, a GPU-gyorsításhoz, a hálózati kommunikációhoz és más böngészőfunkciókhoz. A memóriafogyasztás és a CPU-használat erősen függ a megjelenített tartalomtól, az aktív böngészőpéldányok számától és attól, hogyan kezeli az alkalmazás az erőforrásait.
A CEF nagyobb rugalmasságot kínálhat egy meglévő natív alkalmazásba integrálva. A fejlesztők csak a felület azon részein használhatják a Chromiumot, amelyek webes technológiákat igényelnek, míg más funkciókat közvetlenül natív kódban valósíthatnak meg.
Egy grafikai alkalmazás például használhatja a CEF-et egy beállításpanelhez vagy beágyazott webes felülethez, miközben a renderelőmotor, a dokumentumfeldolgozás és más teljesítményérzékeny funkciók natívak maradnak.
Az Electron-alkalmazások is futtathatnak natív kódot Node.js-kiegészítőkön, külső folyamatokon vagy natív modulokon keresztül. Az Electron architektúrája azonban általában arra épül, hogy maga az alkalmazás webes technológiákkal készüljön.
A CEF egyik különösen hasznos képessége a képernyőn kívüli renderelés. Ahelyett, hogy a webes tartalmat hagyományos böngészőablakban jelenítené meg, a CEF olyan pufferekbe renderelheti, amelyeket a gazdaalkalmazás maga dolgoz fel és jelenít meg. Ez értékes lehet például játékmotorok, streamingszoftverek és egyedi megjelenítési rendszerekkel rendelkező eszközök esetében.
Az Electron további integrációkkal támogathat speciális renderelési munkafolyamatokat, a CEF azonban a képernyőn kívüli renderelést a beágyazási API-jának bevált részeként biztosítja.
A teljesítményt vizsgáló fejlesztők számára a leghasznosabb mérőszámok a következők:
- Indulási idő: Milyen gyorsan válik használhatóvá az alkalmazás.
- Memóriahasználat: Erőforrás-fogyasztás jellemző böngészőtartalom és natív funkciók használata mellett.
- CPU-használat: Teljesítmény renderelés, navigáció és háttérműveletek közben.
- Alkalmazásméret: Letöltési méret és a telepítés utáni lemezterület-használat.
- Renderelési követelmények: Hagyományos ablakokra vagy egyedi, képernyőn kívüli renderelésre van-e szüksége az alkalmazásnak.
Fontos megkülönböztetni a CEF-et a rendszer webnézeteire épülő keretrendszerektől is. A CEF tartalmazza a Chromiumot, nem pedig az operációs rendszer által telepített böngészőmotorra támaszkodik. Emiatt az Electronról CEF-re váltás önmagában nem eredményez drámaian kisebb alkalmazást.
Az elsősorban kisebb alkalmazáscsomagokra törekvő fejlesztőknek érdemes lehet megfontolniuk olyan alternatívákat, mint a Tauri, amely a rendszer által biztosított webnézeteket használja.
Sem az Electront, sem a CEF-et nem szabad egyértelműen gyorsabbnak tekinteni egy tényleges megvalósítás teljesítménymérése nélkül.
Biztonság és böngészőfrissítések
Az Electron és a CEF egyaránt a Chromium böngészőarchitektúrájára és biztonsági mechanizmusaira támaszkodik, az alkalmazások megfelelő konfigurálásáért azonban a fejlesztők felelnek.
Az Electron olyan funkciókat kínál, mint a megjelenítőfolyamatok sandboxba zárása, a kontextusizoláció és a kiemelt jogosultságú alkalmazásfunkciók, illetve a webes tartalom közötti IPC-alapú kommunikáció. Biztonsági dokumentációja a Node.js-hozzáférés korlátozását, az IPC-üzenetek gondos ellenőrzését és a távolról betöltött tartalmak nem megbízhatóként való kezelését javasolja.
A CEF szintén támogatja a Chromium többfolyamatos architektúráját és biztonsági elkülönítését. Mivel azonban a CEF egy, a fejlesztője által vezérelt alkalmazásba integrálódik, a gazdaalkalmazás felelőssége eldönteni, hogy mely böngészőfunkciókat, engedélyeket és natív képességeket teszi elérhetővé.
A CEF támogatja a JavaScript-kötéseket és a natív kommunikációt, így a fejlesztők összekapcsolhatják a webes tartalmat az alkalmazás funkcióival. Ezeket az interfészeket körültekintően kell megtervezni, különösen harmadik felek webhelyeinek megjelenítésekor.
| Biztonsági szempont | Electron | CEF |
|---|---|---|
| Chromium-sandbox | Támogatott | Támogatott |
| Kiemelt jogosultságú natív hozzáférés | Node.js- és Electron API-k | A gazdaalkalmazás natív API-jai |
| JavaScript és natív kód közötti kommunikáció | Előtöltési szkriptek és IPC | V8-kötések és folyamatok közötti üzenetküldés |
| Távoli tartalom elkülönítése | Megjelenítőfolyamatok sandboxba zárása és kontextusizoláció | A Chromium folyamatizolációja és a gazdaalkalmazás vezérlési lehetőségei |
| Böngészőbiztonsági frissítések | Electron-verziófrissítések | CEF-verziófrissítések |
| Az alkalmazás biztonságáért felelős | Az alkalmazás fejlesztője | Az alkalmazás fejlesztője |
További fontos szempont a böngésző karbantartása. Az Electron és a CEF általában saját Chromium-futtatókörnyezetet terjeszt, ezért a fejlesztőknek alkalmazásfrissítéseket kell kiadniuk, amikor biztonsági javítások válnak elérhetővé.
A CEF a Chromiumot követő kiadási ágakat és bináris csomagokat biztosít, amelyek egyszerűsítik ezt a folyamatot. Az Electron hasonlóképpen olyan kiadásokat tart fenn, amelyek tartalmazzák a Chromium és a Node.js frissítéseit.
Egyik megközelítés sem szünteti meg teljesen a folyamatos karbantartás szükségességét. A régebbi Chromium-verziókat használó alkalmazások továbbra is ki lehetnek téve olyan sérülékenységeknek, amelyeket az alapul szolgáló projektben már kijavítottak.
A tetszőleges webhelyeket megjelenítő szoftvereket fejlesztő csapatoknak a biztonsági karbantartást az alkalmazás életciklusának alapvető részeként kell kezelniük, nem pedig alkalmi feladatként.
Elterjedtség: jelentős alkalmazások, amelyek Electront és CEF-et használnak
Az Electron és a CEF egyaránt széles körben elterjedt éles környezetben, de felhasználási mintáik eltérnek.
Az Electron különösen gyakori a széles körben használt asztali produktivitási, kommunikációs és fejlesztői alkalmazások között. A Microsoft a Visual Studio Code-hoz használja az Electront, további ismert Electron-alapú termékek pedig a Slack, a Discord, a Notion, a Figma, a Signal Desktop és a GitHub Desktop.
A CEF-et szintén jelentős szoftvercégek használják, különösen akkor, amikor meglévő natív architektúrával rendelkező alkalmazásokba integrálnak webes felületeket.
Néhány példa:
| Alkalmazás | Technológia | Jellemző felhasználás |
|---|---|---|
| Visual Studio Code | Electron | Többplatformos kódszerkesztő |
| Slack | Electron | Csapatkommunikáció |
| Discord | Electron | Kommunikációs és közösségi platform |
| Notion | Electron | Jegyzetelés és produktivitás |
| Figma Desktop | Electron | Tervezőalkalmazás |
| Spotify Desktop | CEF | Webes technológiákra épülő felület az asztali kliensen belül |
| Steam | CEF | Beágyazott webes felületek az asztali kliensben |
| OBS Studio | CEF | Böngészőforrások, átfedő elemek és dokkolható böngészőpanelek |
A Spotify CEF-használata különösen jól dokumentált. A hivatalos nyílt forráskódú oldalán közzéteszi a Spotify Desktop kiadásaihoz tartozó CEF- és Chromium-verziókat.
Az OBS Studio egy másik szemléletes példa arra, miért választják a fejlesztők a CEF-et. Az obs-browser integrációja CEF-et használ a böngészőforrások biztosításához, így a felhasználók webalapú átfedő elemeket és más tartalmakat jeleníthetnek meg a streamelési jelenetekben. A CEF az OBS Studio egyik összetevője, nem pedig a teljes alkalmazás felépítéséhez használt keretrendszer.
A Steam szintén Chromium-alapú beágyazott webes összetevőket használ az asztali kliensében, és a webes felületeket a szélesebb natív alkalmazás-infrastruktúrájába integrálja.
Ezek a példák jól szemléltetik a két technológia közötti különbséget. Az Electront gyakran a teljes asztali alkalmazás felépítésére használják, míg a CEF-et sokszor webes funkciók bevezetésére olyan alkalmazásokba, amelyek már jelentős natív összetevőkkel rendelkeznek.
A CEF-re nem szabad kevéssé ismert vagy elavult alternatívaként tekinteni. 2008-ban jött létre, tehát megelőzte az Electront, és hosszú évek óta széles körben használják kereskedelmi szoftverekben. Hosszú története és a jelentős termékekben való folyamatos jelenléte azt mutatja, hogy a Chromium beágyazása továbbra is fontos megközelítés az asztali fejlesztésben.
Az Electron eközben különösen erős ökoszisztémát épített ki a JavaScript-alapú asztali alkalmazások köré. Széles körű elterjedtsége, bevált eszközei és a nagy technológiai vállalatok részvétele vonzóvá teszik a webes technológiákkal új termékeket fejlesztő csapatok számára.
A két keretrendszer erősségei azért különböznek, mert eltérő architekturális követelményeket céloznak meg.
Miért választottuk az Electront a WebCatalognál?
A WebCatalognál azért választottuk az Electront többplatformos asztali alkalmazásaink alapjául, mert jól illeszkedik termékeink követelményeihez.
A WebCatalog lehetővé teszi a felhasználók számára, hogy webhelyekből asztali alkalmazásokat hozzanak létre, több fiókot egymástól függetlenül kezeljenek, és rendszerezzék alkalmazásaikat macOS, Windows és Linux rendszereken. Szoftverünknek több ezer különböző fejlesztő által készített webhelyet kell támogatnia, eltérő hitelesítési rendszerekkel, tárolási mechanizmusokkal, böngésző-API-kkal és JavaScript-keretrendszerekkel.
Az Electron és a CEF egyaránt egységes Chromium-futtatókörnyezetet biztosít, ami fontos a kompatibilitás szempontjából. A rendszer webnézeteire épülő keretrendszerekkel ellentétben lehetővé teszik, hogy minden támogatott asztali platformon egy ismert Chromium-verziót használjunk.
A WebCatalog azonban nem elsősorban olyan natív alkalmazás, amelynek beágyazott böngészőkomponensre van szüksége. A böngészőfunkciók a termékünk központi részét alkotják. Széles körű vezérlésre van szükségünk az ablakok, a munkamenetek, a tárolás, az engedélyek, a navigáció és az alkalmazás életciklusának működése felett.
Az Electron kiforrott API-kat biztosít ezekhez az igényekhez. A BrowserWindow, a webContents és a session interfészek lehetővé teszik számunkra, hogy JavaScript és TypeScript használatával böngészőszerű funkciókat építsünk. A tartós munkamenet-partíciók különösen fontosak, mert lehetővé teszik, hogy a felhasználók ugyanazon a webhelyen több fiókhoz is egymástól független bejelentkezési munkameneteket tartsanak fenn.
A CEF szintén biztosít API-kat a böngészőpéldányok, a kérések, a tárolás és a natív integráció kezeléséhez. Elvileg ugyanazon képességek közül sok CEF-fel is megvalósítható lenne. Ehhez azonban több natív infrastruktúrát kellene saját magunknak felépítenünk és karbantartanunk.
Az Electron Node.js-integrációja szintén illeszkedik az általunk használt technológiai környezethez. Asztali alkalmazásaink logikájának nagy részét TypeScriptben valósíthatjuk meg, kódot oszthatunk meg a termékeink között, és kihasználhatjuk a JavaScript-ökoszisztéma előnyeit.
A többplatformos fejlesztés is fontos szempont. A WebCatalog támogatja a macOS, a Windows és a Linux rendszereket, beleértve a platformspecifikus alkalmazáscsomagolást, integrációkat és rendszerbeli működést. Az Electron bevált API-jai és terjesztési eszközei csökkentik a karbantartandó natív kód mennyiségét.
Tisztában vagyunk azzal, hogy az Electron többletterheléssel jár. A Chromium csomagba foglalása növeli az alkalmazás méretét, a böngészőalapú alkalmazások pedig gondos erőforrás-kezelést igényelnek. Az Electron lecserélése helyett arra összpontosítottunk, hogy hatékonyabban használjuk.
Bevezettük például az APFS-klónokat a létrehozott Mac-alkalmazások lemezterület-használatának csökkentésére, így csökkentettük a redundáns tárolást anélkül, hogy feladtuk volna a Chromium-kompatibilitást.
Döntésünk nem jelenti azt, hogy az Electron minden esetben jobb lenne a CEF-nél. Ha a WebCatalog elsősorban natív alkalmazás lenne néhány beágyazott webes felülettel, a CEF kiváló választás lehetne. Mivel azonban termékünk alapvetően webalkalmazásokra és böngészőfunkciókra épül, az Electron hatékonyabb fejlesztést és könnyebb karbantartást lehetővé tevő alapot biztosít.
Miben előnyösebb a CEF?
Bár a WebCatalognál az Electront részesítjük előnyben, a CEF fontos előnyökkel rendelkezik azoknál az alkalmazásoknál, amelyek mélyebb integrációt igényelnek a natív szoftverrel.
A CEF különösen vonzó, ha a fejlesztőknek már van egy kiforrott C++-alkalmazásuk, és meglévő architektúrájuk lecserélése nélkül szeretnének modern webes felületeket bevezetni.
A képernyőn kívüli renderelés támogatása szintén jelentős előny. Az olyan alkalmazásoknak, mint a streamingszoftverek és a játékmotorok, a hagyományos asztali ablakok helyett közvetlenül egyedi grafikus feldolgozási folyamatokba kellhet renderelniük a webes tartalmat. A CEF bevált API-kat biztosít ezekhez a felhasználási esetekhez.
A CEF emellett széles körű vezérlést biztosít a fejlesztőknek a böngésző integrációja felett. Testre szabhatják a kérések kezelését, a navigációt, a JavaScript-kötéseket, az erőforrás-betöltést és azt, hogyan működnek együtt a böngészőpéldányok a natív alkalmazás-összetevőkkel.
Az erős natív fejlesztési szakértelemmel rendelkező csapatok számára ez a rugalmasság többet érhet az Electron kényelménél.
A CEF-et akkor érdemes megfontolni, ha a cél:
- Webes felületek hozzáadása egy meglévő natív alkalmazáshoz. A fejlesztők megtarthatják a jelenlegi alkalmazásarchitektúrát, és ott ágyazhatják be a Chromiumot, ahol szükséges.
- Egyedi renderelési követelményekkel rendelkező szoftver fejlesztése. A képernyőn kívüli renderelés lehetővé teszi a webes tartalom integrálását grafikus feldolgozási folyamatokba és speciális felületekbe.
- Mély integráció natív C++-funkciókkal. A CEF natív API-kat tesz elérhetővé, és részletes vezérlést biztosít a böngésző működése felett.
- Egy meglévő, kiforrott CEF-alkalmazás karbantartása. Az Electronra való átállás jelentős architekturális változtatásokkal járhat érdemi előnyök nélkül.
- Natív és webes felületek kombinálása. A fejlesztők az alkalmazás kiválasztott részein használhatják a Chromiumot, miközben máshol megtartják a natív felületelemeket.
A CEF nagyobb felelősséget igényel az alkalmazás-infrastruktúra terén. A fejlesztőknek saját maguknak kellhet megvalósítaniuk a csomagolást, a frissítést, az ablakkezelést és a platformspecifikus integrációkat.
A natív alkalmazások karbantartására már felkészült csapatok számára ez teljesen észszerű lehet. Egy új asztali terméket fejlesztő, webes technológiákra összpontosító csapat számára viszont szükségtelen bonyolultságot jelenthet.
Electron vagy CEF: melyiket érdemes választani?
Mindkét technológia kiforrott, aktívan fejlesztik, és alkalmas összetett asztali szoftverek támogatására. A jobb választás elsősorban attól függ, hogy webes technológiák köré építünk-e új asztali alkalmazást, vagy egy meglévő natív alkalmazásba ágyazunk be webes funkciókat.
| Fő szempont | Jobb kiindulópont | Miért? |
|---|---|---|
| Új asztali alkalmazás JavaScript vagy TypeScript használatával | Electron | Teljes alkalmazáskeretrendszer |
| Meglévő natív C++-alkalmazás | CEF | Integrálható a natív architektúrába |
| Minimális natív fejlesztés | Electron | Node.js- és JavaScript-API-k |
| Webes tartalom beágyazása natív ablakokba | CEF | Kifejezetten beágyazásra tervezték |
| Képernyőn kívüli renderelés és egyedi grafikus feldolgozási folyamatok | CEF | Kifejezetten erre szolgáló renderelési API-k |
| Átfogó asztali csomagolási és frissítési eszköztár | Electron | Bevált terjesztési ökoszisztéma |
| Közvetlen integráció natív C++-kóddal | CEF | Natív C- és C++-interfészek |
| Egységes Chromium az asztali platformokon | Bármelyik | Mindkettő tartalmazza a Chromiumot |
| Összetett böngésző-munkamenet-kezelés | Bármelyik | Mindkettő biztosít böngészőkezelési lehetőségeket |
| Kis alkalmazáscsomagok | Egyiknek sincs eredendő előnye | Mindkettő a Chromiummal együtt kerül terjesztésre |
| Meglévő JavaScript-fejlesztőcsapat | Electron | Ismerős fejlesztési technológiák |
| Meglévő CEF-alapú termék | CEF | Elkerülhető a szükségtelen átállás |
A legtöbb webfejlesztő számára, aki új, többplatformos asztali alkalmazás fejlesztésébe kezd, általában az Electron a praktikusabb választás. Biztosítja a teljes termék felépítéséhez szükséges alkalmazásarchitektúrát, natív integrációkat, fejlesztőeszközöket és terjesztési ökoszisztémát anélkül, hogy mindent a nulláról kellene kifejleszteni.
A CEF gyakran jobb választás azoknak a fejlesztőknek, akiknek már van natív alkalmazásuk, vagy speciális böngészőbeágyazási képességekre van szükségük. Rugalmassága és közvetlen natív integrációja különösen hasznossá teszi például játékmotorok, streamingeszközök, ipari alkalmazások és beágyazott webes felületekkel rendelkező összetett natív termékek esetében.
Egyik technológia sem eredendően gyorsabb vagy biztonságosabb. Ezek a tulajdonságok nagymértékben függenek az alkalmazástól, az architektúrájától és a megvalósítás minőségétől.
Záró gondolatok
Az Electron és a Chromium Embedded Framework ugyanarra a böngészőtechnológiára épül, de eltérő problémákat oldanak meg.
Az Electron célja, hogy az asztali alkalmazások fejlesztését elérhetővé tegye a webfejlesztők számára. A Chromiumot, a Node.js-t és a natív asztali API-kat olyan keretrendszerben egyesíti, amellyel a csapatok JavaScript és TypeScript használatával készíthetnek összetett alkalmazásokat.
A CEF-et arra tervezték, hogy a Chromiumot más alkalmazásokba ágyazza be. Alacsonyabb szintű vezérlést biztosít a böngésző integrációja felett, és különösen értékes olyan natív alkalmazások számára, amelyeknek webalapú felületekre vagy speciális renderelési képességekre van szükségük.
Mindkettő bizonyította értékét jelentős, éles környezetben használt szoftverekben. Az Electronra épül például a Visual Studio Code, a Slack, a Discord és a Notion, míg a CEF-et olyan termékek használják, mint a Spotify, a Steam és az OBS Studio.
A WebCatalognál azért választottuk az Electront, mert termékeink alapvetően böngészőfunkciókra épülnek. Egységes Chromium-futtatókörnyezete, kiforrott böngészőkezelési API-jai és JavaScript-ökoszisztémája lehetővé teszik számunkra a többplatformos asztali alkalmazások hatékony fejlesztését és karbantartását.
A CEF továbbra is kiváló választás a natív alkalmazásokkal dolgozó fejlesztőknek, különösen akkor, ha a Chromiumot egy meglévő architektúrába kell beágyazni, nem pedig a teljes termék alapjaként használni.
A döntés végső soron attól függ, mit szeretnénk építeni. Ha teljes asztali alkalmazást szeretnénk létrehozni webes technológiákkal, általában az Electron a jobb kiindulópont. Ha egy natív alkalmazást szeretnénk Chromiummal bővíteni, valószínűleg a CEF a megfelelőbb eszköz.
