HTMX ลองใช้สักครั้งเถอะ

• ในการพัฒนาเว็บสมัยใหม่ โครงสร้างแบบ ทางเลือกลวงระหว่าง HTML กับเฟรมเวิร์ก JavaScript ขนาดใหญ่ กำลังผลักให้นักพัฒนาต้องเผชิญความซับซ้อนที่ไม่จำเป็น
• HTMX จัดการ คำขอ AJAX, การอัปเดตบางส่วน, และการเปลี่ยนผ่านแบบแอนิเมชัน ได้ด้วย แอตทริบิวต์ของ HTML เพียงอย่างเดียว โดยใช้วิธีนำ HTML ที่เซิร์ฟเวอร์ส่งกลับมาไปแสดงผลบนหน้าจอตามเดิม
• ด้วยโครงสร้างที่สามารถค่อย ๆ นำมาใช้ได้โดยไม่ต้องเปลี่ยนโค้ดเบสเดิมครั้งใหญ่ จึงช่วยลดความซับซ้อนฝั่งฟรอนต์เอนด์และเพิ่มทั้ง ประสิทธิภาพการทำงานและความสามารถในการดูแลรักษา
• เมื่อเทียบกับ React แบบ SPA มีกรณีจริงในโปรดักชันที่ยืนยันการปรับปรุงอย่างมากในด้าน ปริมาณโค้ด, dependency, เวลา build, และความเร็วในการโหลด
• แทนที่จะเลือกเฟรมเวิร์กที่เกินความจำเป็น แนวทางแบบ hypermedia ที่เรียบง่าย กลับได้เปรียบกว่าสำหรับประสิทธิภาพและการดูแลรักษาในระยะยาว

---

ประเด็นปัญหา: ทางเลือกปลอมในโลกการพัฒนาเว็บ

• ในการถกเถียงเรื่องการพัฒนาเว็บ มักมีแต่ ตัวเลือกสุดโต่ง ว่าจะใช้แค่ HTML หรือใช้เฟรมเวิร์กขนาดใหญ่อย่าง React เท่านั้น
• HTML ล้วนมีความสามารถพื้นฐานที่แข็งแรงทั้งลิงก์ ฟอร์ม และ dialog แต่ก็ยังมีข้อจำกัดในเรื่อง การอัปเดตบางส่วนและการตอบสนองแบบทันที
• หากเลือก React·Vue·Angular ก็มักตามมาด้วย dependency หลายร้อยตัว, build ที่ช้า, และข้อถกเถียงเรื่องการจัดการ state ที่ซับซ้อน
• แม้แต่แอปแบบ CRUD, dashboard, หรือแอปที่เน้นฟอร์มง่าย ๆ ก็ยังถูกบังคับให้ใช้ ระบบเครื่องมือที่ใหญ่เกินความจำเป็น

แนวคิดหลักของ HTMX

• HTMX เป็นเครื่องมือที่เพิ่มแอตทริบิวต์พิเศษให้กับองค์ประกอบ HTML เพื่อทำ การสื่อสารแบบอะซิงโครนัสกับเซิร์ฟเวอร์
  • ตัวอย่างเช่น ใช้แอตทริบิวต์ hx-get, hx-post เพื่อส่งคำขอและแทรกผลตอบกลับลงใน DOM บริเวณที่กำหนด
• ขยายความสามารถให้ ทุกองค์ประกอบ HTML สามารถเป็นผู้ส่งคำขอ HTTP ได้
• ฝั่งเซิร์ฟเวอร์จะส่งกลับเป็น ชิ้นส่วน HTML โดยตรง แทน JSON และ HTML ที่ส่งกลับมาจะถูก แทนที่หรือแทรกโดยอัตโนมัติ ในตำแหน่งที่กำหนด
• กำหนดพฤติกรรมได้ด้วย การประกาศผ่านแอตทริบิวต์ HTML เท่านั้น โดยไม่ต้องเขียน JavaScript โดยตรง
• ไลบรารีมีขนาดประมาณ 14kb(gzip) ซึ่งเบามาก
• ใช้ได้กับ เอกสาร HTML เดิมได้ทันที โดยไม่ต้องมี build tool หรือการตั้งค่าเฟรมเวิร์กเพิ่มเติม
• เป็นโครงสร้างที่เข้ากันได้ดีกับแนวทางพัฒนาเว็บแบบดั้งเดิมที่ยึด server rendering เป็นศูนย์กลาง

ความสามารถหลัก

• การจัดการคำขอ AJAX: ส่งคำขอ GET และ POST ได้ด้วยแอตทริบิวต์ HTML เพียงอย่างเดียว
• การอัปเดต DOM: นำ HTML ที่เซิร์ฟเวอร์ส่งกลับมาสะท้อนบนองค์ประกอบที่กำหนดโดยอัตโนมัติ
• การจัดการอีเวนต์: เชื่อมการเรียกเซิร์ฟเวอร์ตามอีเวนต์ผู้ใช้ เช่น คลิกหรือพิมพ์ข้อมูล
• การจัดการ history: ทำงานร่วมกับการกดย้อนกลับและไปข้างหน้าของเบราว์เซอร์

กรณีใช้งานจริงและตัวเลข

• Contexte ย้าย SaaS ที่สร้างบน React ไปเป็น Django + HTMX
  • จำนวนบรรทัดโค้ดทั้งหมด ลดลง 67% (21,500 → 7,200)
  • JavaScript dependency ลดลง 96% (255 → 9)
  • เวลา build สั้นลง 88% (40 วินาที → 5 วินาที)
  • ความเร็วในการโหลดหน้า ดีขึ้น 50~60%
• ลบโค้ดเบสออกไปสองในสาม แต่แอปกลับดีขึ้น
• โดยไม่ต้องแยกฟรอนต์เอนด์กับแบ็กเอนด์ นักพัฒนาทุกคนสามารถทำงานแบบ full-stack ได้

สรุปคำโต้แย้งที่พบบ่อย

• "จำเป็นต้องมีการจัดการ client state ที่ซับซ้อนหรือเปล่า?"
  • ในความเป็นจริง ส่วนใหญ่ก็เป็นแค่ ฟอร์ม, ลิสต์, และองค์ประกอบที่แสดงตามการคลิก ซึ่ง HTMX ก็จัดการได้เพียงพอ
  • ถ้าเป็นเครื่องมือทำงานร่วมกันแบบเรียลไทม์อย่าง Google Docs ก็เป็นข้อยกเว้น แต่โดยมากแล้วผู้คน ประเมินความซับซ้อนของแอป CRUD สูงเกินไป
• "แล้วข้อดีของ ecosystem ฝั่ง React ล่ะ?"
  • ecosystem ที่ใหญ่โตมักหมายถึง node_modules ขนาดหลาย GB, ตัวเลือกที่ไม่สิ้นสุด, และข้อถกเถียงเรื่อง state management
  • ecosystem ของ HTMX จบลงแค่ที่ ภาษา server-side ที่คุณเลือกใช้เพียงภาษาเดียว
• "SPA ไม่ได้เร็วกว่าในแง่ประสบการณ์ใช้งานหรอกหรือ?"
  • ตอนเริ่มต้นยังต้องผ่าน การดาวน์โหลด JavaScript ขนาดใหญ่, parsing, execution, และ hydration ทั้งหมด
  • HTMX โหลดครั้งแรกได้เร็วกว่า และหลังจากนั้นก็ยังรักษาความเร็วตอบสนองไว้ได้ด้วยการ แทนที่เฉพาะส่วนที่เปลี่ยนแปลง
• "ถ้าจำเป็นต้องใช้ฟีเจอร์บางอย่างของ React จริง ๆ ล่ะ?"
  • ในบางกรณี React อาจเหมาะสม
  • แต่ในความเป็นจริง หลายครั้งผู้คนเลือกใช้เครื่องมือที่ จำเป็นแค่กับบางส่วนของปัญหาทั้งหมด จนกลายเป็นความเคยชิน
• ทำไมควรเลือก HTMX?
  • เหตุผลที่ทีมล้มเหลวไม่ใช่เพราะเลือกเฟรมเวิร์กผิด แต่เป็นเพราะ เลือกเฟรมเวิร์กมากเกินความจำเป็น
  • HTMX คือการ เดิมพันกับความเรียบง่าย และในระยะยาวความเรียบง่ายย่อมได้เปรียบทั้งด้านการดูแลรักษาและประสิทธิภาพการทำงาน

กรณีที่ HTMX ไม่เหมาะ

• เครื่องมือแก้ไขงานร่วมกันแบบเรียลไทม์ (Google Docs, Figma)
• แอปพลิเคชันที่ต้องมีการประมวลผลฝั่งไคลเอนต์จำนวนมาก (โปรแกรมตัดต่อวิดีโอ, เครื่องมือ CAD)
• โครงสร้างแบบ offline-first (แน่นอนว่าสามารถผสมหลายแนวทางเข้าด้วยกันได้)
• กรณีที่ต้องการ UI state ที่ซับซ้อนจริง ๆ

• แต่คุณกำลังสร้างสิ่งแบบนั้นอยู่จริงหรือ?
  • หรือจริง ๆ แล้วคุณแค่กำลังสร้าง dashboard, แผงผู้ดูแลระบบ, เว็บไซต์อีคอมเมิร์ซ, บล็อก, หรือแอป SaaS อีกตัวหนึ่งที่ประกอบด้วยแค่ฟอร์ม ตาราง และรายการ?
  • สำหรับสิ่งเหล่านี้ HTMX นั้นยอดเยี่ยมอย่างน่าทึ่ง ถึงขั้นอยากพูดว่า "ทำไมเราถึงทำให้มันซับซ้อนขนาดนี้นะ?" หรือ "โอ้โห ที่ผ่านมาเสียเวลาไปมากจริง ๆ"

งั้นก็ลองดูสักครั้ง

• คุณก็เคยใช้ React มาแล้ว เคยใช้ Vue มาแล้ว และคงเคยลอง Angular แล้วเสียดายทีหลังใช่ไหม?
  • รวมถึงเมตาเฟรมเวิร์กที่กำลังฮิตบน Hacker News สัปดาห์นี้ คุณก็คงเคยแตะมาบ้างแล้ว
• ลองใช้ HTMX แค่สักครั้งเถอะ
  • ลงทุนเวลาสักวันในช่วงสุดสัปดาห์
  • เลือก side project สักหนึ่งชิ้น
  • หรือเลือก internal tool ที่ไม่มีใครสนใจมากนัก
  • หรือหยิบสิ่งที่เคยผัดวันประกันพรุ่งไว้ว่าจะกลับมาสร้างใหม่ขึ้นมา
• เพิ่มแท็ก <script> แค่หนึ่งตัว แล้วเขียนแอตทริบิวต์ hx-get สักหนึ่งอัน จากนั้นลองดูด้วยตัวเองว่ามันทำงานอย่างไร
• อย่างแย่ที่สุดก็แค่เสียวันหยุดสุดสัปดาห์ไปหนึ่งวัน ซึ่งก็ไม่ได้เสียหายมาก
  • แต่คุณน่าจะไม่เกลียดมัน
  • และที่จริงแล้ว คุณอาจเริ่มสงสัยด้วยซ้ำว่าทำไมการพัฒนาเว็บถึงต้องซับซ้อนขนาดนี้

[iolothebard]

ปีที่แล้วเคยนำเสนอเรื่องแบบนี้ด้วยนะครับ/ค่ะ คนฟังมีไม่ค่อยเยอะเท่าไหร่แต่^^
https://www.slideshare.net/slideshow/htmx-2024/274315966

ในระดับ PoC ก็เคยทำอะไรแบบนี้ไว้ด้วยนะครับ/ค่ะ
https://github.com/iolo/hx

แต่ก็ไม่มีใครใช้ htmx เลยนะ 555

[shakespeares]

น่าเสียดายที่หลังจากสถานการณ์ที่คุ้นชินไปแล้ว และเมื่อระบบนิเวศขนาดใหญ่ถูกประกอบขึ้นมามากขนาดนั้น ทุกอย่างก็ดูเหมือนจะยิ่งแข็งตัวจนไม่มีความเคลื่อนไหวด้านนวัตกรรมอีกต่อไป

[roxie]

สไลด์สนุกดีนะครับ เสียดายที่ไม่ได้ดูพรีเซนต์ 555

[ryj0902]

ผมเคยฟังบรรยายที่เกี่ยวข้องในงาน PyCon อยู่ครั้งหนึ่ง และยังจำได้ว่าผู้บรรยายเองก็บอกว่ายังไม่ได้ลองใช้มันในงานจริงเหมือนกัน

[aer0700]

Rust ได้โปรดลองใช้สักครั้งเถอะ?

[bbulbum]

ผมเคยลอง Alpine.js มาก่อน แต่ส่วนใหญ่ก็ยังจำเป็นต้องมีการจัดการสถานะอยู่ดี...
ถ้าไม่ได้ออกแบบให้จัดการสถานะจากฝั่งแบ็กเอนด์มาตั้งแต่แรก ก็จำได้ว่าการจัดการสถานะแบบเป็นขั้นตอน สถานะแบบมีเงื่อนไข และอะไรทำนองนั้นค่อนข้างชวนปวดหัวเลยครับ

[roxie]

เห็นด้วยกับทุกอย่างที่พูดนะ แต่ก็ยังไม่ค่อยอยากหยิบ htmx มาใช้เลย T_T

[GN⁺]

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

• ฉันเป็นผู้สร้าง htmx รู้สึกขอบคุณที่มันได้รับความสนใจจากบทความที่ค่อนข้างพูดเกินจริง แต่ไม่ค่อยชอบกระแส hype แบบนี้เท่าไร
  วิธีสร้างเว็บแอปมีได้หลายแบบ และแต่ละแบบก็มีทั้งข้อดีข้อเสีย ฉันสรุปจุดแข็งกับจุดอ่อนของ htmx ไว้ในบทความนี้
  อีกไลบรารีแนว hypermedia-oriented ที่ยอดเยี่ยมมากอย่าง Unpoly ก็อยากแนะนำให้ลองใช้ด้วย
  (เพิ่มเติม) พอกลับไปอ่านเนื้อหาบทความอีกครั้ง ก็พบว่าดีกว่าที่คิด ถึงอย่างนั้นก็ยังอยากให้ htmx ถูกพูดถึงด้วย โทนที่สุขุมกว่านี้

  • ถ้าคุณคุ้นเคยกับวิธีสร้างเว็บแอปในช่วงต้นยุค 1999, HTMX ช่วยเพิ่ม ฟีเจอร์แบบโต้ตอบได้ด้วยความพยายามไม่มาก
    การอัปเดตฟิลด์จากดรอปดาวน์, การสร้าง modal, ช่องค้นหาแบบ autocomplete ทั้งหมดทำได้ง่าย
    แต่ความซับซ้อนของ RIA frontend จริง ๆ อยู่ที่การอัปเดต frontend อย่างไรเมื่อข้อมูลเปลี่ยน
    ฝั่ง backend อาจต้องปรับบางอย่าง และจะยิ่งดีถ้ามีโครงสร้างที่รองรับ partial update หลายส่วนพร้อมกันได้
  • มีบทความชื่อ HTMX Sucks ด้วย เป็นมุมมองที่น่าสนใจ
  • Unpoly ดูดีมากจริง ๆ ยังไม่ได้ลอง HTMX แต่ชอบที่มันช่วย แก้ปัญหา UX ของเฟรมเวิร์กอย่าง Django หรือ Rails แบบเบา ๆ
    ตอนนี้กำลังทำ side project ด้วย Rails + Stimulus แต่กลับรู้สึกว่า Stimulus เยอะเกินจำเป็น เลยสงสัยว่า ควรเลือก Inertia หรือ Stimulus เมื่อไร
  • เผื่อบอกไว้ ฉันเป็น CEO ของ htmx และฉันชอบบทความ พูดเกินจริง แบบนี้มาก
  • เอกสารของ Unpoly ก็ดีมาก แต่รู้สึกว่าซับซ้อนนิดหน่อย ถ้าเป็นเคสที่ง่ายกว่านี้ ฉันใช้ Alpine AJAX
    มันเป็น ปลั๊กอิน Alpine.js ที่เพิ่มความสามารถ AJAX พื้นฐานให้ลิงก์และฟอร์ม

• เริ่มเบื่อบทความที่อ้างว่าดีกว่า React จากตัวอย่าง “Hello World”
  ตัวอย่างง่าย ๆ อะไรก็ดูทำงานได้ดีทั้งนั้น แต่โลกจริงส่วนใหญ่คือ backend ที่มี dependency เยอะและ UI ที่ซับซ้อน

  • ความกลัวของนักพัฒนาต่อเฟรมเวิร์กที่ง่ายมาก ๆ สุดท้ายคือจะชนกับ ข้อจำกัดด้านการขยายระบบ
    เดโมพื้นฐานนั้นดี แต่ควรแสดงด้วยว่าจะขยายต่ออย่างไรเมื่อเพิ่มฟีเจอร์ที่ซับซ้อนขึ้น
    อยากรู้ว่าจะใส่ JS ตรงไหน ต้องมี build step ไหม และจะถูกผูกกับแนวคิดของ htmx มากแค่ไหน
  • มีแอปอย่าง Fizzy ที่ 37signals สร้างด้วย Hotwire
    มันไม่ใช่ว่าดีกว่า React แต่เป็นแค่ อีกแนวทางหนึ่ง
  • อินทราเน็ตของเรารันด้วย Python + HTMX จนถึงตอนนี้ยัง ไม่มีอะไรที่ทำไม่ได้
    แนวคิดการแทนที่บางส่วนของ DOM นั้นเรียบง่ายและเข้าใจได้ตรงไปตรงมามาก
  • ในทางกลับกัน บางเทคโนโลยีที่ซับซ้อนเกินไปก็ทำให้ “Hello World” ยังยากเลย
    เช่น effect-ts ที่ทรงพลังมาก แต่แค่แสดงผลธรรมดายังซับซ้อน
  • มีแอป Planning Poker แบบเรียลไทม์ที่สร้างด้วย Go + Htmx ใช้โค้ดแค่ราว 500 บรรทัด

• สตาร์ตอัปของเราเคยนำ HTMX มาใช้ แต่สุดท้ายกำลัง ย้ายไป React
  HTMX มีความซับซ้อนในการจัดการ response สูง และแต่ละ endpoint ต้องคืน HTML fragment หลายแบบ
  เอกสารกับตัวอย่างมีน้อย และยังไม่มี best practice สำหรับงานขนาดใหญ่
  React สุกงอมกว่า และยัง เข้ากับ AI coding ได้ดี ด้วย HTMX เหมาะกับโปรเจกต์ง่าย ๆ แต่ถ้าเกินกว่านั้นจะลำบาก

  • ฉันเจอ รูปแบบสถาปัตยกรรมที่ลื่นไหล สำหรับ HTMX แล้ว
    แต่ละ endpoint ทำหน้าที่เดียวเท่านั้น และตอบสนองทันทีด้วย Optimistic UI
    การจัดการ error ก็ทำให้ง่าย ใช้ hx-swap-oob ให้น้อยที่สุด
    หัวใจของการเลือกเทคโนโลยีคือการ ลด trade-off ให้ต่ำที่สุด
  • การที่ frontend กับ backend ต้องตกลงกันสำหรับทุกสถานการณ์นั้นเป็นเรื่องปกติอยู่แล้ว
    เพราะงั้นฉันจึงเน้น backend เป็นศูนย์กลางของ validation และให้ frontend มีหน้าที่แค่แสดงผล
  • หนังสือ Hypermedia Systems อธิบายภาพรวมแบบบูรณาการได้ดีกว่า
  • การเลือกโซลูชันเฉพาะทางที่ตัวเองยังไม่เข้าใจ แล้วค่อยย้ายไปหาอีกความซับซ้อนหนึ่ง ก็เป็นแค่การ วนซ้ำ trade-off
  • การเลือกเทคโนโลยีเพราะ “เหมาะกับ AI coding” ฟังดูน่าเศร้านิดหน่อย

• ฉันไม่ต้องการ SSR เลย backend ควรให้แค่ JSON API แล้ว frontend ก็นำไปใช้
  ฉันคิดว่า SSR ถูก hype เกินจริง มันเหมือนเป็นกลยุทธ์ชักจูงเพื่อขายบริการคลาวด์มากกว่า

• ตัวอย่าง Demo 3 Live Search มีปัญหา scroll jank หนักมาก
  เหมือนผลลัพธ์ถูกแทรกลงในเอกสารโดยตรง ทำให้ต้องคำนวณ layout ใหม่ตลอด

• React ก็โอเคมากพออยู่แล้ว ต่อให้เป็นโปรเจกต์ง่าย ๆ ก็ไม่ได้มีเหตุผลจำเป็นที่จะต้องไปเรียนรู้อีก paradigm หนึ่ง

  • สุดท้าย React ก็ render ออกมาเป็น HTML อยู่ดี ดังนั้นก็ยังต้อง เรียน HTML/CSS อยู่ดี
    มันแค่มี abstraction เพิ่มเข้ามาเท่านั้น
  • ecosystem ของ React กว้างเกินไปจนมีความ เหนื่อยกับการต้องเรียนแล้วลืมอยู่เรื่อย ๆ
    ขณะที่ HTMX ใช้ 15 นาทีก็เข้าใจแนวคิด และใช้ได้ไปอีก 10 ปี
  • React หรือ Angular เป็นโครงสร้างแบบ เอา MVC อีกชั้นไปทับบน MVC มันซับซ้อนเกินจำเป็น
  • การใช้โซลูชันหนัก ๆ กับทุกที่ไม่มีประสิทธิภาพ
    ในประวัติศาสตร์ แนวทางที่เบากว่า มักเป็นฝ่ายชนะตลาด และ React เองก็เคยเป็นแบบนั้นมาก่อน
  • เหตุผลง่ายมาก — ประสิทธิภาพ

• ฉันไม่ได้ตกหลุมรัก HTMX แต่ตกหลุมรัก Alpine.js แบบเต็ม ๆ
  แนวคิดเรื่องการ enhance HTML ที่ render มาจากเซิร์ฟเวอร์มันคลิกมาก
  ไม่ว่าจะ dropdown, show/hide ทุกอย่างตรงไปตรงมาและไม่ต้องมี build step

  • Alpine ก็มีปลั๊กอิน Alpine AJAX ที่ให้ความสามารถคล้าย HTMX ด้วย
  • ฉันก็ใช้ Alpine.js เหมือนกัน และทำให้ frontend กลับมาสนุกอีกครั้ง
    มันตรงไปตรงมาและจัดการได้ง่ายแม้ในโปรเจกต์ขนาดใหญ่
  • แต่ในโปรเจกต์เชิงพาณิชย์ Alpine อาจกลายเป็น ฝันร้าย ได้
    ถ้าใส่ JS แบบ inline ลงใน HTML ไปเรื่อย ๆ จะดูแลรักษายาก และการจัดการ state ก็เป็นนัยเกินไป
    รู้สึกว่า Hotwire หรือ Stimulus เหมาะกับงานระดับองค์กรกว่ามาก
  • แนวทางเชิงประกาศคือคำตอบ

• ถ้าจะใช้ HTMX กับแอปขนาดใหญ่ ก็สงสัยเรื่อง ภาระของเซิร์ฟเวอร์และต้นทุน
  เพราะ render HTML ที่เซิร์ฟเวอร์น่าจะใช้ทรัพยากรมากกว่า JSON

  • แต่ก็ไม่จำเป็นต้องเป็นแบบนั้นเสมอไป การ render template เร็วมาก
    บางครั้งยังมีประสิทธิภาพกว่า JSON serialization ด้วยซ้ำ และฝั่ง client เองก็มีต้นทุนในการ deserialize เหมือนกัน
    ถ้าใช้ HTMX คู่กับเครื่องมืออย่าง Alpine.js ก็จัดการ state ที่ซับซ้อนได้ง่าย
    มันไม่เหมาะกับทุกสถานการณ์ แต่ใน หลายกรณีมันทำงานได้ดีมาก

• การออกไปเทศนาเฟรมเวิร์กคือ วัฒนธรรมที่แย่ที่สุด ของ ecosystem ฝั่งเว็บ
  ถ้ามันเป็นโซลูชันที่ดี เดี๋ยวมันก็จะถูกนำไปใช้เอง ไม่จำเป็นต้องทำตัวเหมือนนักเผยแผ่
  เรื่องการโจมตี npm ก็ถูกพูดเกินจริง htmx เองสุดท้ายก็ต้องใช้ npm อยู่ดี

  • htmx เป็น ไฟล์เดี่ยวไร้ dependency เลยไม่จำเป็นต้องใช้ npm ก็ได้
  • คำพูดที่ว่า “โซลูชันที่ดีจะถูกนำไปใช้เองตามธรรมชาติ” นั้นไม่จริง
    ในโลกนี้มี โซลูชันแย่ ๆ มากมายที่ถูกรับไปใช้เพราะการตลาดและการรับรู้ชื่อ
  • ความนิยม งบประมาณ และความเฉื่อย เป็นตัวกำหนดการยอมรับเทคโนโลยี
    ถ้าอยากรักษางานฝีมือที่แท้จริงไว้ ก็ต้อง ต้านอคติเหล่านี้

• HTMX ดูเหมือน รวมแต่ข้อเสียของทั้งสองโลกเข้าด้วยกัน
  SSR มีความเป็นเอกภาพ ส่วน CSR แยกโครงสร้างชัดเจน แต่ HTMX เอาทั้งสองอย่างมาปนกันจนเกิด การผูกกันแบบแฝง
  ถ้าจะนำเสนอข้อมูลเดียวกันในรูปแบบอื่น ก็สงสัยว่าฝั่ง backend ต้องสร้าง สอง endpoint หรือไม่

  • ต้องเลิกคิดก่อนว่า frontend state เป็นสิ่งจำเป็นเสมอไป
    แอปส่วนใหญ่ใช้แค่ state ใน backend ก็พอแล้ว และนอกจากช่วย UX ก็ไม่ได้มีประโยชน์มากนัก
  • ถ้าอ่านบทความ Splitting Your APIs จะพบว่านี่อาจเป็นข้อดีด้วยซ้ำ
  • ถ้าใช้ server template อย่าง Jinja ก็สามารถจัดการ หลายรูปแบบการแสดงผล ได้ในการ render ครั้งเดียว
    ถ้าประกอบทั้งหน้าโดยให้เซิร์ฟเวอร์ทำ ข้อมูลก็อยู่ในนั้นอยู่แล้ว