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 ใช้แนวทางที่ต่างออกไป แทนที่จะให้เฟรมเวิร์กแอปพลิเคชันเดสก์ท็อปที่ครบวงจร แต่จะช่วยให้นักพัฒนาผสาน 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 เฉพาะแพลตฟอร์ม

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

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

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

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

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

เรื่องนี้ไม่ได้หมายความว่า 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 ระหว่างฟังก์ชันแอปพลิเคชันที่มีสิทธิ์ระดับสูงกับเนื้อหาเว็บ เอกสารด้านความปลอดภัยของ Electron แนะนำให้จำกัดการเข้าถึง 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 น่าสนใจสำหรับทีมที่สร้างผลิตภัณฑ์ใหม่ด้วยเทคโนโลยีเว็บ

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

ทำไม WebCatalog จึงเลือก Electron

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

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

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

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

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

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

การผสาน Electron กับ Node.js ยังสอดคล้องกับชุดเทคโนโลยีที่ทีมวิศวกรรมของเราใช้อีกด้วย เราสามารถพัฒนาตรรกะส่วนใหญ่ของแอปพลิเคชันเดสก์ท็อปด้วย 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 ก็น่าจะเป็นเครื่องมือที่เหมาะสมกว่า