นักพัฒนาคนหนึ่งได้แบ่งปันเส้นทางการเดินทางจากการใช้ HTMX ไปสู่การสร้างเฟรมเวิร์กของตนเองที่เรียกว่า MESH (Modular Element SSR with Hydration) ซึ่งเน้นให้เห็นถึงการถกเถียงที่ยังคงดำเนินต่อไปเกี่ยวกับแนวทางที่ดีที่สุดในการพัฒนาเว็บสมัยใหม่ เรื่องราวนี้เผยให้เห็นทั้งความหวังและข้อจำกัดของโซลูชัน HTML-over-the-wire เมื่อสร้างแอปพลิเคชันเชิงโต้ตอบที่ซับซ้อน
 |
|---|
| นักพัฒนาที่กำลังไตร่ตรองเกี่ยวกับวิวัฒนาการของเทคโนโลยีเว็บ ครุ่นคิดถึงความสมดุลระหว่างความเรียบง่ายและความซับซ้อนในแอปพลิเคชันสมัยใหม่ |
ปัญหาโครงสร้างของ HTMX นำไปสู่โซลูชันใหม่
นักพัฒนาคนนี้เริ่มต้นด้วยความชื่นชอบปรัชญาของ HTMX ที่ทำสิ่งต่างๆ ได้มากขึ้นด้วย HTML attributes แทนที่จะใช้ JavaScript แต่เร็วๆ นี้ก็ระบุสิ่งที่พวกเขามองว่าเป็นข้อบกพร่องที่สำคัญ พวกเขาอธิบาย HTMX ว่าเป็น declarative jQuery และกังวลเกี่ยวกับความซับซ้อนของโค้ดที่หลีกเลี่ยงไม่ได้ซึ่งจะเกิดขึ้นหากไม่มีโครงสร้างที่บังคับใช้ ความกังวลนี้ผลักดันให้พวกเขาทดลองกับแนวทางของตนเองที่จะรักษาประโยชน์ของ HTMX ไว้ในขณะที่เพิ่มระเบียบวินัยในการจัดระเบียบที่พวกเขารู้สึกว่าหายไป
MESH ทำงานตามหลักการง่ายๆ คือ หนึ่งคอมโพเนนต์เท่ากับหนึ่ง endpoint การออกแบบนี้ช่วยให้นักพัฒนาสามารถเขียนโค้ด backend ที่เน้น HTML เป็นหลักซึ่งให้ความรู้สึกคล้ายกับการสร้าง Single Page Application (SPA) แต่มีประโยชน์จาก server-side rendering เฟรมเวิร์กใช้ Declarative Shadow DOM และ custom elements เพื่อสร้างคอมโพเนนต์แบบโมดูลาร์ที่สามารถอัปเดตแยกกันได้
หมายเหตุ: Server-side rendering (SSR) หมายความว่าหน้าเว็บถูกสร้างขึ้นบนเซิร์ฟเวอร์ก่อนที่จะส่งไปยังเบราว์เซอร์ แทนที่จะถูกประกอบขึ้นโดย JavaScript ในเบราว์เซอร์
คุณสมบัติหลักของ MESH Framework:
- สถาปัตยกรรมแบบหนึ่งคอมโพเนนต์เท่ากับหนึ่ง endpoint
- การเรนเดอร์ฝั่งเซิร์ฟเวอร์พร้อมการ hydration ฝั่งไคลเอนต์
- ใช้ Declarative Shadow DOM สำหรับการห่อหุ้มคอมโพเนนต์
- การอัปเดตแบบ out-of-band ผ่าน Server-Sent Events ( SSE )
- สร้างด้วย Go และ Templ templating
ชุมชนแบ่งแยกเรื่องความซับซ้อนของเฟรมเวิร์ก
การตอบสนองของชุมชนนักพัฒนาเผยให้เห็นการแบ่งแยกพื้นฐานในปรัชญาการพัฒนาเว็บ นักพัฒนาบางคนชื่นชมความยืดหยุ่นของ HTMX และโต้แย้งว่าการเพิ่มโครงสร้างจะทำลายจุดประสงค์ของมัน คนอื่นๆ มีความผิดหวังคล้ายกันกับความสามารถในการขยายขนาดของ HTMX สำหรับแอปพลิเคชันที่ซับซ้อน สมาชิกชุมชนคนหนึ่งสังเกตว่า HTMX ทำงานได้ดีที่สุดสำหรับแอปพลิเคชันหลายหน้าแบบดั้งเดิม แต่ประสบปัญหากับฟีเจอร์เชิงโต้ตอบสูงเช่นฟังก์ชัน drag-and-drop
การอภิปรายยังเน้นให้เห็นแนวทางทางเลือกที่กำลังได้รับความนิยม นักพัฒนาหลายคนกล่าวถึง Phoenix LiveView และ Blazor เป็นโซลูชันที่เป็นผู้ใหญ่มากขึ้นสำหรับอินเทอร์เฟซที่ขับเคลื่อนโดยเซิร์ฟเวอร์ เฟรมเวิร์กเหล่านี้ให้ประโยชน์คล้ายกับ HTMX แต่มีโครงสร้างที่มีความเห็นชัดเจนมากกว่าซึ่งนักพัฒนาบางคนชอบสำหรับโปรเจ็กต์ขนาดใหญ่
เฟรมเวิร์กทางเลือกที่ได้รับการกล่าวถึง:
- Phoenix LiveView ( Elixir ) - อินเทอร์เฟซแบบเรียลไทม์ที่ขับเคลื่อนโดยเซิร์ฟเวอร์
- Blazor ( C ) - สามารถคอมไพล์เป็น WebAssembly หรือทำงานฝั่งเซิร์ฟเวอร์
- Datastar - แนวทาง SSE-first ที่สร้างโดยวิศวกร Go
- Leptos ( Rust ) - คอมไพล์เป็น WASM ด้วยประสิทธิภาพที่ดีกว่า Blazor
ความท้าทายทางเทคนิคขับเคลื่อนนวัตกรรม
การใช้งาน MESH เผชิญกับอุปสรรคทางเทคนิคที่สำคัญ โดยเฉพาะอย่างยิ่งกับความเข้ากันได้ของ Shadow DOM HTMX ไม่ทำงานตามธรรมชาติข้าม shadow root boundaries ทำให้นักพัฒนาต้องสร้าง JavaScript workarounds แบบกำหนดเอง ประสบการณ์นี้แสดงให้เห็นถึงความท้าทายที่กว้างขึ้นในการพัฒนาเว็บ คือ การสร้างสมดุลระหว่างความปรารถนาสำหรับเทคโนโลยีที่เรียบง่ายและมาตรฐานกับความต้องการฟีเจอร์เชิงโต้ตอบที่ซับซ้อน
HTMX ปล่อยให้นักพัฒนาเป็นผู้กำหนดระเบียบวินัยในโค้ดของตนเอง ไม่ว่าพวกเขาจะเห็นสมควรอย่างไรก็ตาม
ปรากฏการณ์ความเหนื่อยล้าจากเฟรมเวิร์กยังคงขับเคลื่อนการทดลอง ในขณะที่นักพัฒนาบางคนวิพากษ์วิจารณ์การสร้างเฟรมเวิร์กอีกตัวหนึ่ง คนอื่นๆ ชื่นชมการสำรวจแนวทางที่แตกต่างกันต่อปัญหาพื้นฐานเดียวกัน การอภิปรายเผยให้เห็นว่านักพัฒนาจำนวนมากกำลังมองหาโซลูชันที่รวมประโยชน์ของ server-side rendering เข้ากับการโต้ตอบฝั่งไคลเอ็นต์โดยไม่มีความซับซ้อนของเฟรมเวิร์ก JavaScript แบบดั้งเดิม
ข้อจำกัดของ HTMX ที่ระบุได้:
- ขาดโครงสร้างโค้ดที่บังคับใช้สำหรับแอปพลิเคชันที่ซับซ้อน
- ไม่สามารถข้ามขอบเขต Shadow DOM ได้หากไม่มีวิธีแก้ไขเพิ่มเติม
- พฤติกรรมการแลกเปลี่ยนแบบ innerHTML เริ่มต้นอาจไม่เหมาะสมกับทุกกรณีการใช้งาน
- ต้องการโซลูชันแบบกำหนดเองสำหรับการสื่อสารระหว่างคอมโพเนนต์
มองไปข้างหน้า
MESH เป็นตัวแทนของความพยายามของนักพัฒนาคนหนึ่งในการหาจุดกึ่งกลางระหว่างความเรียบง่ายของ HTMX และโครงสร้างที่จำเป็นสำหรับแอปพลิเคชันที่ซับซ้อน ว่าจะได้รับการยอมรับหรือไม่ยังคงต้องติดตามดู แต่โปรเจ็กต์นี้เน้นให้เห็นถึงวิวัฒนาการที่ยังคงดำเนินต่อไปในแนวทางการพัฒนาเว็บ การอภิปรายของชุมชนแสดงให้เห็นว่าเครื่องมือต่างๆ ทำงานได้ดีกว่าสำหรับกรณีการใช้งานที่แตกต่างกัน และการค้นหาโซลูชันการพัฒนาเว็บที่สมบูรณ์แบบยังคงขับเคลื่อนนวัตกรรมและการทดลอง
อ้างอิง: MESH: I tried HTMX, then ditched it