HTMX เผชิญกับความเป็นจริง: นักพัฒนาเปิดเผยความซับซ้อนที่ซ่อนอยู่เบื้องหลังเฟรมเวิร์ก "ง่าย" นี้

HTMX ถูกนำเสนอในฐานะยาแก้พิษสำหรับความซับซ้อนของ frontend สมัยใหม่ โดยสัญญาว่าจะนำความเรียบง่ายของ HTML ที่เรนเดอร์จากเซิร์ฟเวอร์กลับมา พร้อมเพิ่มการโต้ตอบที่เพียงพอเพื่อแข่งขันกับแอปพลิเคชันแบบหน้าเดียว อย่างไรก็ตาม นักพัฒนาจำนวนมากขึ้นเรื่อยๆ กำลังค้นพบว่าโซลูชันที่เรียบง่ายนี้มาพร้อมกับชุดความท้าทายของมันเองที่ไม่ชัดเจนในทันที

ความน่าสนใจของเฟรมเวิร์กนี้ชัดเจน: แทนที่จะจัดการ state ฝั่งไคลเอนต์ที่ซับซ้อนและ API endpoints นักพัฒนาสามารถสร้างเว็บแอปพลิเคชันแบบโต้ตอบได้โดยส่งส่วนของ HTML จากเซิร์ฟเวอร์ แนวทางนี้โดนใจนักพัฒนาฝั่งแบ็กเอนด์เป็นพิเศษ ที่ชอบทำงานกับเทมเพลตฝั่งเซิร์ฟเวอร์ที่คุ้นเคยมากกว่าการเรียนรู้ React หรือ Vue.js

การจัดการ State กลายเป็นฝันร้ายฝั่งเซิร์ฟเวอร์

หนึ่งในจุดขายที่ใหญ่ที่สุดของ HTMX คือการย้ายการจัดการ state ไปยังเซิร์ฟเวอร์ แต่กลับกลายเป็นปัญหาอย่างรวดเร็วในแอปพลิเคชันในโลกแห่งความเป็นจริง นักพัฒนาพบว่าตัวเองต้องสร้าง session objects ที่ซับซ้อนเพื่อเก็บข้อมูลฟอร์มชั่วคราว ความคืบหน้าของผู้ใช้ และ UI state ที่ปกติจะอยู่ในเบราว์เซอร์ การจัดการ state ฝั่งเซิร์ฟเวอร์นี้นำมาซึ่งความท้าทายใหม่เกี่ยวกับการใช้หน่วยความจำ การล้าง session และการจัดการหลายแท็บในเบราว์เซอร์

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

ความท้าทายทั่วไปในการใช้งาน HTMX

• Form Wizards: ต้องการการเก็บสถานะฝั่งเซิร์ฟเวอร์และการจัดการเซสชันที่ซับซ้อน
• การอัปเดตหลายองค์ประกอบ: ต้องใช้การอัปเดต Out-of-Band (OOB) หรือการสลับหน้าเว็บทั้งหมด
• การจัดการข้อผิดพลาด: รหัสสถานะ HTTP ขัดแย้งกับความคาดหวังของเฟรมเวิร์ก
• ประวัติเบราว์เซอร์: ต้องการการจัดการด้วยตนเองสำหรับการนำทางที่ซับซ้อน
• การนำองค์ประกอบกลับมาใช้ใหม่: ส่วนของเทมเพลตถูกแยกระหว่างการเรนเดอร์เริ่มต้นและ endpoint สำหรับการอัปเดต
• การทดสอบ: ตรรกะการเรนเดอร์ฝั่งเซิร์ฟเวอร์ทดสอบ unit test ได้ยากกว่าองค์ประกอบฝั่งไคลเอนต์
• การรับเข้าของทีม: ต้องการการฝึกอบรมใหม่สำหรับนักพัฒนาที่คุ้นเคยกับรูปแบบ SPA

ปัญหาความกำกวมของ HTTP Status Code

แอปพลิเคชัน HTMX มักจะละเมิดมาตรฐาน HTTP ในรูปแบบที่ทำให้นักพัฒนารู้สึกไม่สบายใจ ข้อผิดพลาดการตรวจสอบฟอร์มมักจะส่งคืน HTTP 200 status codes พร้อมข้อความแสดงข้อผิดพลาดใน response body แทนที่จะเป็น 400 Bad Request ที่ถูกต้องตามความหมาย สิ่งนี้เกิดขึ้นเพราะพฤติกรรมเริ่มต้นของ HTMX จะทิ้ง response bodies สำหรับ status codes ที่ไม่ใช่ 200 ทำให้นักพัฒนาต้องเลือกระหว่างความหมาย HTTP ที่เหมาะสมกับความสะดวกของเฟรมเวิร์ก

แม้ว่าจะมีวิธีแก้ไขปัญหา แต่ก็ต้องการการกำหนดค่าเพิ่มเติมและขัดกับคำสัญญาของ HTMX เรื่องความเรียบง่าย นักพัฒนาต้องยอมรับการละเมิดความหมายหรือเพิ่มความซับซ้อนเพื่อจัดการ HTTP status codes ที่เหมาะสม ซึ่งทำลายหนึ่งในข้อได้เปรียบหลักของเฟรมเวิร์ก

การเปรียบเทียบ HTMX กับ Frontend Frameworks แบบดั้งเดิม

ความแตกแยกระหว่างรุ่นในการพัฒนาเว็บ

การถกเถียงเรื่อง HTMX เผยให้เห็นการเปลี่ยนแปลงพื้นฐานในวิธีที่นักพัฒนาเข้าหาเว็บแอปพลิเคชัน นักพัฒนาปัจจุบันหลายคนเรียนรู้การพัฒนา frontend ในยุค React และคิดว่า APIs และการจัดการ state ฝั่งไคลเอนต์เป็นวิธีธรรมชาติในการสร้างเว็บแอปพลิเคชัน สำหรับพวกเขา แนวทางที่เน้นเซิร์ฟเวอร์ของ HTMX รู้สึกเหมือนก้าวถอยหลังมากกว่าก้าวไปข้างหน้า

มีนักพัฒนาทั้งรุ่นที่คิดว่า frontend = React และที่สำคัญกว่านั้นคือพวกเขามีจำนวนมากกว่าพวกเราที่ผ่าน DHTML และ Ajax มา

ความแตกแยกระหว่างรุ่นนี้ขยายไปไกลกว่านักพัฒนาไปถึงนักออกแบบและสมาชิกทีมอื่นๆ ที่ต้องปรับเวิร์กโฟลว์ของตัวเองเพื่อรองรับกระบวนทัศน์ที่แตกต่างของ HTMX เฟรมเวิร์กนี้ต้องการการยอมรับจากทีมทั้งหมด ไม่ใช่แค่นักพัฒนาแต่ละคน

เมื่อสิ่งง่ายๆ กลายเป็นซับซ้อน

แม้จะมีการตลาดว่าเป็นโซลูชันที่เรียบง่าย แต่ HTMX มักต้องการให้นักพัฒนาใช้วิธีแก้ไขปัญหาสำหรับรูปแบบ UI ทั่วไป ฟีเจอร์เช่นการไฮไลต์ขั้นตอนการนำทางที่ใช้งานอยู่ การรักษาตำแหน่งการเลื่อน หรือการอัปเดตองค์ประกอบหลายหน้าพร้อมกัน ต้องการการวางแผนอย่างระมัดระวังและบางครั้งรู้สึกซับซ้อนกว่าโซลูชันที่เทียบเท่าในเฟรมเวิร์ก frontend แบบดั้งเดิม

เฟรมเวิร์กนี้ทำงานได้ดีสำหรับการเพิ่มการโต้ตอบพื้นฐานให้กับหน้าที่เป็นแบบคงที่ แต่ดิ้นรนกับ user interfaces ที่ซับซ้อนมากขึ้น นักพัฒนามักพบว่าตัวเองตั้งคำถามว่าควรยึดติดกับ HTMX สำหรับฟีเจอร์ที่ซับซ้อนหรือเปลี่ยนไปใช้ JavaScript frameworks สำหรับคอมโพเนนต์เฉพาะ

คำถามเรื่องการบำรุงรักษา

การพิจารณาการบำรุงรักษาระยะยาวยังเป็นปัจจัยในการอภิปราย HTMX ในขณะที่เฟรมเวิร์กลด JavaScript dependencies ฝั่งไคลเอนต์ แต่มักจะเพิ่มความซับซ้อนฝั่งเซิร์ฟเวอร์และผูกตรรกะการนำเสนอ frontend เข้ากับระบบแบ็กเอนด์แน่นขึ้น สิ่งนี้อาจทำให้การเปลี่ยนแปลงในอนาคตยากขึ้นและลดความยืดหยุ่นที่มาจากการมีระบบ frontend และ backend แยกกัน

นักพัฒนาบางคนรายงานว่าหลังจากเลือก HTMX ในตอนแรกเพื่อหลีกเลี่ยงความซับซ้อนของเฟรมเวิร์ก frontend สมัยใหม่ ในที่สุดพวกเขากลับไปใช้ React หรือ Vue.js เพราะการแยกความกังวลและรูปแบบที่ยอมรับแล้วทำให้แอปพลิเคชันของพวกเขาง่ายต่อการบำรุงรักษาและขยายเมื่อเวลาผ่านไป

HTMX เป็นตัวเลือกที่น่าสนใจสำหรับภูมิทัศน์การพัฒนา frontend ปัจจุบัน แต่มันไม่ใช่โซลูชันสากลที่ผู้สนับสนุนบางครั้งอ้าง เช่นเดียวกับการเลือกเทคโนโลยีใดๆ มันเกี่ยวข้องกับการแลกเปลี่ยนที่นักพัฒนาต้องพิจารณาอย่างรอบคอบตามความต้องการเฉพาะ ความเชี่ยวชาญของทีม และเป้าหมายการบำรุงรักษาระยะยาว

อ้างอิง: HTMX is hard, so let's get it right (Part 1)