Electron เทียบกับ Chromium Embedded Framework (CEF)

Electron และ Chromium Embedded Framework (CEF) เป็นสองเทคโนโลยีที่ได้รับการยอมรับสำหรับการนำ Chromium มาใช้ในแอปพลิเคชันเดสก์ท็อป ทั้งสองช่วยให้นักพัฒนาสร้างซอฟต์แวร์ที่แสดงเว็บไซต์และอินเทอร์เฟซเว็บสมัยใหม่บน macOS, Windows และ Linux ได้ อย่างไรก็ตาม ทั้งสองมีวัตถุประสงค์พื้นฐานที่แตกต่างกัน

Electron เป็นเฟรมเวิร์กสำหรับพัฒนาแอปพลิเคชันเดสก์ท็อปอย่างครบวงจร ซึ่งรวม Chromium, Node.js และ API แบบเนทีฟของระบบปฏิบัติการเข้าด้วยกัน นักพัฒนาสามารถสร้างแอปพลิเคชันทั้งตัวด้วย JavaScript, TypeScript, HTML และ CSS โดยไม่จำเป็นต้องมีประสบการณ์การเขียนโปรแกรมแบบเนทีฟอย่างเชี่ยวชาญ ส่วน CEF เป็นเฟรมเวิร์กสำหรับฝัง Chromium ลงในแอปพลิเคชันที่มีอยู่แล้วหรือแอปพลิเคชันใหม่ ซึ่งโดยทั่วไปเขียนด้วย C++ หรือภาษาเนทีฟอื่น ๆ

ทั้งสองเทคโนโลยีถูกใช้อย่างแพร่หลายในซอฟต์แวร์ที่ใช้งานจริง Electron เป็นเทคโนโลยีเบื้องหลังแอปพลิเคชันอย่าง Visual Studio Code, Slack, Discord และ Notion ส่วน CEF ถูกใช้ในผลิตภัณฑ์อย่าง Spotify, Steam และ OBS Studio ที่ WebCatalog เราเลือกใช้ Electron เพื่อสร้างแอปพลิเคชันเดสก์ท็อปข้ามแพลตฟอร์มของเรา

แล้วทั้งสองแตกต่างกันอย่างไร และเมื่อใดจึงควรเลือกใช้เทคโนโลยีหนึ่งแทนอีกเทคโนโลยีหนึ่ง?

ภาพรวมการเปรียบเทียบ Electron กับ CEF

แม้ Electron และ CEF จะใช้ Chromium เหมือนกัน แต่ทั้งสองแตกต่างกันอย่างมากในด้านสถาปัตยกรรม ประสบการณ์ของนักพัฒนา และลักษณะการใช้งานที่มุ่งเน้น

คุณสมบัติ	Electron	Chromium Embedded Framework (CEF)
เปิดตัวครั้งแรก	2013	2008
วัตถุประสงค์หลัก	สร้างแอปเดสก์ท็อปอย่างครบวงจร	ฝัง Chromium ลงในแอปพลิเคชันอื่น
เอนจินเบราว์เซอร์	Chromium	Chromium
ภาษาหลัก	JavaScript, TypeScript	C, C++ พร้อมตัวเชื่อมต่อภาษาจากบุคคลที่สาม
มี Node.js รวมมาให้	มี	ไม่มี
การผสานรวมกับเนทีฟ	Electron API และโมดูลเนทีฟของ Node.js	ผสานรวมกับโค้ดเนทีฟโดยตรง
โครงสร้างแอปพลิเคชัน	โปรเซสหลักและโปรเซสเรนเดอร์	แอปพลิเคชันโฮสต์พร้อมโปรเซสย่อยของ Chromium
การเรนเดอร์แบบนอกจอ	ทำได้ผ่านโซลูชันที่ปรับแต่งเอง	มี API รองรับในตัว
ขนาดแอปพลิเคชัน	โดยทั่วไปมีขนาดใหญ่	ขึ้นอยู่กับวิธีผสานรวม แต่ Chromium เองก็มีขนาดมาก
ประสิทธิภาพ	ขึ้นอยู่กับแอปพลิเคชัน	ขึ้นอยู่กับแอปพลิเคชันและวิธีผสานรวม
การรองรับข้ามแพลตฟอร์ม	macOS, Windows, Linux	macOS, Windows, Linux
ระบบนิเวศเครื่องมือจัดแพ็กเกจ	Electron Forge, electron-builder	โดยทั่วไปจัดการโดยแอปพลิเคชันโฮสต์
เหมาะที่สุดสำหรับ	แอปเดสก์ท็อปที่พัฒนาด้วย JavaScript	แอปเนทีฟที่ต้องฝังเนื้อหาเว็บ

ความแตกต่างที่สำคัญที่สุดคือ Electron เป็นเฟรมเวิร์กสำหรับแอปพลิเคชัน ขณะที่ CEF เป็นเฟรมเวิร์กสำหรับฝังเบราว์เซอร์ ทั้งสองจึงไม่จำเป็นต้องใช้แทนกันได้โดยตรง เพราะทำงานอยู่บนระดับนามธรรมที่ต่างกัน

สถาปัตยกรรม: เฟรมเวิร์กครบวงจรเทียบกับเบราว์เซอร์แบบฝัง

Electron รวม Chromium และ Node.js ไว้ในรันไทม์แอปพลิเคชันเดียวกัน นักพัฒนาสร้างโปรเซสหลักเพื่อจัดการหน้าต่างแอปพลิเคชัน เหตุการณ์ในวงจรชีวิต และฟังก์ชันเนทีฟ ขณะที่โปรเซสเรนเดอร์ดูแลอินเทอร์เฟซที่ใช้เทคโนโลยีเว็บ

สถาปัตยกรรมนี้ช่วยให้นักพัฒนาเขียนแอปพลิเคชันส่วนใหญ่ด้วยเครื่องมือ JavaScript และ TypeScript ที่คุ้นเคยได้ Electron มี API สำหรับสร้างหน้าต่าง จัดการเซสชันเบราว์เซอร์ จัดการเมนู แสดงการแจ้งเตือน เข้าถึงกล่องโต้ตอบของระบบ และผสานรวมกับระบบปฏิบัติการ

CEF ใช้แนวทางที่ต่างออกไป แทนที่จะให้เฟรมเวิร์กแอปพลิเคชันเดสก์ท็อปครบวงจร CEF ช่วยให้นักพัฒนาผสาน Chromium เข้ากับแอปพลิเคชันที่ตนสร้างและควบคุมเอง

ตัวอย่างเช่น นักพัฒนาที่สร้างแอปพลิเคชันเนทีฟด้วย C++ สามารถใช้ CEF เพื่อแสดงเนื้อหาเว็บภายในหน้าต่างแอปพลิเคชันที่มีอยู่แล้วได้ ส่วนอินเทอร์เฟซโดยรอบ วงจรชีวิตแอปพลิเคชัน บริการเบื้องหลัง และฟังก์ชันเนทีฟอื่น ๆ ยังคงอยู่ภายใต้การควบคุมของนักพัฒนา

CEF มี API สำหรับจัดการอินสแตนซ์เบราว์เซอร์ การนำทาง การโหลดทรัพยากร การรัน JavaScript และการสื่อสารระหว่างเบราว์เซอร์กับแอปพลิเคชันเนทีฟ นอกจากนี้ยังใช้สถาปัตยกรรมแบบหลายโปรเซสของ Chromium โดยแยกโปรเซสสำหรับการเรนเดอร์และฟังก์ชันเบราว์เซอร์อื่น ๆ

ความแตกต่างนี้ส่งผลต่อวิธีจัดโครงสร้างแอปพลิเคชันของนักพัฒนา เมื่อใช้ Electron โดยทั่วไปแอปพลิเคชันจะสร้างขึ้นโดยมี Chromium และ Node.js เป็นแกนหลัก แต่เมื่อใช้ CEF โดยทั่วไป Chromium จะเป็นเพียงส่วนประกอบหนึ่งภายในแอปพลิเคชันที่ใหญ่กว่า

CEF ยังใช้สร้างแอปพลิเคชันที่มีอินเทอร์เฟซเป็นเว็บเป็นหลักได้เช่นกัน แต่นักพัฒนาจะต้องสร้างโครงสร้างพื้นฐานแอปพลิเคชันส่วนอื่น ๆ ด้วยตนเองมากขึ้น

ข้อเท็จจริงทางประวัติศาสตร์ที่น่าสนใจคือ Electron และ NW.js เวอร์ชันแรก ๆ เคยใช้ CEF ต่อมา Electron เปลี่ยนมาผสานรวมกับ Chromium โดยตรงมากขึ้น เนื่องจากชั้นนามธรรมของ CEF ทำให้บางฟีเจอร์ โดยเฉพาะการผสานรวมกับ Node.js อย่างลึกซึ้ง พัฒนาได้ยาก

สำหรับนักพัฒนาที่ต้องการเฟรมเวิร์กครบวงจรเพื่อสร้างแอปพลิเคชันเดสก์ท็อปด้วยเทคโนโลยีเว็บ โดยทั่วไป Electron เป็นจุดเริ่มต้นที่ตรงไปตรงมากว่า ส่วนนักพัฒนาที่มีแอปพลิเคชันเนทีฟอยู่แล้วและต้องการเพิ่มความสามารถด้านเว็บ CEF อาจเป็นตัวเลือกที่เข้ากับงานได้มากกว่า

ประสบการณ์ของนักพัฒนา: JavaScript เทียบกับการพัฒนาแบบเนทีฟ

ข้อได้เปรียบที่สำคัญที่สุดอย่างหนึ่งของ Electron คือความง่ายในการเข้าถึง นักพัฒนาที่คุ้นเคยกับการพัฒนาเว็บสมัยใหม่สามารถใช้ทักษะเดิมสร้างแอปพลิเคชันเดสก์ท็อปได้ โดยไม่ต้องเรียนรู้ C++ หรือเฟรมเวิร์ก UI เฉพาะแพลตฟอร์ม

การผสานรวมกับ Node.js ของ Electron ช่วยให้เข้าถึงระบบนิเวศแพ็กเกจขนาดใหญ่สำหรับการทำงานกับระบบไฟล์ เครือข่าย ฐานข้อมูล โปรเซสเบื้องหลัง และฟังก์ชันอื่น ๆ ได้ อีกทั้งยังใช้เทคโนโลยีฟรอนต์เอนด์ยอดนิยมอย่าง React, Vue, Svelte และ Angular ได้โดยไม่ต้องเปลี่ยนสถาปัตยกรรมมากนัก

CEF ออกแบบโดยเน้น API ภาษา C และ C++ เป็นหลัก แม้จะมีตัวเชื่อมต่อภาษาจากบุคคลที่สามสำหรับภาษาอย่าง C#, Java, Python และ Delphi แต่นักพัฒนายังคงต้องเข้าใจสถาปัตยกรรมของแอปพลิเคชันเนทีฟ รวมถึงข้อกำหนดด้านโปรเซส เธรด และวงจรชีวิตของ CEF

สำหรับทีมที่ดูแลแอปพลิเคชันเนทีฟอยู่แล้ว สิ่งนี้อาจเป็นข้อดีมากกว่าข้อเสีย CEF ช่วยให้นักพัฒนาเพิ่มอินเทอร์เฟซเว็บสมัยใหม่ได้ โดยไม่ต้องเขียนโค้ดเนทีฟเดิมใหม่หรือเปลี่ยนไปใช้เฟรมเวิร์กแอปพลิเคชันใหม่ทั้งหมด

อย่างไรก็ตาม สำหรับทีมที่เน้น JavaScript และกำลังเริ่มสร้างแอปพลิเคชันเดสก์ท็อปใหม่ โดยทั่วไป CEF ต้องอาศัยการตั้งค่าและงานผสานรวมกับเนทีฟมากกว่า

ความแตกต่างยังครอบคลุมถึงเครื่องมือพัฒนาด้วย Electron ได้ประโยชน์จากเครื่องมือที่เป็นที่ยอมรับอย่าง Electron Forge และ electron-builder ซึ่งช่วยให้การจัดแพ็กเกจ การลงนามโค้ด การเผยแพร่แอปพลิเคชัน และการอัปเดตง่ายขึ้น ส่วน CEF มีชุดไบนารีพร้อมใช้งานและตัวอย่างให้ แต่นักพัฒนามักต้องรับผิดชอบการผสานเฟรมเวิร์กเข้ากับระบบบิลด์และระบบนำไปใช้งานของตนเอง

สิ่งนี้ไม่ได้หมายความว่า CEF มีความสามารถน้อยกว่า แต่สะท้อนถึงวัตถุประสงค์ของมันในฐานะส่วนประกอบที่ฝังลงในแอปได้ แทนที่จะเป็นแพลตฟอร์มพัฒนาแอปพลิเคชันครบวงจร

ประสิทธิภาพ การใช้หน่วยความจำ และขนาดแอปพลิเคชัน

เนื่องจากทั้ง Electron และ CEF ใช้ Chromium จึงไม่มีเทคโนโลยีใดกำจัดภาระการใช้ทรัพยากรที่เกิดจากการรันเอนจินเบราว์เซอร์สมัยใหม่ได้โดยอัตโนมัติ

ทั้งสองเทคโนโลยีอาจใช้หลายโปรเซสสำหรับการเรนเดอร์ การเร่งความเร็วด้วย GPU เครือข่าย และฟังก์ชันเบราว์เซอร์อื่น ๆ การใช้หน่วยความจำและ CPU ขึ้นอยู่กับเนื้อหาที่แสดง จำนวนอินสแตนซ์เบราว์เซอร์ที่ทำงานอยู่ และวิธีที่แอปพลิเคชันจัดการทรัพยากรเป็นอย่างมาก

CEF อาจให้ความยืดหยุ่นมากกว่าเมื่อนำไปผสานกับแอปพลิเคชันเนทีฟที่มีอยู่แล้ว นักพัฒนาสามารถใช้ Chromium เฉพาะส่วนของอินเทอร์เฟซที่ต้องใช้เทคโนโลยีเว็บ ขณะที่พัฒนาฟังก์ชันอื่นด้วยโค้ดเนทีฟโดยตรง

ตัวอย่างเช่น แอปพลิเคชันกราฟิกอาจใช้ CEF สำหรับแผงการตั้งค่าหรืออินเทอร์เฟซเว็บแบบฝัง โดยยังคงใช้โค้ดเนทีฟสำหรับเอนจินเรนเดอร์ การประมวลผลเอกสาร และฟังก์ชันอื่นที่ต้องการประสิทธิภาพสูง

แอปพลิเคชัน Electron ก็รันโค้ดเนทีฟผ่านส่วนเสริมของ Node.js โปรเซสภายนอก หรือโมดูลเนทีฟได้เช่นกัน อย่างไรก็ตาม โดยทั่วไปสถาปัตยกรรมของ Electron มุ่งเน้นให้สร้างตัวแอปพลิเคชันด้วยเทคโนโลยีเว็บ

ความสามารถหนึ่งของ CEF ที่มีประโยชน์เป็นพิเศษคือการเรนเดอร์แบบนอกจอ แทนที่จะแสดงเนื้อหาเว็บในหน้าต่างเบราว์เซอร์แบบปกติ CEF สามารถเรนเดอร์เนื้อหาลงในบัฟเฟอร์ เพื่อให้แอปพลิเคชันโฮสต์นำไปประมวลผลและแสดงผลเองได้ ความสามารถนี้มีประโยชน์ต่อแอปพลิเคชันอย่างเอนจินเกม ซอฟต์แวร์สตรีมมิง และเครื่องมือที่มีระบบเรนเดอร์เฉพาะของตนเอง

Electron สามารถรองรับกระบวนการเรนเดอร์เฉพาะทางผ่านการผสานรวมเพิ่มเติมได้ แต่ CEF มีการเรนเดอร์แบบนอกจอเป็นส่วนหนึ่งของ API สำหรับการฝังที่มีให้ใช้อย่างเป็นระบบอยู่แล้ว

สำหรับนักพัฒนาที่กำลังประเมินประสิทธิภาพ ตัวชี้วัดที่มีประโยชน์มากที่สุด ได้แก่:

• เวลาเริ่มต้นทำงาน: แอปพลิเคชันพร้อมใช้งานได้เร็วเพียงใด
• การใช้หน่วยความจำ: การใช้ทรัพยากรเมื่อแสดงเนื้อหาเบราว์เซอร์และใช้ฟังก์ชันเนทีฟที่เป็นตัวแทนของการใช้งานจริง
• การใช้ CPU: ประสิทธิภาพระหว่างการเรนเดอร์ การนำทาง และการทำงานเบื้องหลัง
• ขนาดแอปพลิเคชัน: ขนาดดาวน์โหลดและพื้นที่ดิสก์ที่ใช้หลังติดตั้ง
• ข้อกำหนดด้านการเรนเดอร์: แอปพลิเคชันต้องใช้หน้าต่างทั่วไปหรือการเรนเดอร์แบบนอกจอที่ปรับแต่งเอง

สิ่งสำคัญอีกประการคือการแยก CEF ออกจากเฟรมเวิร์กที่ใช้เว็บวิวของระบบ CEF รวม Chromium มาด้วย แทนที่จะพึ่งพาเอนจินเบราว์เซอร์ที่ระบบปฏิบัติการติดตั้งไว้ ดังนั้น การเปลี่ยนจาก Electron มาเป็น CEF จึงไม่ได้ทำให้แอปพลิเคชันมีขนาดเล็กลงอย่างมากโดยอัตโนมัติ

นักพัฒนาที่ให้ความสำคัญกับแพ็กเกจแอปพลิเคชันขนาดเล็กเป็นหลักอาจพิจารณาทางเลือกอย่าง Tauri ซึ่งใช้เว็บวิวที่ระบบจัดเตรียมให้

ไม่ควรสรุปว่า Electron หรือ CEF เร็วกว่าอย่างเด็ดขาดโดยไม่ทดสอบวัดประสิทธิภาพจากการพัฒนาใช้งานจริง

ความปลอดภัยและการอัปเดตเบราว์เซอร์

ทั้ง Electron และ CEF อาศัยสถาปัตยกรรมเบราว์เซอร์และกลไกความปลอดภัยของ Chromium แต่นักพัฒนามีหน้าที่กำหนดค่าแอปพลิเคชันให้เหมาะสม

Electron มีฟีเจอร์อย่างการแซนด์บ็อกซ์โปรเซสเรนเดอร์ การแยกบริบท และการสื่อสารผ่าน IPC ระหว่างฟังก์ชันแอปพลิเคชันที่มีสิทธิ์พิเศษกับเนื้อหาเว็บ เอกสารด้านความปลอดภัยแนะนำให้จำกัดการเข้าถึง Node.js ตรวจสอบความถูกต้องของข้อความ IPC อย่างรอบคอบ และถือว่าเนื้อหาที่โหลดจากระยะไกลไม่น่าเชื่อถือ

CEF รองรับสถาปัตยกรรมแบบหลายโปรเซสและการแยกขอบเขตความปลอดภัยของ Chromium เช่นกัน อย่างไรก็ตาม เนื่องจาก CEF ถูกผสานรวมเข้ากับแอปพลิเคชันที่นักพัฒนาควบคุมเอง แอปพลิเคชันโฮสต์จึงมีหน้าที่ตัดสินใจว่าจะเปิดให้ใช้ฟีเจอร์เบราว์เซอร์ สิทธิ์ และความสามารถเนทีฟใดบ้าง

CEF รองรับการเชื่อมโยง JavaScript และการสื่อสารกับเนทีฟ ช่วยให้นักพัฒนาเชื่อมเนื้อหาเว็บเข้ากับฟังก์ชันแอปพลิเคชันได้ อินเทอร์เฟซเหล่านี้ต้องได้รับการออกแบบอย่างรอบคอบ โดยเฉพาะเมื่อแสดงเว็บไซต์ของบุคคลที่สาม

ประเด็นด้านความปลอดภัย	Electron	CEF
การแซนด์บ็อกซ์ของ Chromium	รองรับ	รองรับ
การเข้าถึงเนทีฟด้วยสิทธิ์พิเศษ	Node.js และ Electron API	API เนทีฟของแอปพลิเคชันโฮสต์
การสื่อสารจาก JavaScript ไปยังเนทีฟ	สคริปต์ preload และ IPC	การเชื่อมโยง V8 และการส่งข้อความระหว่างโปรเซส
การแยกเนื้อหาจากระยะไกล	การแซนด์บ็อกซ์โปรเซสเรนเดอร์และการแยกบริบท	การแยกโปรเซสของ Chromium และการควบคุมโดยโฮสต์
การอัปเดตความปลอดภัยของเบราว์เซอร์	อัปเกรดเวอร์ชัน Electron	อัปเกรดเวอร์ชัน CEF
ผู้รับผิดชอบความปลอดภัยของแอปพลิเคชัน	นักพัฒนาแอปพลิเคชัน	นักพัฒนาแอปพลิเคชัน

อีกประเด็นสำคัญคือการบำรุงรักษาเบราว์เซอร์ โดยทั่วไปทั้ง Electron และ CEF จะแจกจ่ายรันไทม์ Chromium ของตนเองมาด้วย ดังนั้นนักพัฒนาต้องเผยแพร่การอัปเดตแอปพลิเคชันเมื่อมีแพตช์แก้ไขความปลอดภัย

CEF มีสาขารีลีสที่อัปเดตตาม Chromium และชุดไบนารีพร้อมใช้งานที่ช่วยให้กระบวนการนี้ง่ายขึ้น ในทำนองเดียวกัน Electron ก็มีรีลีสที่รวมการอัปเดต Chromium และ Node.js อย่างต่อเนื่อง

ไม่มีแนวทางใดขจัดความจำเป็นในการบำรุงรักษาอย่างต่อเนื่องได้ทั้งหมด แอปพลิเคชันที่ใช้ Chromium เวอร์ชันเก่าอาจยังเสี่ยงต่อช่องโหว่ที่โครงการต้นน้ำแก้ไขไปแล้ว

สำหรับทีมที่สร้างซอฟต์แวร์ซึ่งแสดงเว็บไซต์ใด ๆ ก็ได้ ควรมองการบำรุงรักษาความปลอดภัยเป็นส่วนสำคัญของวงจรชีวิตแอปพลิเคชัน ไม่ใช่งานที่ทำเป็นครั้งคราว

การนำไปใช้: แอปพลิเคชันสำคัญที่ใช้ Electron และ CEF

ทั้ง Electron และ CEF ถูกนำไปใช้อย่างกว้างขวางในซอฟต์แวร์ที่ใช้งานจริง แต่มีรูปแบบการใช้งานแตกต่างกัน

Electron พบเห็นได้เด่นชัดในแอปพลิเคชันเดสก์ท็อปยอดนิยมด้านการทำงาน การสื่อสาร และเครื่องมือสำหรับนักพัฒนา Microsoft ใช้ Electron สำหรับ Visual Studio Code ขณะที่ผลิตภัณฑ์ Electron ที่เป็นที่รู้จักอื่น ๆ ได้แก่ Slack, Discord, Notion, Figma, Signal Desktop และ GitHub Desktop

CEF ก็ถูกใช้โดยบริษัทซอฟต์แวร์รายใหญ่เช่นกัน โดยเฉพาะเมื่อต้องผสานอินเทอร์เฟซเว็บเข้ากับแอปพลิเคชันที่มีสถาปัตยกรรมเนทีฟอยู่แล้ว

ตัวอย่าง ได้แก่:

แอปพลิเคชัน	เทคโนโลยี	การใช้งานทั่วไป
Visual Studio Code	Electron	โปรแกรมแก้ไขโค้ดข้ามแพลตฟอร์ม
Slack	Electron	การสื่อสารภายในทีม
Discord	Electron	แพลตฟอร์มการสื่อสารและชุมชน
Notion	Electron	การจดบันทึกและเพิ่มประสิทธิภาพการทำงาน
Figma Desktop	Electron	แอปพลิเคชันออกแบบ
Spotify Desktop	CEF	อินเทอร์เฟซที่ใช้เทคโนโลยีเว็บภายในไคลเอนต์เดสก์ท็อป
Steam	CEF	อินเทอร์เฟซเว็บแบบฝังในไคลเอนต์เดสก์ท็อป
OBS Studio	CEF	แหล่งเนื้อหาจากเบราว์เซอร์ โอเวอร์เลย์ และแผงเบราว์เซอร์แบบด็อก

Spotify เป็นตัวอย่างผู้ใช้ CEF ที่มีเอกสารยืนยันชัดเจนเป็นพิเศษ โดยหน้าโอเพนซอร์สอย่างเป็นทางการ เผยแพร่เวอร์ชัน CEF และ Chromium ที่เกี่ยวข้องกับแต่ละรีลีสของ Spotify Desktop

OBS Studio เป็นอีกตัวอย่างที่ชัดเจนว่าทำไมนักพัฒนาจึงเลือก CEF โดยการผสานรวม obs-browser ใช้ CEF เพื่อให้บริการแหล่งเนื้อหาจากเบราว์เซอร์ ช่วยให้ผู้ใช้แสดงโอเวอร์เลย์ที่ใช้เทคโนโลยีเว็บและเนื้อหาอื่น ๆ ภายในฉากสตรีมได้ CEF เป็นส่วนประกอบของ OBS Studio ไม่ใช่เฟรมเวิร์กที่ใช้สร้างแอปพลิเคชันทั้งหมด

Steam ยังใช้ส่วนประกอบเว็บแบบฝังที่อิง Chromium ภายในไคลเอนต์เดสก์ท็อป โดยผสานอินเทอร์เฟซเว็บเข้ากับโครงสร้างพื้นฐานแอปพลิเคชันเนทีฟที่ใหญ่กว่า

ตัวอย่างเหล่านี้แสดงให้เห็นความแตกต่างระหว่างเทคโนโลยีทั้งสอง Electron มักใช้สร้างแอปพลิเคชันเดสก์ท็อปทั้งตัว ส่วน CEF มักใช้เพิ่มความสามารถด้านเว็บให้กับแอปพลิเคชันที่มีส่วนประกอบเนทีฟจำนวนมากอยู่แล้ว

ไม่ควรมอง CEF ว่าเป็นทางเลือกที่ไม่เป็นที่รู้จักหรือล้าสมัย โครงการนี้เริ่มต้นในปี 2008 ก่อน Electron และถูกใช้อย่างแพร่หลายในซอฟต์แวร์เชิงพาณิชย์มาหลายปี ประวัติอันยาวนานและการใช้งานอย่างต่อเนื่องในผลิตภัณฑ์สำคัญแสดงให้เห็นว่า การฝัง Chromium ยังคงเป็นแนวทางที่สำคัญในการพัฒนาเดสก์ท็อป

ขณะเดียวกัน Electron ได้สร้างระบบนิเวศที่แข็งแกร่งเป็นพิเศษสำหรับแอปพลิเคชันเดสก์ท็อปที่พัฒนาด้วย JavaScript การใช้งานอย่างแพร่หลาย เครื่องมือที่เป็นที่ยอมรับ และการมีส่วนร่วมของบริษัทเทคโนโลยีรายใหญ่ ทำให้ Electron น่าสนใจสำหรับทีมที่สร้างผลิตภัณฑ์ใหม่ด้วยเทคโนโลยีเว็บ

ทั้งสองเฟรมเวิร์กมีจุดแข็งต่างกัน เพราะมุ่งตอบสนองข้อกำหนดด้านสถาปัตยกรรมที่ต่างกัน

เหตุผลที่เราเลือก Electron ที่ WebCatalog

ที่ WebCatalog เราเลือกใช้ Electron เป็นเทคโนโลยีเบื้องหลังแอปพลิเคชันเดสก์ท็อปข้ามแพลตฟอร์มของเรา เพราะสอดคล้องกับข้อกำหนดของผลิตภัณฑ์เราอย่างมาก

WebCatalog ช่วยให้ผู้ใช้เปลี่ยนเว็บไซต์เป็นแอปพลิเคชันเดสก์ท็อป จัดการหลายบัญชีแยกจากกัน และจัดระเบียบแอปพลิเคชันบน macOS, Windows และ Linux ซอฟต์แวร์ของเราต้องรองรับเว็บไซต์ที่สร้างโดยนักพัฒนาหลายพันราย ซึ่งใช้ระบบยืนยันตัวตน กลไกจัดเก็บข้อมูล API เบราว์เซอร์ และเฟรมเวิร์ก JavaScript ที่แตกต่างกัน

ทั้ง Electron และ CEF ให้รันไทม์ Chromium ที่สอดคล้องกัน ซึ่งสำคัญต่อความเข้ากันได้ ต่างจากเฟรมเวิร์กที่ใช้เว็บวิวของระบบ ทั้งสองช่วยให้เราใช้ Chromium เวอร์ชันที่ทราบแน่ชัดบนแพลตฟอร์มเดสก์ท็อปทั้งหมดที่เรารองรับ

อย่างไรก็ตาม WebCatalog ไม่ได้เป็นแอปพลิเคชันเนทีฟเป็นหลักที่เพียงต้องการส่วนประกอบเบราว์เซอร์แบบฝัง ความสามารถของเบราว์เซอร์เป็นหัวใจของผลิตภัณฑ์เรา เราต้องควบคุมหน้าต่าง เซสชัน การจัดเก็บข้อมูล สิทธิ์ การนำทาง และพฤติกรรมวงจรชีวิตแอปพลิเคชันได้อย่างครอบคลุม

Electron มี API ที่พัฒนาจนสมบูรณ์สำหรับข้อกำหนดเหล่านี้ อินเทอร์เฟซ BrowserWindow, webContents และ session ช่วยให้เราสร้างฟังก์ชันคล้ายเบราว์เซอร์ด้วย JavaScript และ TypeScript ได้ พาร์ทิชันเซสชันแบบคงอยู่มีความสำคัญเป็นพิเศษ เพราะช่วยให้ผู้ใช้เก็บเซสชันการลงชื่อเข้าใช้ของหลายบัญชีบนเว็บไซต์เดียวกันแยกจากกันได้

CEF ก็มี API สำหรับจัดการอินสแตนซ์เบราว์เซอร์ คำขอ การจัดเก็บข้อมูล และการผสานรวมกับเนทีฟเช่นกัน ในทางหลักการ เราสามารถพัฒนาความสามารถเดียวกันหลายอย่างด้วย CEF ได้ อย่างไรก็ตาม การทำเช่นนั้นจะทำให้เราต้องสร้างและดูแลโครงสร้างพื้นฐานเนทีฟด้วยตนเองมากขึ้น

การผสานรวมกับ Node.js ของ Electron ยังสอดคล้องกับชุดเทคโนโลยีด้านวิศวกรรมของเรา เราสามารถพัฒนาตรรกะแอปพลิเคชันเดสก์ท็อปส่วนใหญ่ด้วย TypeScript ใช้โค้ดร่วมกันระหว่างผลิตภัณฑ์ และใช้ประโยชน์จากระบบนิเวศ JavaScript ได้

การพัฒนาข้ามแพลตฟอร์มเป็นอีกปัจจัยหนึ่ง WebCatalog รองรับ macOS, Windows และ Linux รวมถึงการจัดแพ็กเกจแอปพลิเคชัน การผสานรวม และพฤติกรรมระบบเฉพาะแพลตฟอร์ม API และเครื่องมือเผยแพร่ที่เป็นที่ยอมรับของ Electron ช่วยลดปริมาณโค้ดเนทีฟที่เราต้องดูแล

เราตระหนักว่า Electron มีภาระการใช้ทรัพยากรเพิ่มเติม การรวม Chromium มาด้วยทำให้แอปพลิเคชันมีขนาดใหญ่ขึ้น และแอปพลิเคชันที่ใช้เทคโนโลยีเบราว์เซอร์ต้องจัดการทรัพยากรอย่างรอบคอบ แทนที่จะเปลี่ยนจาก Electron เราจึงมุ่งปรับปรุงวิธีใช้งานมัน

ตัวอย่างเช่น เรานำ APFS clones มาใช้เพื่อลดการใช้พื้นที่ดิสก์ของแอปพลิเคชัน Mac ที่สร้างขึ้น เพื่อลดการจัดเก็บข้อมูลซ้ำซ้อนโดยไม่ต้องละทิ้งความเข้ากันได้ของ Chromium

การตัดสินใจของเราไม่ได้หมายความว่า Electron ดีกว่า CEF ในทุกกรณี หาก WebCatalog เป็นแอปพลิเคชันเนทีฟเป็นหลักและมีอินเทอร์เฟซเว็บแบบฝังเพียงไม่กี่ส่วน CEF อาจเป็นตัวเลือกที่ยอดเยี่ยม แต่เนื่องจากผลิตภัณฑ์ของเราสร้างขึ้นโดยมีแอปพลิเคชันเว็บและความสามารถของเบราว์เซอร์เป็นพื้นฐาน Electron จึงให้รากฐานที่ช่วยให้พัฒนาได้อย่างมีประสิทธิภาพและดูแลรักษาได้ง่ายกว่า

กรณีที่ CEF ได้เปรียบ

แม้ Electron จะเป็นตัวเลือกที่เราต้องการใช้ที่ WebCatalog แต่ CEF มีข้อได้เปรียบสำคัญสำหรับแอปพลิเคชันที่ต้องผสานรวมกับซอฟต์แวร์เนทีฟอย่างลึกซึ้งกว่า

CEF น่าสนใจเป็นพิเศษเมื่อนักพัฒนามีแอปพลิเคชัน C++ ที่พัฒนาเป็นระบบอยู่แล้ว และต้องการเพิ่มอินเทอร์เฟซเว็บสมัยใหม่โดยไม่ต้องเปลี่ยนสถาปัตยกรรมเดิม

การรองรับการเรนเดอร์แบบนอกจอเป็นข้อได้เปรียบสำคัญอีกประการหนึ่ง แอปพลิเคชันอย่างซอฟต์แวร์สตรีมมิงและเอนจินเกมอาจต้องเรนเดอร์เนื้อหาเว็บเข้าสู่ไปป์ไลน์กราฟิกที่ปรับแต่งเองโดยตรง แทนการแสดงในหน้าต่างเดสก์ท็อปทั่วไป CEF มี API ที่พร้อมใช้งานสำหรับกรณีเหล่านี้

CEF ยังให้นักพัฒนาควบคุมการผสานรวมเบราว์เซอร์ได้อย่างมาก โดยสามารถปรับแต่งการจัดการคำขอ การนำทาง การเชื่อมโยง JavaScript การโหลดทรัพยากร และวิธีที่อินสแตนซ์เบราว์เซอร์โต้ตอบกับส่วนประกอบแอปพลิเคชันเนทีฟ

สำหรับทีมที่มีความเชี่ยวชาญด้านการพัฒนาเนทีฟสูง ความยืดหยุ่นนี้อาจมีน้ำหนักมากกว่าความสะดวกของ Electron

CEF เป็นตัวเลือกที่ควรพิจารณาเมื่อ:

• เพิ่มอินเทอร์เฟซเว็บให้แอปพลิเคชันเนทีฟที่มีอยู่แล้ว นักพัฒนาสามารถคงสถาปัตยกรรมแอปพลิเคชันเดิมไว้ และฝัง Chromium เฉพาะจุดที่ต้องการ
• สร้างซอฟต์แวร์ที่มีข้อกำหนดการเรนเดอร์เฉพาะ การเรนเดอร์แบบนอกจอช่วยให้ผสานเนื้อหาเว็บเข้ากับไปป์ไลน์กราฟิกและอินเทอร์เฟซเฉพาะทางได้
• ผสานรวมกับฟังก์ชันเนทีฟ C++ อย่างลึกซึ้ง CEF เปิดให้ใช้ API เนทีฟและควบคุมพฤติกรรมเบราว์เซอร์ได้อย่างละเอียด
• ดูแลแอปพลิเคชัน CEF ที่มีอยู่แล้ว การย้ายไป Electron อาจทำให้ต้องเปลี่ยนสถาปัตยกรรมอย่างมากโดยไม่ได้ประโยชน์ที่มีนัยสำคัญ
• ผสมผสานอินเทอร์เฟซเนทีฟกับเว็บ นักพัฒนาสามารถใช้ Chromium กับบางส่วนของแอปพลิเคชัน และคงส่วนประกอบ UI เนทีฟไว้ในส่วนอื่น

CEF ทำให้นักพัฒนาต้องรับผิดชอบโครงสร้างพื้นฐานแอปพลิเคชันมากขึ้น โดยอาจต้องพัฒนาระบบจัดแพ็กเกจ อัปเดต จัดการหน้าต่าง และการผสานรวมเฉพาะแพลตฟอร์มด้วยตนเอง

สำหรับทีมที่พร้อมดูแลแอปพลิเคชันเนทีฟอยู่แล้ว สิ่งนี้อาจสมเหตุสมผลอย่างยิ่ง แต่สำหรับทีมที่เน้นเว็บและกำลังสร้างผลิตภัณฑ์เดสก์ท็อปใหม่ อาจเพิ่มความซับซ้อนโดยไม่จำเป็น

Electron กับ CEF: ควรเลือกอะไร?

ทั้งสองเทคโนโลยีมีความ成熟 พัฒนาอย่างต่อเนื่อง และรองรับซอฟต์แวร์เดสก์ท็อปที่ซับซ้อนได้ ตัวเลือกที่เหมาะกว่าขึ้นอยู่กับว่าคุณกำลังสร้างแอปพลิเคชันเดสก์ท็อปใหม่โดยมีเทคโนโลยีเว็บเป็นแกนหลัก หรือกำลังฝังความสามารถด้านเว็บลงในแอปพลิเคชันเนทีฟที่มีอยู่แล้วเป็นสำคัญ

สิ่งที่คุณให้ความสำคัญ	จุดเริ่มต้นที่เหมาะกว่า	เหตุผล
แอปเดสก์ท็อปใหม่ที่ใช้ JavaScript หรือ TypeScript	Electron	เฟรมเวิร์กแอปพลิเคชันครบวงจร
แอปพลิเคชันเนทีฟ C++ ที่มีอยู่แล้ว	CEF	ผสานเข้ากับสถาปัตยกรรมเนทีฟได้
ลดงานพัฒนาเนทีฟให้เหลือน้อยที่สุด	Electron	Node.js และ JavaScript API
ฝังเนื้อหาเว็บในหน้าต่างเนทีฟ	CEF	ออกแบบมาเพื่อการฝังโดยเฉพาะ
การเรนเดอร์แบบนอกจอและไปป์ไลน์กราฟิกที่ปรับแต่งเอง	CEF	API สำหรับการเรนเดอร์โดยเฉพาะ
เครื่องมือจัดแพ็กเกจและอัปเดตแอปเดสก์ท็อปที่ครอบคลุม	Electron	ระบบนิเวศการเผยแพร่ที่เป็นที่ยอมรับ
ผสานรวมกับโค้ดเนทีฟ C++ โดยตรง	CEF	อินเทอร์เฟซเนทีฟภาษา C และ C++
Chromium ที่สอดคล้องกันบนแพลตฟอร์มเดสก์ท็อปต่าง ๆ	ได้ทั้งคู่	ทั้งสองรวม Chromium มาด้วย
การจัดการเซสชันเบราว์เซอร์ที่ซับซ้อน	ได้ทั้งคู่	ทั้งสองมีความสามารถในการจัดการเบราว์เซอร์
แพ็กเกจแอปพลิเคชันขนาดเล็ก	ไม่มีตัวใดได้เปรียบโดยตัวมันเอง	ทั้งสองแจกจ่าย Chromium มาด้วย
ทีมวิศวกรรม JavaScript ที่มีอยู่แล้ว	Electron	ชุดเทคโนโลยีการพัฒนาที่คุ้นเคย
ผลิตภัณฑ์ที่ใช้ CEF อยู่แล้ว	CEF	หลีกเลี่ยงการย้ายเทคโนโลยีที่ไม่จำเป็น

สำหรับนักพัฒนาเว็บส่วนใหญ่ที่กำลังเริ่มสร้างแอปพลิเคชันเดสก์ท็อปข้ามแพลตฟอร์มใหม่ โดยทั่วไป Electron เป็นตัวเลือกที่ใช้งานได้จริงกว่า เพราะมีสถาปัตยกรรมแอปพลิเคชัน การผสานรวมกับเนทีฟ เครื่องมือพัฒนา และระบบนิเวศการเผยแพร่ที่จำเป็นต่อการสร้างผลิตภัณฑ์ครบวงจร โดยไม่ต้องพัฒนาทุกอย่างตั้งแต่ต้น

CEF มักเป็นตัวเลือกที่ดีกว่าสำหรับนักพัฒนาที่มีแอปพลิเคชันเนทีฟอยู่แล้ว หรือต้องการความสามารถเฉพาะทางในการฝังเบราว์เซอร์ ความยืดหยุ่นและการผสานรวมกับเนทีฟโดยตรงทำให้ CEF มีประโยชน์เป็นพิเศษสำหรับซอฟต์แวร์อย่างเอนจินเกม เครื่องมือสตรีมมิง แอปพลิเคชันอุตสาหกรรม และผลิตภัณฑ์เนทีฟที่ซับซ้อนซึ่งมีอินเทอร์เฟซเว็บแบบฝัง

ไม่มีเทคโนโลยีใดเร็วหรือปลอดภัยกว่าโดยตัวมันเอง คุณสมบัติเหล่านั้นขึ้นอยู่กับแอปพลิเคชัน สถาปัตยกรรม และคุณภาพการพัฒนาเป็นอย่างมาก

บทสรุป

Electron และ Chromium Embedded Framework ใช้เทคโนโลยีเบราว์เซอร์พื้นฐานเดียวกัน แต่แก้ปัญหาคนละประเภท

Electron ออกแบบมาเพื่อให้นักพัฒนาเว็บเข้าถึงการพัฒนาแอปพลิเคชันเดสก์ท็อปได้ง่ายขึ้น โดยรวม Chromium, Node.js และ API เดสก์ท็อปแบบเนทีฟไว้ในเฟรมเวิร์กที่ช่วยให้ทีมสร้างแอปพลิเคชันที่ซับซ้อนด้วย JavaScript และ TypeScript ได้

CEF ออกแบบมาเพื่อฝัง Chromium ลงในแอปพลิเคชันอื่น โดยให้การควบคุมการผสานรวมเบราว์เซอร์ในระดับล่าง และมีคุณค่าเป็นพิเศษสำหรับแอปพลิเคชันเนทีฟที่ต้องการอินเทอร์เฟซที่ใช้เทคโนโลยีเว็บหรือความสามารถในการเรนเดอร์เฉพาะทาง

ทั้งสองพิสูจน์คุณค่าผ่านซอฟต์แวร์สำคัญที่ใช้งานจริงแล้ว Electron เป็นเทคโนโลยีเบื้องหลังแอปพลิเคชันอย่าง Visual Studio Code, Slack, Discord และ Notion ส่วน CEF ถูกใช้ในผลิตภัณฑ์อย่าง Spotify, Steam และ OBS Studio

ที่ WebCatalog เราเลือก Electron เพราะผลิตภัณฑ์ของเราสร้างขึ้นโดยมีความสามารถของเบราว์เซอร์เป็นพื้นฐาน รันไทม์ Chromium ที่สอดคล้องกัน API จัดการเบราว์เซอร์ที่พัฒนาจนสมบูรณ์ และระบบนิเวศ JavaScript ช่วยให้เราพัฒนาและดูแลแอปพลิเคชันเดสก์ท็อปข้ามแพลตฟอร์มได้อย่างมีประสิทธิภาพ

CEF ยังคงเป็นตัวเลือกที่ยอดเยี่ยมสำหรับนักพัฒนาที่ทำงานกับแอปพลิเคชันเนทีฟ โดยเฉพาะเมื่อต้องฝัง Chromium ลงในสถาปัตยกรรมที่มีอยู่แล้ว แทนที่จะใช้เป็นรากฐานของผลิตภัณฑ์ทั้งหมด

ท้ายที่สุด การตัดสินใจขึ้นอยู่กับสิ่งที่คุณกำลังสร้าง หากต้องการสร้างแอปพลิเคชันเดสก์ท็อปครบวงจรด้วยเทคโนโลยีเว็บ โดยทั่วไป Electron เป็นจุดเริ่มต้นที่ดีกว่า แต่หากต้องการเพิ่ม Chromium ลงในแอปพลิเคชันเนทีฟ CEF น่าจะเป็นเครื่องมือที่เหมาะสมกว่า