ถ้าคุณใช้เวลาอ่าน Hacker News หรือ Reddit มากพอ ในที่สุดคุณก็จะพบคำวิจารณ์เดิม ๆ ว่า Electron เทอะทะ Electron ใช้หน่วยความจำมากเกินไป และแอปพลิเคชันเดสก์ท็อปที่จริงจังควรเป็นแอปเนทีฟ
คำวิจารณ์นั้นมีส่วนจริงอยู่บ้าง โดยทั่วไปแอปพลิเคชัน Electron มีขนาดและการใช้ทรัพยากรพื้นฐานสูงกว่า เพราะมาพร้อมกับ Chromium และ Node.js แอปพลิเคชันเนทีฟที่ได้รับการออกแบบอย่างพิถีพิถันสามารถใช้หน่วยความจำน้อยกว่า เปิดได้เร็วกว่า และผสานเข้ากับระบบปฏิบัติการได้ลึกกว่า
แต่การถกเถียงนี้ให้ความสำคัญกับคอมพิวเตอร์มากเกินไป และให้ความสำคัญกับบริษัทที่สร้างซอฟต์แวร์น้อยเกินไป
สำหรับผู้ใช้ส่วนใหญ่ เทคโนโลยีเบื้องหลังแอปพลิเคชันแทบไม่มีความสำคัญ พวกเขาสนใจว่ามันใช้งานได้หรือไม่ ตอบสนองรวดเร็วหรือไม่ บั๊กได้รับการแก้ไขหรือไม่ และมีฟีเจอร์ที่เป็นประโยชน์เพิ่มเข้ามาเรื่อย ๆ หรือไม่ ดังนั้น สำหรับบริษัทซอฟต์แวร์ คุณสมบัติที่สำคัญที่สุดอย่างหนึ่งของชุดเทคโนโลยีจึงเป็นสิ่งที่แทบไม่ปรากฏในตารางผลทดสอบประสิทธิภาพ นั่นคือ ทีมสามารถสร้าง ส่งมอบ เรียนรู้ และปรับปรุงผลิตภัณฑ์ได้เร็วเพียงใด?
สำหรับแอปพลิเคชันเดสก์ท็อปสมัยใหม่จำนวนมาก Electron ทำเรื่องนี้ได้ดีเป็นพิเศษ
ทรัพยากรที่ขาดแคลนคือเวลาของวิศวกร
บริษัทผู้พัฒนาซอฟต์แวร์เดสก์ท็อปเนทีฟในอุดมคติมีทีม macOS ที่ยอดเยี่ยม มีอีกทีมสร้างแอปพลิเคชัน Windows และอาจมีอีกทีมดูแล Linux แอปพลิเคชันแต่ละตัวได้รับการปรับแต่งอย่างพิถีพิถันสำหรับแพลตฟอร์มของตน และวิศวกรทุกคนเข้าใจระบบปฏิบัติการที่ตนทำงานด้วยอย่างลึกซึ้ง
บริษัทส่วนใหญ่ไม่ได้มีทรัพยากรพร้อมขนาดนั้น
ผลิตภัณฑ์เดสก์ท็อปหนึ่งตัวอาจมีวิศวกรห้าคน หรืออาจมีเพียงสองคน วิศวกรกลุ่มเดียวกันนี้ต้องสร้างฟีเจอร์ แก้บั๊ก ปรับปรุงประสิทธิภาพ ตอบคำถามลูกค้า ดูแลโครงสร้างพื้นฐาน รับมือกับการเปลี่ยนแปลงของระบบปฏิบัติการ และทำให้ผลิตภัณฑ์เดินหน้าต่อไป
การพัฒนาแบบเนทีฟทำให้เรื่องนี้ยากขึ้น เพราะ macOS, Windows และ Linux เป็นแพลตฟอร์มที่แตกต่างกันจริง ๆ ทั้งเฟรมเวิร์ก UI, API, ระบบสิทธิ์การเข้าถึง, พฤติกรรมตลอดวงจรชีวิตของแอป, โปรแกรมติดตั้ง, กลไกอัปเดต, ระบบแจ้งเตือน, การจัดการหน้าต่าง, API ด้านการเข้าถึงสำหรับผู้พิการ และลักษณะเฉพาะของแต่ละแพลตฟอร์มที่สะสมมานานหลายปี
Electron เปลี่ยนสมการนี้ โดยรวม Chromium, Node.js และ API สำหรับเดสก์ท็อปเข้าด้วยกันเป็นโมเดลแอปพลิเคชันร่วมกันบน macOS, Windows และ Linux วิศวกร TypeScript คนเดียวมักสามารถสร้างฟีเจอร์ได้ตั้งแต่ส่วนติดต่อผู้ใช้ไปจนถึงตรรกะของแอปพลิเคชัน แล้วส่งมอบบนทุกแพลตฟอร์มเดสก์ท็อปได้ โค้ดเนทีฟยังคงใช้ได้เมื่อจำเป็นจริง ๆ แต่กลายเป็นข้อยกเว้นแทนที่จะเป็นรากฐานของผลิตภัณฑ์ Electron เองก็อธิบายว่านี่คือข้อได้เปรียบหลักอย่างหนึ่งของตน นั่นคือใช้ฐานโค้ด JavaScript ชุดเดียวบนแพลตฟอร์มเดสก์ท็อปหลักทั้งสาม
ความแตกต่างนี้ส่งผลทบต้นตลอดหลายปี หากทุกฟีเจอร์สำคัญต้องพัฒนาแยกกันสำหรับ Mac และ Windows บริษัทก็ต้องจ่ายต้นทุนจากการแยกแพลตฟอร์มซ้ำแล้วซ้ำเล่า ไม่ว่าจะเป็นฟีเจอร์ใหม่ การออกแบบใหม่ การทดลอง การแก้บั๊ก การปรับปรุงการเข้าถึงสำหรับผู้พิการ หรือการเพิ่มประสิทธิภาพ
เมื่อใช้ Electron งานเหล่านั้นจำนวนมากทำเพียงครั้งเดียว
Electron มุ่งเพิ่มความเร็วในการพัฒนาปรับปรุงเป็นรอบ ๆ
ผลิตภัณฑ์แทบไม่เคยยอดเยี่ยมเพราะการพัฒนาครั้งแรกสมบูรณ์แบบ แต่ยอดเยี่ยมขึ้นได้ด้วยการปรับปรุงซ้ำเป็นรอบ ๆ
ทีมส่งมอบบางอย่างออกไป ลูกค้าใช้งาน ทีมได้เรียนรู้ ทีมปรับเปลี่ยนฟีเจอร์ มีผู้ใช้เพิ่มขึ้น ปัญหาอีกอย่างเริ่มปรากฏ ทีมปรับปรุงอีกครั้ง
ยิ่งวงจรระหว่างแนวคิด การลงมือพัฒนา ข้อเสนอแนะ และการปรับปรุงสั้นลงเท่าไร ผลิตภัณฑ์ก็ยิ่งดีขึ้นเร็วเท่านั้น
Electron ย่นวงจรนี้ได้ดีเป็นพิเศษ เพราะสร้างขึ้นบนเทคโนโลยีที่บริษัทซอฟต์แวร์ใช้อยู่แล้วอย่างแพร่หลาย ได้แก่ JavaScript, TypeScript, HTML, CSS, React, Chromium, Node.js และ npm
นั่นหมายความว่าบริษัทสามารถใช้ร่วมกันได้มากกว่าแค่ซอร์สโค้ด ทั้งวิศวกร คอมโพเนนต์ UI เครื่องมือ ไลบรารี โครงสร้างพื้นฐาน แนวทางการทดสอบ และองค์ความรู้ภายในองค์กร สามารถใช้ร่วมกันระหว่างผลิตภัณฑ์เว็บและเดสก์ท็อปได้
วิศวกรฟรอนต์เอนด์ไม่ได้กลายเป็นคนที่ช่วยอะไรไม่ได้ทันที เพียงเพราะบริษัทต้องการความช่วยเหลือกับไคลเอนต์ Windows วิศวกรเดสก์ท็อปสามารถร่วมพัฒนาเว็บแอปพลิเคชันได้ วิศวกร TypeScript แบบฟูลสแต็กสามารถย้ายไปทำผลิตภัณฑ์อื่นได้เมื่อความสำคัญของงานเปลี่ยนไป
สำหรับบริษัทขนาดเล็กหรือกลาง ความยืดหยุ่นนี้อาจมีค่ามากกว่าการประหยัด RAM 100 MB อย่างมาก
ลองดูว่าใครใช้ Electron จริง ๆ
บางครั้ง Electron ถูกมองว่าเป็นทางลัดสำหรับบริษัทที่ไม่ยอมลงทุนสร้างแอปพลิเคชันเดสก์ท็อปที่ “เหมาะสม” แต่ผลิตภัณฑ์ที่สร้างด้วย Electron ทำให้ข้อโต้แย้งนั้นยืนหยัดได้ยากขึ้นเรื่อย ๆ
โครงการ Electron เองนำเสนอผลิตภัณฑ์อย่าง Slack, Discord, Signal, ChatGPT, Claude, Visual Studio Code, Notion, Docker, Loom และ Canva ผลิตภัณฑ์เหล่านี้ไม่ใช่เครื่องมือเล็ก ๆ เรียบง่าย หลายตัวอยู่ในกลุ่มแอปพลิเคชันเพื่อเพิ่มประสิทธิภาพการทำงานที่ซับซ้อนและใช้กันแพร่หลายที่สุดในโลก
Visual Studio Code เป็นตัวอย่างที่มีประโยชน์อย่างยิ่ง Microsoft สามารถสร้างโปรแกรมแก้ไขโค้ดเรือธงของตนด้วยเทคโนโลยี Windows แทบทุกชนิดที่ต้องการได้ แต่ VS Code กลับใช้ Electron บน Windows, macOS และ Linux โดยมีทั้งเทอร์มินัล การดีบัก เซิร์ฟเวอร์ภาษา การผสานกับ Git การพัฒนาจากระยะไกล โน้ตบุ๊ก ส่วนขยาย และตัวแก้ไขที่ปรับแต่งได้อย่างละเอียด
คำถามที่น่าสนใจไม่ใช่ว่า Microsoft จะประหยัดหน่วยความจำได้หรือไม่ด้วยการสร้างเวอร์ชันเนทีฟแยกกันสามตัว แน่นอนว่าทำได้
คำถามที่ดีกว่าคือ VS Code จะพัฒนาได้เร็วขนาดนี้ รักษาความสอดคล้องระหว่างแพลตฟอร์มได้ขนาดนี้ และสร้างระบบนิเวศที่ใหญ่ขนาดนี้ได้หรือไม่ หากความสามารถสำคัญทุกอย่างต้องถูกพัฒนาแยกกันหลายชุด
ChatGPT และ Claude แสดงให้เห็นความแตกต่างของแนวทาง
ความแตกต่างระหว่าง ChatGPT และ Claude ก็ให้บทเรียนที่น่าสนใจเช่นกัน
ในช่วงแรก OpenAI สร้างแอปพลิเคชัน ChatGPT สำหรับ macOS โดยเฉพาะแบบเนทีฟ ขณะที่ Anthropic สร้าง Claude Desktop บน Electron และมีรากฐานเดสก์ท็อปร่วมกันข้ามแพลตฟอร์มตั้งแต่ต้น
ความแตกต่างนี้ยิ่งสำคัญขึ้นเมื่อผลิตภัณฑ์ขยายตัว Claude Desktop สามารถเพิ่มความสามารถอย่างการผสานกับ MCP ส่วนขยาย และ Claude Code เข้าไปในแอปพลิเคชันข้ามแพลตฟอร์มตัวเดียวกันได้อย่างต่อเนื่อง ตอนนี้ Anthropic รองรับ Claude Code โดยตรงภายในประสบการณ์เดสก์ท็อปของตน รวมถึงการใช้งานหลายเซสชันทั้งในเครื่องและระยะไกล
ต่อมา OpenAI ก็ขยับแนวทางเดสก์ท็อปข้ามแพลตฟอร์มรุ่นใหม่ไปทาง Electron เช่นกัน และตอนนี้ Electron ระบุทั้ง ChatGPT และ Claude ไว้ในรายชื่อแอปพลิเคชัน Electron ที่โดดเด่น
การอ้างว่า Electron เพียงอย่างเดียวอธิบายความแตกต่างด้านความเร็วในการพัฒนาผลิตภัณฑ์คงเป็นการกล่าวเกินไป ขนาดทีม ลำดับความสำคัญ กลยุทธ์ผลิตภัณฑ์ และการจัดองค์กรภายในล้วนมีผล แต่ข้อได้เปรียบทางสถาปัตยกรรมนั้นชัดเจน รากฐานร่วมกันข้ามแพลตฟอร์มทำให้ส่งมอบฟีเจอร์บนระบบปฏิบัติการต่าง ๆ ได้ง่ายขึ้น โดยไม่ต้องดูแลโค้ดที่พัฒนาแยกกัน
นี่คือข้อได้เปรียบที่จะยิ่งมีค่ามากขึ้นเมื่อผลิตภัณฑ์เดสก์ท็อปเติบโต
Evernote ได้เรียนรู้ต้นทุนของการดูแลไคลเอนต์แยกกัน
Evernote เป็นหนึ่งในตัวอย่างจากอดีตที่ชัดเจนที่สุดของปัญหานี้
หลายปีที่ผ่านมา Evernote ดูแลแอปพลิเคชันที่แตกต่างกันบน Mac, Windows, อุปกรณ์มือถือ และเว็บ เมื่อเวลาผ่านไป ผลิตภัณฑ์เหล่านั้นสะสมทั้งพฤติกรรมที่แตกต่าง ความแตกต่างด้านการแสดงผล สมมติฐานจากระบบเดิม และปัญหาการซิงโครไนซ์
ในปี 2020 Evernote สร้างแอปพลิเคชัน Windows และ Mac ใหม่บนฐานโค้ดร่วมกัน บริษัทกล่าวว่ารากฐานใหม่นี้จะทำให้แอปเสถียรขึ้น แก้บั๊กได้เร็วขึ้น ส่งมอบฟีเจอร์ได้บ่อยขึ้น และปรับปรุงการซิงโครไนซ์ระหว่างแพลตฟอร์ม
การย้ายครั้งนั้นไม่ได้ราบรื่นไร้ปัญหา และผู้ใช้เก่าบางคนไม่ชอบที่ฟีเจอร์เฉพาะแพลตฟอร์มบางอย่างหายไปในช่วงแรก แต่เหตุผลที่ Evernote ยอมเขียนระบบใหม่ด้วยต้นทุนสูงเช่นนี้น่าสนใจกว่าปัญหาของการย้ายเสียอีก
เมื่อผลิตภัณฑ์มีตัวแก้ไขที่รองรับความสามารถมากมาย การจัดเก็บข้อมูลออฟไลน์ การค้นหา ไฟล์แนบ การทำงานร่วมกัน งาน ปฏิทิน และการซิงโครไนซ์ที่ซับซ้อน การดูแลระบบที่พัฒนาแยกกันหลายชุดก็มีต้นทุนสูงขึ้นเรื่อย ๆ บั๊กแสดงอาการต่างกัน การแสดงผลต่างกัน ตรรกะการซิงโครไนซ์มีปฏิสัมพันธ์กับสถาปัตยกรรมภายในเครื่องที่ต่างกัน การเปลี่ยนแปลงสำคัญทุกอย่างของผลิตภัณฑ์ต้องถูกนำไปใช้กับไคลเอนต์หลายตัว
สถาปัตยกรรมร่วมกันไม่ได้ทำให้ปัญหายาก ๆ หายไป แต่ช่วยให้บริษัทแก้ปัญหาได้มากขึ้นโดยทำเพียงครั้งเดียว
Linux อาจเป็นข้อได้เปรียบของ Electron ที่ถูกมองข้ามมากที่สุด
Linux ทำให้เหตุผลสนับสนุน Electron ยิ่งหนักแน่นขึ้น
การรองรับ Linux อย่างเหมาะสมเป็นเรื่องยาก ต่างจาก macOS หรือ Windows เพราะ “เดสก์ท็อป Linux” ไม่ใช่แพลตฟอร์มเดียวที่ถูกควบคุมอย่างเข้มงวด นักพัฒนาต้องรับมือกับดิสทริบิวชัน รูปแบบแพ็กเกจ สภาพแวดล้อมเดสก์ท็อป ชุดเทคโนโลยีกราฟิก ไลบรารีระบบ และโพรโทคอลการแสดงผลที่แตกต่างกัน
สำหรับบริษัทซอฟต์แวร์จำนวนมาก การตัดสินใจทางธุรกิจที่สมเหตุสมผลก็คือไม่รองรับ Linux ไปเลย
Electron เปลี่ยนความคุ้มค่าทางเศรษฐศาสตร์นี้
เนื่องจาก Electron มีสภาพแวดล้อมรันไทม์ร่วมกันบน macOS, Windows และ Linux การเพิ่มการรองรับ Linux จึงอาจง่ายกว่าการดูแลเวอร์ชันเนทีฟสำหรับ Linux แยกต่างหากอย่างมาก นี่คือเหตุผลหนึ่งที่ผู้ใช้ Linux ในปัจจุบันเข้าถึงแอปพลิเคชันเดสก์ท็อปหลักจำนวนมากได้ ทั้งที่ในอดีตแอปเหล่านั้นอาจไม่เคยมีไคลเอนต์ Linux อย่างเป็นทางการเลย
Visual Studio Code, Slack, Discord, Signal, 1Password, Postman, Obsidian และเครื่องมืออื่น ๆ อีกมากสามารถรองรับ Linux ได้โดยไม่ต้องดูแลแอปพลิเคชัน GTK หรือ Qt ที่แยกต่างหากอย่างสิ้นเชิง
Electron ยังรับภาระความซับซ้อนเฉพาะของ Linux จำนวนมากแทนนักพัฒนาแอปพลิเคชัน ตัวอย่างที่ดีคือการเปลี่ยนจาก X11 ไปเป็น Wayland ผู้ดูแล Electron อธิบายว่าการเปลี่ยนผ่านไปสู่ Wayland ของ Chromium ช่วยพาแอปพลิเคชัน Electron ตามไปด้วยอย่างมีประสิทธิภาพ ลดงานเกี่ยวกับระบบแสดงผลที่แต่ละทีมต้องทำเอง
หากไม่มีเฟรมเวิร์กอย่าง Electron หลายบริษัทคงไม่สร้างไคลเอนต์เนทีฟสำหรับ Linux แต่จะรองรับเพียง macOS และ Windows แล้วปล่อยให้ผู้ใช้ Linux ใช้งานผ่านแท็บเบราว์เซอร์
Electron น่าจะทำประโยชน์ให้ซอฟต์แวร์เดสก์ท็อปเชิงพาณิชย์บน Linux มากกว่าที่ได้รับการยอมรับ
แม้แต่ Microsoft ก็เลือกเทคโนโลยีเว็บมากขึ้นเรื่อย ๆ
Microsoft อาจเป็นตัวอย่างโต้แย้งที่ชัดเจนที่สุดต่อแนวคิดที่ว่าซอฟต์แวร์ Windows ที่จริงจังควรใช้เฟรมเวิร์ก UI แบบเนทีฟของ Windows เสมอ
Microsoft ควบคุม Windows รวมถึง Win32, .NET, WinUI, WebView2 และองค์ประกอบส่วนใหญ่ของแพลตฟอร์มที่นักพัฒนาใช้สร้างซอฟต์แวร์ หากการพัฒนา Windows แบบเนทีฟเต็มรูปแบบเป็นคำตอบที่ชัดเจนเสมอ Microsoft ก็น่าจะอยู่ในตำแหน่งที่ดีที่สุดที่จะใช้แนวทางนั้นทุกที่
แต่ก็ไม่ได้ทำเช่นนั้น
Visual Studio Code ใช้ Electron ส่วน Teams ยังคงสร้างบน React, TypeScript และ Chromium แม้ Microsoft จะเปลี่ยนจาก Electron ไปใช้โฮสต์ WebView2 ที่ปรับแต่งให้มีประสิทธิภาพมากกว่าแล้วก็ตาม Outlook รุ่นใหม่สำหรับ Windows ก็พึ่งพาเทคโนโลยีเว็บอย่างมากเช่นกัน และ Microsoft อธิบายอย่างชัดเจนว่าสถาปัตยกรรมนั้นเป็นวิธีเพิ่มความคล่องตัว ส่งมอบฟีเจอร์ได้เร็วขึ้น และสร้างประสบการณ์ที่สอดคล้องกันมากขึ้น
Teams ให้บทเรียนที่น่าสนใจเป็นพิเศษ Microsoft ต้องการเพิ่มประสิทธิภาพและลดการใช้ทรัพยากร จึงเปลี่ยนสถาปัตยกรรม แต่ไม่ได้เขียน UI ใหม่ให้เป็นแอปพลิเคชันเนทีฟของ Windows แบบดั้งเดิม
บริษัทคงชุดเทคโนโลยีเว็บไว้ แล้วปรับปรุงประสิทธิภาพรอบ ๆ มัน
ความแตกต่างนี้สำคัญ Microsoft ตัดสินใจว่าข้อได้เปรียบด้านองค์กรของ React, TypeScript และ Chromium มีคุณค่าควรเก็บรักษาไว้ แม้จะพยายามเพิ่มประสิทธิภาพอย่างจริงจังไปพร้อมกัน
ยังมีบทเรียนอีกอย่างหนึ่ง Microsoft เองได้เปิดตัวเทคโนโลยีแอปพลิเคชัน Windows มาหลายรุ่นตลอดหลายปี ทั้ง Win32, WPF, UWP, WinUI และอื่น ๆ บริษัทที่เลือก “เนทีฟ Windows” ไม่ได้กำลังเลือกแพลตฟอร์มที่อยู่เหนือกาลเวลาเสมอไป บ่อยครั้งบริษัทกำลังเดิมพันกับเฟรมเวิร์กรุ่นหนึ่งที่ Microsoft สนับสนุนเป็นหลักในเวลานั้น
ชวนให้รู้สึกย้อนแย้งอยู่บ้างที่แพลตฟอร์มเว็บกลับกลายเป็นหนึ่งในแพลตฟอร์มเป้าหมายสำหรับแอปพลิเคชันที่มีเสถียรภาพมากกว่าแพลตฟอร์มอื่น ๆ
การจ้างคนเป็นส่วนหนึ่งของสถาปัตยกรรม
การเลือกเฟรมเวิร์กยังกำหนดด้วยว่าคุณจะจ้างใครได้บ้าง
นักพัฒนา JavaScript และ TypeScript เป็นหนึ่งในกลุ่มบุคลากรวิศวกรรมที่ใหญ่ที่สุดในอุตสาหกรรม บริษัทที่สร้างผลิตภัณฑ์ด้วย Electron สามารถสรรหาคนจากกลุ่มนี้ได้ แทนที่จะต้องมีทีมผู้เชี่ยวชาญ macOS, Windows และ Linux ที่มีประสบการณ์แยกกัน
ผู้เชี่ยวชาญเนทีฟยังคงมีคุณค่า ผลิตภัณฑ์เดสก์ท็อปที่จริงจังยังต้องการวิศวกรที่เข้าใจระบบปฏิบัติการอย่างลึกซึ้ง แต่ Electron เปลี่ยนจำนวนผู้เชี่ยวชาญที่คุณจำเป็นต้องมี
แทนที่จะต้องให้ผู้เชี่ยวชาญแพลตฟอร์มสร้างส่วนใหญ่ของแอปพลิเคชัน คุณสามารถเก็บโค้ดเนทีฟสำหรับเชื่อมต่อกับระบบไว้ในสัดส่วนที่ค่อนข้างเล็ก แล้วให้คนส่วนใหญ่ในทีมทำงานกับผลิตภัณฑ์ส่วนที่ใช้ร่วมกัน
เรื่องนี้สำคัญยิ่งขึ้นเมื่อบริษัทมีเว็บแอปพลิเคชันอยู่แล้ว บางครั้งคอมโพเนนต์ React สามารถใช้ร่วมกันได้ ไลบรารี TypeScript สามารถนำกลับมาใช้ใหม่ได้ ตรรกะของผลิตภัณฑ์สามารถย้ายระหว่างเว็บกับเดสก์ท็อปได้ วิศวกรสามารถย้ายทีมโดยไม่ต้องเรียนรู้ระบบนิเวศที่ต่างกันอย่างสิ้นเชิง
การจ้างคนยังมีความเสี่ยงน้อยลงด้วย หากวิศวกรเพียงคนเดียวที่เข้าใจไคลเอนต์ Windows แบบเนทีฟของคุณอย่างลึกซึ้งลาออก การหาคนมาแทนความเชี่ยวชาญนั้นอาจเป็นเรื่องยาก แต่เมื่อใช้ Electron โค้ดส่วนใหญ่ใช้เทคโนโลยีที่คนอื่น ๆ ในองค์กรคุ้นเคย
ดังนั้น เฟรมเวิร์กจึงไม่ได้กำหนดเพียงวิธีแสดงผลส่วนติดต่อผู้ใช้ แต่ยังส่งผลต่อวิธีจัดโครงสร้างองค์กรวิศวกรรมด้วย
เนทีฟไม่ได้หมายถึงซอฟต์แวร์ที่ดีกว่าโดยอัตโนมัติ
นักพัฒนามักใช้คำว่า “เนทีฟ” ราวกับเป็นคำพ้องของคำว่า “เร็ว”
แต่มันไม่ใช่
API แบบเนทีฟเปิดโอกาสให้นักพัฒนาสร้างแอปพลิเคชันที่มีประสิทธิภาพสูงมากได้ แต่ผลิตภัณฑ์สุดท้ายจะทำได้จริงหรือไม่ ขึ้นอยู่กับสถาปัตยกรรม ทีม งบประมาณ และปริมาณงานปรับปรุงประสิทธิภาพที่บริษัทสามารถลงทุนได้
แอปพลิเคชันเนทีฟก็ยังช้า มีบั๊ก กินหน่วยความจำ ไม่สอดคล้องกัน หรือขาดการดูแลที่ดีได้
ที่สำคัญกว่านั้น การแบ่งทีมที่มีขนาดจำกัดไปพัฒนาเวอร์ชันเนทีฟหลายชุด หมายความว่าแต่ละชุดจะได้รับเวลาทำงานจากวิศวกรน้อยลง
ลองนึกภาพบริษัทที่มีวิศวกรหกคนสำหรับผลิตภัณฑ์เดสก์ท็อป ทางเลือกหนึ่งคือแบ่งพวกเขาไปทำ Mac และ Windows โดยอาจไม่รองรับ Linux อีกทางเลือกคือให้วิศวกรเกือบทั้งหกคนทำแอปพลิเคชัน Electron ร่วมกันตัวเดียวที่รองรับทั้งสามแพลตฟอร์ม
แนวทางใดทำให้บริษัทมีกำลังวิศวกรรมมากกว่าในการลดเวลาเริ่มต้น แก้ปัญหาหน่วยความจำรั่ว ขัดเกลาการโต้ตอบ ปรับปรุงการเข้าถึงสำหรับผู้พิการ ลดการล่ม และตอบสนองต่อผู้ใช้?
ไม่ใช่เรื่องชัดเจนเลยว่าแอปพลิเคชันเนทีฟจะให้ผลิตภัณฑ์ที่ดีกว่า
สิ่งนี้ก่อให้เกิดความย้อนแย้งที่น่าสนใจ: เฟรมเวิร์กที่ใช้ทรัพยากรเครื่องมากกว่าเล็กน้อย อาจทำให้บริษัทสร้างผลิตภัณฑ์ที่ปรับแต่งประสิทธิภาพได้ดีกว่า เพราะมันใช้ทรัพยากรด้านวิศวกรรมน้อยกว่ามาก
Electron ให้แพลตฟอร์มที่คุณควบคุมได้
Electron ยังมีข้อได้เปรียบอีกอย่างที่มองข้ามได้ง่าย นั่นคือมาพร้อมกับรันไทม์ Chromium เวอร์ชันที่ใช้สร้างและทดสอบแอปพลิเคชันนั้น
สิ่งนี้ตัดตัวแปรสำคัญตัวหนึ่งออกจากการพัฒนาข้ามแพลตฟอร์ม
เฟรมเวิร์กที่ใช้เว็บวิวของระบบปฏิบัติการสามารถทำให้แอปพลิเคชันมีขนาดเล็กลงได้ แต่สิ่งที่ต้องแลกคือฟรอนต์เอนด์เดียวกันอาจทำงานบน WebView2 ใน Windows, WKWebView ใน macOS และ WebKitGTK ใน Linux เอนจินเหล่านั้นมีความสามารถ บั๊ก กำหนดการออกรุ่น และพฤติกรรมการแสดงผลที่แตกต่างกัน
Electron เลือกแลกอีกแบบหนึ่ง คือบรรจุรันไทม์มาด้วยและทำให้เป็นส่วนหนึ่งของแอปพลิเคชัน
ใช่ นั่นต้องใช้พื้นที่ดิสก์
แต่ทำให้นักพัฒนามีแพลตฟอร์มเป้าหมายที่สอดคล้องกันมากขึ้นบนระบบปฏิบัติการสามตัวที่แตกต่างกันมาก
ความสอดคล้องมีคุณค่ามหาศาลในงานวิศวกรรม
เมื่อ Electron ไม่เพียงพอ คุณก็ยังใช้เนทีฟได้
การเลือก Electron ไม่ได้หมายความว่าต้องสละการเข้าถึงความสามารถแบบเนทีฟ
แอปพลิเคชัน Electron สามารถใช้โมดูลเนทีฟและโค้ดเฉพาะแพลตฟอร์มเมื่อจำเป็นได้ นั่นหมายความว่าทางเลือกด้านสถาปัตยกรรมไม่ได้เป็นเพียง:
เนทีฟ 100% หรือ JavaScript 100%
สำหรับผลิตภัณฑ์จำนวนมาก โมเดลที่ดีกว่าคือ:
ใช้ส่วนใหญ่ของแอปพลิเคชันร่วมกัน และมีโค้ดเนทีฟเพียงเล็กน้อยในจุดที่ระบบปฏิบัติการต้องการจริง ๆ
โค้ดเนทีฟกลายเป็นทางออกสำรอง แทนที่จะเป็นรากฐานของผลิตภัณฑ์ทั้งหมด
สำหรับหลายบริษัท นี่คือการจัดสรรแรงงานวิศวกรรมที่ดีกว่ามาก
ผู้ใช้สนใจผลิตภัณฑ์ ไม่ใช่เฟรมเวิร์ก
มีผู้ใช้ที่เชี่ยวชาญเทคนิคกลุ่มเล็ก ๆ ซึ่งเปิด Activity Monitor เห็นโพรเซส Chromium หลายตัว แล้วบ่นทันทีว่าแอปพลิเคชันนั้นใช้ Electron
ผู้ใช้ส่วนใหญ่ไม่ได้ทำเช่นนั้น
พวกเขาไม่สนใจว่า Slack ใช้ Electron ไม่สนใจว่า VS Code สร้างด้วยเทคโนโลยีเว็บ ไม่รู้ว่า Claude ใช้เฟรมเวิร์กอะไร พวกเขาสนใจว่าซอฟต์แวร์ช่วยให้ทำงานสำเร็จได้หรือไม่
หากแอปพลิเคชันเปิดได้เร็วพอ ตอบสนองดี แทบไม่ล่ม และแก้ปัญหาของผู้ใช้ได้ เทคโนโลยีที่ใช้พัฒนาก็แทบจะมองไม่เห็น
ในทางกลับกันก็จริงเช่นกัน แอปพลิเคชันเนทีฟไม่ได้กลายเป็นผลิตภัณฑ์ที่ดีโดยอัตโนมัติเพียงเพราะใช้ Swift หรือ WinUI
ซอฟต์แวร์แข่งขันกันในระดับผลิตภัณฑ์ ไม่ใช่ระดับเฟรมเวิร์ก
เพิ่มประสิทธิภาพให้บริษัท ไม่ใช่แค่ไฟล์ไบนารี
Electron มีต้นทุนจริง มันใช้พื้นที่ดิสก์มากกว่า การใช้หน่วยความจำพื้นฐานก็มักสูงกว่าแอปพลิเคชันเนทีฟขนาดเล็ก และมีผลิตภัณฑ์ที่ต้นทุนเหล่านี้ทำให้ Electron เป็นตัวเลือกที่ไม่เหมาะสมอย่างแน่นอน
เครื่องมือเล็ก ๆ บนแถบเมนูอาจไม่จำเป็นต้องใช้ Chromium ไดรเวอร์อุปกรณ์ย่อมไม่ต้องใช้แน่นอน เกม ซอฟต์แวร์เสียงระดับมืออาชีพ และแอปพลิเคชันที่ไวต่อความหน่วงอย่างยิ่งมีข้อกำหนดแตกต่างกัน และหากผลิตภัณฑ์ของคุณจะทำงานบนระบบปฏิบัติการเดียวตลอดไป การพัฒนาแบบเนทีฟก็มีเหตุผลรองรับได้ง่ายขึ้นมาก
แต่ซอฟต์แวร์เดสก์ท็อปสมัยใหม่จำนวนมหาศาลไม่ได้อยู่ในหมวดเหล่านั้น
มันประกอบด้วยส่วนติดต่อผู้ใช้ที่ซับซ้อนซึ่งเชื่อมต่อกับบริการคลาวด์ ต้องทำงานบน Windows และ macOS และผู้ใช้ก็คาดหวังการรองรับ Linux มากขึ้นเรื่อย ๆ ต้องพัฒนาอย่างต่อเนื่อง แข่งขันกับผลิตภัณฑ์ที่ส่งมอบการเปลี่ยนแปลงทุกสัปดาห์ และมักสร้างโดยบริษัทที่มีวิศวกรจำนวนจำกัด
สำหรับผลิตภัณฑ์เหล่านั้น ประสิทธิภาพการทำงานของนักพัฒนาเป็นส่วนหนึ่งของประสิทธิภาพแอปพลิเคชัน
Electron ช่วยให้บริษัทจ้างคนจากกลุ่มบุคลากรที่ใหญ่กว่ามาก ใช้วิศวกรร่วมกันระหว่างเว็บกับเดสก์ท็อป ดูแลแอปพลิเคชันหลักเพียงตัวเดียวแทนที่จะเป็นหลายตัว ใช้ประโยชน์จากระบบนิเวศ JavaScript ส่งมอบฟีเจอร์บนระบบปฏิบัติการต่าง ๆ ได้สอดคล้องกันมากขึ้น รองรับ Linux ด้วยต้นทุนที่หากใช้แนวทางอื่นก็มักยากจะหาเหตุผลรองรับ และใช้เวลาวิศวกรรมกับการปรับปรุงผลิตภัณฑ์มากขึ้น แทนที่จะดูแลโค้ดหลายชุดที่ทำสิ่งเดียวกัน
คุณวัดต้นทุนของ Electron เป็นเมกะไบต์ได้ง่าย ๆ
ต้นทุนของทางเลือกอื่นมองเห็นได้ยากกว่า มันปรากฏในรูปของวิศวกรที่ต้องเพิ่มขึ้น โค้ดที่ต้องพัฒนาซ้ำ วงจรการออกรุ่นที่ยาวขึ้น บั๊กเฉพาะแพลตฟอร์ม ความยากในการจ้างงาน ทีมที่ทำงานแยกส่วน ผู้ใช้ Linux ที่ไม่ได้รับการรองรับ และฟีเจอร์ที่ใช้เวลาเพิ่มอีกหลายเดือนกว่าจะถึงมือทุกคน
ต้นทุนเหล่านั้นไม่ปรากฏใน Activity Monitor
แต่สำหรับบริษัทที่สร้างซอฟต์แวร์ มันอาจสูงกว่ามาก
เป้าหมายของการพัฒนาซอฟต์แวร์ไม่ใช่การสร้างไฟล์ไบนารีที่เล็กที่สุด
แต่คือการสร้างผลิตภัณฑ์ที่ดีที่สุดที่องค์กรของคุณสามารถส่งมอบ ดูแลรักษา และปรับปรุงได้อย่างต่อเนื่อง
สำหรับแอปพลิเคชันเดสก์ท็อปในกลุ่มที่มีขนาดใหญ่กว่าที่หลายคนคาด Electron ยังคงเป็นหนึ่งในวิธีที่มีประสิทธิภาพที่สุดในการทำเช่นนั้น