เปรียบเทียบ Tauri กับ Electron - ประสิทธิภาพ ขนาดบันเดิล และข้อแลกเปลี่ยนที่เกิดขึ้นจริง
(gethopp.app)- ระหว่างพัฒนาแอปรีโมตคอนโทรลที่มีความหน่วงต่ำมากสำหรับการทำ remote pair programming ทีมได้ เลือกใช้ Tauri เป็นเฟรมเวิร์กของแอป
- เหตุผลที่เลือกคือเรื่องประสิทธิภาพ ประสิทธิภาพการใช้หน่วยความจำ การรองรับ sidecar เป็นต้น
- ด้วยแบ็กเอนด์ที่ใช้ Rust + การใช้ WebView ของระบบ ทำให้ ขนาดแอปและการใช้หน่วยความจำเล็กกว่า Electron มาก
- ใน Tauri v2 ช่องว่างด้านฟีเจอร์ก็ถูกปิดลงอย่างรวดเร็ว โดยมีฟีเจอร์สำคัญอย่าง auto update, sidecar ฯลฯ มาให้ในตัว
- Electron ยังคงทรงพลัง แต่สำหรับความต้องการเฉพาะของ Hopp นั้น Tauri เหมาะสมกว่า
เหตุผลที่ Hopp เลือก Tauri
เบื้องหลัง: การเลือกเฟรมเวิร์กสำหรับแอปข้ามแพลตฟอร์ม
- Hopp ต้องการ เดสก์ท็อปแอปประสิทธิภาพสูง ที่ทำงานได้เหมือนกันบน Windows, macOS, และ Linux
- Electron และ Tauri เป็นตัวเลือกหลัก และ แต่ละตัวก็มีข้อดีข้อเสียที่ชัดเจน
- ทีม Hopp ให้ความสำคัญกับ การบำรุงรักษาระยะยาวและประสิทธิภาพ จึงตัดสินใจเลือก
Tauri vs. Electron: ความแตกต่างเชิงสถาปัตยกรรม
-
โครงสร้างของ Electron
- ต้องรวม Node.js runtime มาด้วย → ทำให้ขนาดแอปใหญ่ขึ้น
- แต่ละหน้าต่างใช้ renderer process แยก (เอนจิน Chromium) → ใช้หน่วยความจำสูง
- การผสานกับระบบในระดับลึกต้องใช้โปรเซสแยกต่างหาก
-
สรุปโครงสร้างของ Tauri
- แบ็กเอนด์เป็น native binary ที่ใช้ Rust → ไม่ต้องมี runtime แยก
- ใช้ WebView ของระบบ (Windows: WebView2, macOS: WKWebView, Linux: WebKitGTK)
- มีประสิทธิภาพด้านหน่วยความจำที่ดีกว่าเมื่อจำนวนหน้าต่างเพิ่มขึ้น แต่ก็ต้องจัดการกับ ปัญหาความไม่สอดคล้องของ browser engine
เปรียบเทียบฟีเจอร์หลัก
- เวลาเริ่มต้น ของทั้ง Tauri และ Electron ถือว่าเร็วทั้งคู่ และแทบไม่รู้สึกถึงความต่าง
- ในด้าน การใช้หน่วยความจำ Tauri ใช้น้อยกว่ามาก
- Tauri ใช้หน่วยความจำประมาณ 172MB
- ขณะที่ Electron ใช้ประมาณ 409MB ซึ่ง กินหน่วยความจำมากกว่าเกือบ 2 เท่า
- ในมุมของ rendering engine
- Tauri ใช้ WebView ที่ฝังมากับระบบปฏิบัติการ ทำให้แอปมีขนาดเล็กและน้ำหนักเบา
- Electron รวมเอนจิน Chromium มาในแอปโดยตรง จึงใช้ทรัพยากรมากกว่า
- ส่วน ภาษาแบ็กเอนด์
- Tauri ใช้ Rust จึงสามารถเขียน native code ประสิทธิภาพสูงได้
- Electron ใช้ JavaScript (Node.js) ซึ่งคุ้นเคยกับนักพัฒนาเว็บมากกว่า แต่ประสิทธิภาพโดยรวมต่ำกว่า
- ด้าน เวลา build ครั้งแรก
- Tauri มีการคอมไพล์ Rust รวมอยู่ด้วย จึง build แรกได้ช้า
- Electron เป็นฐาน JS จึง build แรกได้เร็ว
- เมื่อเทียบ ขนาดแอป
- Tauri มีขนาดประมาณ 8.6MiB และเบามาก
- Electron มีขนาดประมาณ 244MiB ซึ่ง ใหญ่กว่าราว 28 เท่า
เหตุผลชี้ขาดที่ Hopp เลือก Tauri
-
1. แบ็กเอนด์ Rust ประสิทธิภาพสูง
- จำเป็นต้องทำ วิดีโอสตรีมมิงความหน่วงต่ำมากบนพื้นฐาน WebRTC
- ถ้าเป็น Electron ต้องแยกโปรเซสออกมาต่างหาก แต่ Tauri สามารถทำได้โดยตรงในแบ็กเอนด์ Rust
-
2. การรองรับโปรเซส Sidecar
- แยกงานสตรีมมิงและการจัดการอินพุตออกไปเป็น binary แยก เพื่อดูแลจัดการ
- Tauri รองรับ sidecar อย่างเป็นทางการ → จัดการ lifecycle และการสื่อสารได้สะดวก
- ในอนาคตก็กำลังพิจารณาขยายไปสู่ Tauri egui เพื่อการเรนเดอร์เคอร์เซอร์
-
3. การรองรับฟีเจอร์ที่พัฒนาอย่างรวดเร็ว
- Tauri v2 มีฟีเจอร์สำคัญอย่าง auto update มาให้ในตัว
- แม้จะใหม่กว่า Electron แต่ วิสัยทัศน์ที่เน้นความปลอดภัยและประสิทธิภาพ สอดคล้องกับ Hopp
บทสรุป: เฟรมเวิร์กไหนดีกว่ากัน?
- ทั้ง Electron และ Tauri ต่างก็เป็นเฟรมเวิร์กเดสก์ท็อปแอปที่ยอดเยี่ยม
- การเลือกอาจเปลี่ยนไปตามลักษณะของโปรเจกต์
- Electron: พัฒนาได้เร็ว เป็นมิตรกับ JS และมี ecosystem กว้าง
- Tauri: เล็กกว่า เบากว่า เร็วกว่า และเหมาะกับประสิทธิภาพแบบ Rust
- Hopp เลือกใช้ Tauri เพราะ ต้องการเทคโนโลยีสแตกที่เน้นประสิทธิภาพและการจัดวางโปรเซสแยก
6 ความคิดเห็น
ฉันใช้ webui อยู่ครับ/ค่ะ ขนาดก็เล็กและมีการพึ่งพา runtime น้อยกว่ามาก
น่าจะดีถ้ามีการเปรียบเทียบ Wails รวมอยู่ด้วย
ผมกลับตีความว่าในกรณีส่วนใหญ่ Electron ก็น่าจะเพียงพอแล้ว
หรืออาจเป็นเพราะผมยังจำได้ว่าประสบการณ์การสื่อสารระหว่างฝั่งแบ็กเอนด์-ฟรอนต์เอนด์ของ Tauri ในช่วงแรก ๆ ไม่ค่อยดีนัก...
แม้จะคิดว่าความแตกต่างของเอนจินเบราว์เซอร์เป็นประเด็นใหญ่ แต่ถ้าคิดถึงการรองรับที่รวมถึงมือถือด้วย ก็รู้สึกว่าอาจไม่ใช่เรื่องใหญ่มากนัก
ถ้าปัญหาเรื่องขนาดแอปเป็นประเด็นใหญ่ ก็ต้องไปทาง Tauri แบบไม่ต้องลังเลเลยครับ
เรื่องขนาดไฟล์ หน่วยความจำ และความเหมาะสมในการเลือกใช้แบบ sidecar คงต้องลองใช้งานดูสักครั้ง! ขอบคุณสำหรับการแนะนำครับ