แมวป่าลิงซ์หูมีพู่ต้นฉบับกำลังต่อสะพานสามช่วงระหว่างหน้าต่างส่วนติดต่อ host และพื้นผิว native
lynxjslynxtrondesktoparchitecturecross-platform

Lynxtron: แบ่งขอบเขต UI, host และ native extension ให้ชัด

พี่โชว์Engineering

เวลาเลือกเทคโนโลยี desktop ทีมมักถูกบังคับให้เลือกระหว่างเขียนเร็วด้วย web stack กับลงทุน native เพื่อขนาดและการเชื่อมระบบที่ลึกกว่า Lynxtron เสนอทางกลาง: ใช้ Lynx renderer ทำ UI, ให้ host process ครอบครองความสามารถของเครื่อง และต่อ native extension เฉพาะจุดที่จำเป็นครับ

WHY: น้ำหนัก runtime ไม่ใช่คำถามเดียว

คำว่า “Electron-like” ในประกาศหมายถึงโมเดลการแบ่ง process และ bridge ไม่ได้แปลว่า API หรือ compatibility เหมือน Electron Lynxtron ไม่ bundle browser เป็น UI runtime จึงมีโอกาสลดขนาดและเวลาเปิดหน้าต่าง แต่สิ่งที่ทีมควรถามก่อนคือขอบเขตสิทธิ์: code ชั้นไหนอ่านไฟล์ เปิด network หรือแตะอุปกรณ์ได้

ให้นึกถึงร้านอาหารสามห้อง ห้องหน้ารับออร์เดอร์คือ Lynx UI ครัวกลางที่ถือกุญแจคลังคือ host process ส่วนเตาเฉพาะทางคือ native extension ถ้าย้ายกุญแจทุกดอกไปไว้หน้าร้าน แม้ร้านเบาและเร็วขึ้นก็แลกด้วยพื้นที่โจมตีที่กว้างขึ้น

HOW: วางสัญญาระหว่างสามชั้น

ชั้น UI ควรรู้เฉพาะข้อมูลที่ต้องแสดงและคำสั่งระดับ domain เช่น “บันทึกโน้ต” ไม่ควรรับ primitive อย่าง “รันคำสั่ง shell นี้” ชั้น host validate schema, path และสิทธิ์ก่อนแปลงคำสั่งเป็นการทำงานของ OS ส่วน native extension รับงานที่ renderer ทำไม่เหมาะ เช่น camera preview, texture, map หรือ hardware integration และเปิด surface ให้น้อยที่สุด

ประกาศทางการทดสอบตัวอย่างกับ Lynxtron Go 0.1.18, runtime 0.0.28, macOS ทั้ง Apple silicon/Intel และ Windows x64 โดยต้องใช้ Node ^22.18.0 || ^24 || ^26 บางตัวอย่างไป Web ได้ผ่าน platform adapter นี่คือกรอบทดลอง ไม่ใช่คำรับรองว่า package, startup หรือ memory จะดีกว่าทุก Electron app เพราะ workload, native module และวิธีวัดต่างกัน

เช็กลิสต์ก่อนทำ prototype

เลือกหนึ่ง flow ที่มีทั้ง UI และ system capability เช่นเปิดไฟล์ใน workspace แล้ววัด cold start, memory หนึ่ง/สองหน้าต่าง, package size และ latency ของ bridge เก็บ baseline จากเทคโนโลยีเดิมด้วยเครื่องเดียวกัน จากนั้น threat-model ข้อมูลข้าม bridge: ใครสร้าง input, validate ที่ไหน, error รั่ว path หรือไม่ และ native extension crash แล้ว recovery อย่างไร

ยังไม่ควรย้ายทั้งผลิตภัณฑ์ถ้า accessibility, auto-update, signing, crash reporting หรือ ecosystem module ที่ต้องใช้ยังไม่มีหลักฐานพอ Prototype ที่ดีตอบคำถามเหล่านี้ด้วยข้อมูล ไม่ใช่แค่หน้าต่างแรกเปิดได้

Recap

  • ให้ UI ขอ action ระดับ domain ไม่ส่ง shell primitive
  • รวม filesystem/network/device permission ไว้ที่ host
  • เปิด native surface เท่าที่ use case ต้องใช้
  • benchmark เทียบ baseline บนเครื่องและ build mode เดียวกัน
  • ตรวจ packaging, signing, update และ accessibility ก่อนเลือก production