ความเหนื่อยล้าจากการจัดการ dependency: ทำไมถึงเลิกใช้ React แล้วเลือก Go+HTMX+Templ

• หลังจากทำโปรเจกต์ส่วนตัวในปีนี้ด้วย Go, HTMX และ Templ ก็ได้ตัดสินใจว่าจะเลิกใช้ React
  • ในเว็บไซต์ทางการของ HTMX มีเหตุผลที่น่าเชื่อถือหลายข้อว่าทำไมควรเลิกใช้ React แล้วหันมาเลือก HTMX แต่รู้สึกว่ายังมีคนพูดถึงความเหนื่อยล้าจากการจัดการ dependency ไม่มากนัก
• "ความเหนื่อยล้าจากการจัดการ dependency" คืออะไร?
  • ในโปรเจกต์ส่วนตัวล่าสุดที่ใช้ React (พจนานุกรมภาษาคาตาลันแบบโต้ตอบ) ได้ตระหนักว่าตัวเองใช้เวลามากเกินไปกับการอัปเดต dependency ของแพ็กเกจ React
  • เมื่ออัปเดตแพ็กเกจเป็นรีลีสล่าสุด ก็มักเกิดการเปลี่ยนแปลงสำคัญใน API ทำให้ต้องเสียเวลาไปกับการ refactor โค้ด
  • เนื่องจากเว็บแอปถูกนำขึ้นให้บริการสาธารณะบน EC2 instance จึงต้องการคงการอัปเดต dependency ไว้อย่างต่อเนื่อง
• รีลีส major เวอร์ชันใหม่จำเป็นจริงหรือ?
  • แพ็กเกจอย่าง wouter (แพ็กเกจ React router) และ TanStackQuery (ใช้สำหรับดึงข้อมูลจากแบ็กเอนด์, แคช และจัดการ state) ทำให้เว็บแอปเสียหายอย่างร้ายแรงจากการอัปเดต major version
  • ตอนที่แอปพังจากการอัปเดต major ครั้งแรก ก็ refactor โค้ดโดยไม่ได้ตั้งคำถามอะไร แต่เมื่อเกิดขึ้นเป็นครั้งที่สองก็เริ่มสงสัย
  • ตั้งคำถามว่าเว็บแอปได้ประโยชน์อะไรจริง ๆ จากรีลีส major version นอกเหนือจาก security patch
  • ตั้งคำถามว่าการทำให้ API ขององค์ประกอบหลักพังถึง 5 ครั้งนั้นจำเป็นหรือไม่
  • คิดว่ากำลังสูญเสียเวลาไปมากแค่ไหน ทั้งที่เวลานั้นอาจใช้ปล่อยฟีเจอร์ใหม่หรือเปิดตัวผลิตภัณฑ์อื่นได้
• ปัญหาเรื่องเวลาที่ไม่เพียงพอ
  • เพราะมีเวลาให้กับโปรเจกต์เขียนโค้ดส่วนตัวไม่มาก จึงไม่อยากเสียเวลาไปกับการ refactor โค้ดหลัง dependency ออก major version ใหม่
  • หากกำลังสร้างผลิตภัณฑ์ให้ลูกค้าและมีแผนจะคิดค่าบริการงานบำรุงรักษาในอนาคต การใช้ dependency ที่ไม่เสถียรจำนวนมากก็อาจไม่เป็นปัญหา
  • แต่ถ้าต้องการสร้างผลิตภัณฑ์ที่ต้องการการบำรุงรักษาน้อยที่สุด ก็จะอยู่ให้ห่างจาก ecosystem ของ JS
• การใช้ Go+HTMX+Templ
  • เหตุผลหลักที่ใช้ Go+HTMX+Templ ในโปรเจกต์ส่วนตัว คือมันช่วยให้โฟกัสกับการส่งมอบฟีเจอร์ได้ โดยไม่ต้องละเลยการอัปเดต dependency/security ตามปกติ
  • ตัวภาษา Go เองก็ยังคงรักษา standard library และ language spec ที่มีเสถียรภาพไว้ได้

[bbulbum]

ดูเหมือนว่า HTMX จะได้รับการประเมินในทางบวกค่อนข้างมาก
เลยคิดว่าหลายคนน่าจะมองหา HTMX ในฐานะทางเลือกเสริมสำหรับแอปพลิเคชันที่อิงกับ SSR
คงต้องลองใช้ในโปรเจกต์ข้างเคียงสักครั้งแล้วครับ

[savvykang]

ไลบรารีของ TanStack ซับซ้อนเกินความจำเป็น และในช่วงไม่กี่ปีมานี้คุณภาพของเอกสารก็ตกลงไปมาก เลยไม่ได้เลือกใช้ครับ อีกอย่างรอบการเปลี่ยนของแพ็กเกจ npm ก็สั้นเกินไป จนรู้สึกว่าเราจำเป็นต้องยึดติดกับเวอร์ชันล่าสุดอยู่ตลอดไหม

แต่ถ้าเป็นงานบริษัทก็คงเลิกใช้ React ไม่ได้ครับ ถ้าเป็นโปรเจกต์ส่วนตัวจะใช้อะไรก็คงไม่เป็นไร

[dohyun682]

ถ้าไม่อัปเดตแค่เมเจอร์เวอร์ชัน ก็น่าจะไม่ได้มีปัญหาเรื่องดีเพนเดนซีมากขนาดนั้นไม่ใช่เหรอ...?

[aer0700]

เมื่อไม่นานมานี้ผมเห็นงาน schedule job ภายในบริษัทตัวหนึ่งที่ยังรันด้วย Python 2 อยู่ แล้วรู้สึกอึดอัดจนหายใจไม่ออก
พอคิดดูแล้ว ตอนนี้มันก็ยังทำงานได้ดี เลยตัดสินใจปล่อยมันไว้ก่อน คงไม่สามารถฝืนไม่อัปเดตแบบนี้ไปได้ตลอดหรอกครับ

[aer0700]

ความเหนื่อยล้าจากการจัดการ dependency ปะทะความเบื่อหน่ายจากการสร้างล้อขึ้นมาใหม่
เป็นข้อถกเถียงเก่าแก่ครับ ถึงจะจริงที่ไม่ควรใช้ล้อที่ไม่จำเป็น แต่สิ่งที่ไม่จำเป็นวันนี้ จะยังไม่จำเป็นในวันพรุ่งนี้หรือเปล่าก็อีกเรื่อง...
ผมยังไม่เคยใช้ Go มาก่อน แต่ช่วงนี้เห็นเซิร์ฟเวอร์ที่สร้างด้วย Go เยอะเลย แม้จะยังไม่ได้ใช้ทันที แต่ก็น่าจะต้องลองจับดูสักครั้งครับ

[clickin]

ดูเหมือนว่า HTMX จะเป็นผู้นำของเทคโนโลยีสายฮิปก็เลยมีคนลองนำไปใช้กันเยอะ แต่ผมกลับคิดว่าถ้าไปในทางอย่าง go + vecty + gox น่าจะดีกว่า

[GN⁺]

ความคิดเห็นบน Hacker News

• แบ่งปันประสบการณ์การเลิกใช้ไลบรารีอย่าง React แล้วพัฒนาเว็บแอปด้วย Actix, Tera และ HTMX โดยสแตกนี้ดูแลรักษาได้ดีและได้รับความนิยมจากผู้ใช้

  • อธิบายประสบการณ์การพัฒนาเว็บแอปใหม่อย่างรวดเร็วแล้วปล่อยให้ผู้ใช้ทดสอบใช้งาน
  • การไม่มี "ความเหนื่อยล้าจากการจัดการ dependency" ทำให้เข้าใจเครื่องมือได้ลึกซึ้งขึ้น

• มองว่าไลบรารีของ Tanner มีฟีเจอร์มาก แต่การออกแบบ API ยังไม่ดีพอ

  • React Table และ React Query ทรงพลัง แต่ตั้งขอบเขตไว้ไม่เหมาะสมจึงก่อปัญหา
  • จุดแข็งของ React คือมันไม่ใช่เฟรมเวิร์ก และหยุดอยู่ที่ขอบเขตที่ออกแบบมาอย่างดี
  • พยายามเลือกใช้เฉพาะไลบรารีที่ตรงตามเกณฑ์นี้

• รู้สึกว่าตัวอย่างของ HTMX เพียงย้ายความซับซ้อนไปไว้อีกที่หนึ่ง และอธิบายว่า JSX เป็นวิธีที่สง่างามในการหลีกเลี่ยงการใช้เทมเพลต

  • ยังมีปัญหาอีกมากที่ต้องแก้ เช่น routing, state management, authentication เป็นต้น

• รู้สึกว่าการพูดว่าเลิกใช้ React เป็นเรื่องแปลก และโต้แย้งว่าปัญหาไม่ได้อยู่ที่ React แต่อยู่ที่ dependency อื่น ๆ

  • การเลือกเขียนแบ็กเอนด์ด้วย Go เป็นทางเลือกที่มีอยู่เสมอ

• เน้นว่าเมื่ออัปเดตไปยัง major version ถัดไปของแพ็กเกจ ก็ควรคาดหวังการเปลี่ยนแปลงไว้ด้วย

  • ยกตัวอย่าง Remix เพื่ออธิบายวิธีค่อย ๆ ปรับใช้การเปลี่ยนแปลงได้
  • มองว่าแพ็กเกจที่ดีต้องอาศัยความพยายามอย่างมาก

• แบ่งปันประสบการณ์การย้ายโปรเจ็กต์ SPA ไปใช้ Django และ HTMX พร้อมอธิบายว่าสามารถลด dependency ฝั่ง JavaScript ลงได้มาก

  • บอกว่า SPA ให้ความรู้สึกเหมือนระเบิดเวลาที่รอวันปะทุ

• โต้แย้งว่า React ไม่ควรถูกโทษจากแพ็กเกจภายนอกที่ดูแลรักษาไม่ดี

  • อธิบายว่าไม่จำเป็นต้องใช้ router หรือเครื่องมือจัดการสถานะอย่าง Redux

• คิดว่า v5 ของ react-query ควรเข้ากันได้กับ API ของ v3 แต่ก็อธิบายว่าการย้ายระบบทำได้ง่ายและไม่ใช่สิ่งจำเป็น

  • รู้สึกว่า "ความเหนื่อยล้าจากการจัดการ dependency" ถูกพูดเกินจริง และแนะนำให้รักษาจำนวน dependency ให้อยู่ในระดับที่สมเหตุสมผล

• ตั้งคำถามว่าทำไมถึงอัปเกรด ทั้งที่เว็บแอปไม่ได้ประโยชน์เพิ่มเติมอะไร

  • อธิบายว่าการอัปเกรดไปเวอร์ชันล่าสุดไม่ได้มีข้อดีเสมอไป

• อธิบายว่าหลังจากเลิกใช้ React และ nextjs แล้วเปลี่ยนไปใช้สแตกอื่น ความเครียดก็ลดลง และการอัปเดตไม่ทำให้รู้สึกหดหู่อีกต่อไป