เหตุผลที่ Gumroad ไม่เลือก Htmx

 (htmx.org)
6 คะแนน โดย GN⁺ 2024-10-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Gumroad พิจารณาใช้ htmx ตอนเริ่มโปรเจ็กต์ใหม่ชื่อ Helper
  • เดิมตั้งใจจะใช้ htmx เพื่อหลีกเลี่ยงความซับซ้อนของ React แต่ภายในทีมมีความเห็นแตกต่างกัน
  • ในช่วงแรก htmx ดูมีอนาคตสำหรับการเพิ่มปฏิสัมพันธ์แบบง่าย ๆ

ข้อจำกัดของ htmx

  • ความเป็นธรรมชาติและประสบการณ์นักพัฒนา: การทำงานกับ htmx ไม่ได้ให้ความรู้สึกตรงไปตรงมามากกว่า Next.js การทำฟอร์มที่ซับซ้อนและการตรวจสอบแบบไดนามิกทำให้ลอจิกฝั่งเซิร์ฟเวอร์ซับซ้อนขึ้น
  • ข้อจำกัดด้าน UX: htmx โดยพื้นฐานใช้แนวทางแบบ Rails/CRUD ทำให้ประสบการณ์ผู้ใช้ค่อนข้างจำเจ การทำอินเทอร์เฟซแบบลากแล้ววางทำได้ยากกว่า React
  • การรองรับ AI และเครื่องมือ: Next.js ทำงานร่วมกับเครื่องมือ AI ได้คุ้นเคยกว่า แต่ htmx ไม่เป็นเช่นนั้น ซึ่งส่งผลต่อความเร็วในการพัฒนาและการแก้ปัญหา
  • ปัญหาด้านการขยายตัว: เมื่อโปรเจ็กต์ซับซ้อนขึ้น htmx ก็เริ่มตามความต้องการไม่ทัน เมื่อต้องเพิ่มฟีเจอร์อย่างการทำงานร่วมกันแบบเรียลไทม์และการแสดงข้อมูลเชิงภาพที่ซับซ้อน การจัดการ state กลายเป็นเรื่องยาก
  • ชุมชนและระบบนิเวศ: ระบบนิเวศของ React/Next.js เติบโตเต็มที่และมีโซลูชันที่หลากหลาย ขณะที่ htmx ยังไม่เป็นเช่นนั้น

การตัดสินใจสุดท้าย: เปลี่ยนไปใช้ React/Next.js

  • React/Next.js เหมาะกับการสร้าง UX ที่ซับซ้อนมากกว่า
  • ทีมได้ใช้ข้อได้เปรียบของ React ในเรื่องฟังก์ชันลากแล้ววาง การจัดการ state ที่ซับซ้อน การสร้างฟอร์มแบบไดนามิก การทำงานร่วมกันแบบเรียลไทม์ และการปรับแต่งประสิทธิภาพ
  • ทีมจึงย้ายไปใช้ React เพื่อก้าวข้ามข้อจำกัดของ htmx และรองรับวิสัยทัศน์ระยะยาวของโปรเจ็กต์
  • พวกเขาพอใจกับการตัดสินใจนี้ และในตอนนี้สามารถเดินหน้าได้เร็วขึ้น สร้างประสบการณ์ผู้ใช้ที่น่าสนใจขึ้น และใช้ประโยชน์จากเครื่องมือและไลบรารีที่มีอยู่ได้

บทเรียนที่ได้จากประสบการณ์

  • การพิจารณาทางเลือกที่เบากว่ายังคงสำคัญ แต่การเลือกเทคโนโลยีที่เติบโตไปพร้อมกับโปรเจ็กต์และรองรับวิสัยทัศน์ระยะยาวก็สำคัญไม่แพ้กัน
  • สำหรับ Helper นั้น React และ Next.js ได้พิสูจน์แล้วว่าเป็นตัวเลือกแบบนั้น และหลังจากย้ายมาใช้แล้วก็สามารถยกระดับ UX ของแอปสำหรับลูกค้าหลักได้อย่างมาก

สรุปของ GN⁺

  • ประสบการณ์ของ Gumroad แสดงให้เห็นว่า แม้การพิจารณาทางเลือกที่เบากว่าจะเป็นเรื่องสำคัญ แต่การเลือกเทคโนโลยีที่รองรับการเติบโตของโปรเจ็กต์และวิสัยทัศน์ระยะยาวนั้นสำคัญยิ่งกว่า
  • htmx อาจเหมาะกับโมเดลปฏิสัมพันธ์ที่เรียบง่าย หรือแอปพลิเคชันที่เรนเดอร์ฝั่งเซิร์ฟเวอร์อยู่แล้ว
  • สำหรับอินเทอร์เฟซที่ขับเคลื่อนด้วย state และมีความซับซ้อนของ Helper นั้น React และ Next.js เป็นตัวเลือกที่ดีกว่า
  • สแตกเทคโนโลยีสามารถนำกลับมาประเมินใหม่ได้ตามความต้องการ และการรักษาความยืดหยุ่นไว้เมื่อมีเทคโนโลยีใหม่เกิดขึ้นเป็นสิ่งสำคัญ

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-04
ความเห็นจาก Hacker News

  • CEO ของ Gumroad ได้แบ่งปันประสบการณ์จากการลองใช้ htmx แล้วเปลี่ยนไปใช้ NextJS ซึ่งเป็นข้อมูลที่มีประโยชน์สำหรับคนที่กำลังมองหาประสบการณ์ด้านลบของ htmx

    • เครื่องมือ AI คุ้นเคยกับ Next.js แต่ไม่คุ้นกับ htmx ซึ่งชี้ให้เห็นแนวโน้มสำคัญเกี่ยวกับอนาคตของเครื่องมือพัฒนา
    • มีการคาดการณ์ว่า LLMs จะยิ่งเสริมโครงสร้างแบบผู้ชนะกินรวบที่มีอยู่เดิม และกระตุ้นให้เกิดการใช้เครื่องมือโอเพนซอร์สมากขึ้น

  • ตอนสร้างฟอร์มที่ซับซ้อน ลอจิกฝั่งเซิร์ฟเวอร์กลับซับซ้อนมากขึ้นและยากกว่างานฝั่งไคลเอนต์ใน React

    • มีมีมที่เน้นย้ำว่าต้องทำ validation ฝั่งเซิร์ฟเวอร์ด้วยเช่นกัน

  • พยายามทำให้ฟรอนต์เอนด์เบาด้วย htmx แต่สุดท้ายก็ต้องใช้ไลบรารีภายนอกเพื่อรองรับ UI/UX ที่ซับซ้อนและการจัดการสถานะ

    • มีความเห็นว่าสาเหตุที่ทำงานใน React ได้ง่ายกว่า ก็เพราะมีการใช้ไลบรารีภายนอกนั่นเอง
    • มีความเห็นว่าถ้าต้องจัดการสถานะและการเรนเดอร์ที่ซับซ้อน htmx ก็คงไม่ใช่ตัวเลือกที่ดีตั้งแต่แรก

  • การทำอินเทอร์เฟซแบบ drag and drop ด้วย htmx เป็นเรื่องยาก และใช้ไลบรารี React แล้วได้ประสบการณ์ที่ลื่นไหลกว่า

    • htmx เหมาะกับการใช้ฟรอนต์เอนด์บันเดิลเท่าที่จำเป็น
    • สามารถใช้เหตุการณ์ htmx.onLoad เพื่อค้นหา markup ที่มีแอตทริบิวต์ในคอนเทนต์ที่โหลดแล้วและเชื่อมต่อเข้าด้วยกันได้

  • ดูเหมือนว่าทีมจะคุ้นเคยกับการพัฒนาฟรอนต์เอนด์มากกว่า และมีปัญหาในการสื่อสารกับแบ็กเอนด์

    • ยอมรับข้อดีของ React component รวมถึงความง่ายในการหาเอกสารและความช่วยเหลือ

  • มีความเห็นว่ากระบวนการพัฒนาด้วย Next.js ให้ความรู้สึกเป็นธรรมชาติมากกว่า

    • แต่ก็มีความเห็นเช่นกันว่าไวยากรณ์ของ ReactJS ไม่เป็นธรรมชาติ

  • มีความเห็นว่าน่าสนใจที่ HTMX แบ่งปันประสบการณ์แบบนี้ และมีบางโปรเจกต์ที่ใช้แค่ HTMX อย่างเดียวอาจไม่เพียงพอ

    • เน้นย้ำอีกครั้งว่าจำเป็นต้องมีการตรวจสอบความถูกต้องของฟอร์มที่ฝั่งแบ็กเอนด์
    • กรณีของทีมที่พึ่งพาเครื่องมือ AI อย่างมากเป็นสิ่งที่น่าสนใจ
    • มีความเห็นว่าจำเป็นต้องมีปลั๊กอินเพื่อชดเชยข้อจำกัดของ HTMX

  • มีคำชื่นชมที่ HTMX.org โฮสต์บทความลักษณะนี้ไว้

  • มีความกังวลว่าเครื่องมือ AI อาจทำให้การยอมรับเฟรมเวิร์กหรือภาษาโปรแกรมใหม่ ๆ ทำได้ยากขึ้น

    • มีการจินตนาการว่าอาจส่งผลต่อเครื่องมือพัฒนาในลักษณะคล้ายกับ SEO