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

 (htmx.org)
6 คะแนน โดย GN⁺ 2024-10-04 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Gumroad พิจารณา htmx สำหรับโปรเจกต์ใหม่ Helper โดยคาดหวังฟรอนต์เอนด์ที่เบา แต่เมื่อความต้องการด้าน UX ที่ซับซ้อนเพิ่มขึ้น จึงเปลี่ยนไปใช้ React/Next.js
  • htmx ดูมีอนาคตสำหรับปฏิสัมพันธ์แบบง่าย แต่ในฟอร์มที่มีการตรวจสอบแบบไดนามิกและฟิลด์ตามเงื่อนไข ลอจิกฝั่งเซิร์ฟเวอร์กลับยืดยาวจนขั้นตอนการพัฒนาไม่เป็นธรรมชาติ
  • drag-and-drop ของตัวสร้างเวิร์กโฟลว์, การทำงานร่วมกันแบบเรียลไทม์, การจัดการสถานะที่ซับซ้อน และการสร้างฟอร์มแบบไดนามิก ถูกทำได้ตรงไปตรงมามากกว่าด้วย ecosystem และ component model ของ React
  • แหล่งข้อมูลสำหรับแก้ปัญหาและการรองรับจากเครื่องมือ AI มีมากกว่าทางฝั่ง Next.js และ React ขณะที่ htmx เสียเปรียบด้านความเร็วในการพัฒนาเพราะมีข้อมูลโอเพนซอร์สสำหรับการเรียนรู้น้อยกว่า
  • htmx อาจเหมาะกับแอปที่เรนเดอร์ฝั่งเซิร์ฟเวอร์อยู่แล้วหรือโมเดลปฏิสัมพันธ์ที่เรียบง่าย แต่สำหรับอินเทอร์เฟซที่มีสถานะจำนวนมากอย่าง Helper, React และ Next.js เหมาะสมกว่า

เบื้องหลังที่ Helper พิจารณา htmx

  • Gumroad เริ่มโปรเจกต์ใหม่ Helper และพิจารณา htmx เป็นตัวเลือกฝั่งฟรอนต์เอนด์
  • ความคาดหวังในตอนแรกมาจากประสบการณ์เดิมที่มองว่า React หนักเกินความจำเป็น และเห็นว่า htmx อาจเป็นวิธีเพิ่มปฏิสัมพันธ์แบบง่ายได้อย่างเบาแรง
  • ภายในทีมยังมีมุมมองว่า htmx คล้ายมีมที่ล้อเลียน ecosystem ของ JavaScript ที่ซับซ้อนขึ้นเรื่อย ๆ
    • เช่นเดียวกับที่ Tailwind ดูเหมือนเป็นอีกไวยากรณ์หนึ่งของ inline CSS, htmx ก็ถูกมองว่าใกล้เคียงกับอีกไวยากรณ์หนึ่งของ inline JavaScript
  • Tailwind กลายเป็นส่วนหนึ่งของชุดเครื่องมือของ Gumroad ได้ แต่ htmx ไม่สามารถขยายให้เข้ากับเป้าหมายของ Helper ได้ และไม่ได้นำไปสู่ประสบการณ์ผู้ใช้ที่ดีที่สุดสำหรับลูกค้า

จุดที่ React/Next.js ดูเป็นธรรมชาติมากกว่า

  • ประสบการณ์การพัฒนาและการจัดการฟอร์ม

    • แม้จะทำให้ถูกต้องด้วย htmx ได้ แต่ Gumroad รู้สึกว่าการทำให้ฟีเจอร์ทำงานบน Next.js ตรงไปตรงมามากกว่า
    • ในฟอร์มที่ซับซ้อนซึ่งมี การตรวจสอบแบบไดนามิก และฟิลด์ตามเงื่อนไข งานฝั่งไคลเอนต์ของ React เรียบง่ายกว่า ขณะที่ htmx ทำให้ลอจิกฝั่งเซิร์ฟเวอร์ยาวขึ้น

  • UX และข้อจำกัดด้านปฏิสัมพันธ์

    • htmx มีแนวโน้มผลักแอปไปในแนวทางแบบ Rails/CRUD ทำให้ประสบการณ์พื้นฐานออกมาในรูปแบบทั่ว ๆ ไปหรือค่อนข้างธรรมดาได้ง่าย
    • อินเทอร์เฟซ drag-and-drop ของตัวสร้างเวิร์กโฟลว์ต้องอาศัยวิธีอ้อม ๆ เมื่อทำด้วย htmx และให้ความรู้สึกแข็งกว่าเมื่อเทียบกับประสบการณ์ที่ลื่นไหลจากไลบรารี React

  • เครื่องมือ AI และความเร็วในการแก้ปัญหา

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

  • ความซับซ้อนและการขยายระบบ

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

ความต่างที่เห็นได้จากฟีเจอร์ของ Helper

  • drag-and-drop: react-beautiful-dnd ใน ecosystem ของ React มอบ drag-and-drop ที่ลื่นไหลและเข้าถึงได้ด้วยการตั้งค่าไม่มาก
  • การจัดการสถานะที่ซับซ้อน: การสะท้อนค่าตั้งต้นและลอจิกเงื่อนไขของแต่ละขั้นในเวิร์กโฟลว์สู่ UI แบบเรียลไทม์ ทำได้ตรงไปตรงมามากกว่าด้วยแนวทางจัดการสถานะของ React เช่น useState หรือ Redux
  • การสร้างฟอร์มแบบไดนามิก: งานสร้างฟอร์มตั้งค่าที่ต่างกันตามประเภทของแต่ละขั้น และปรับเปลี่ยนตามอินพุตของผู้ใช้ จัดการได้เข้าใจกว่าด้วย component model ของ React
  • การทำงานร่วมกันแบบเรียลไทม์: ฟีเจอร์ที่ให้ผู้ใช้หลายคนแก้ไขเวิร์กโฟลว์พร้อมกัน ถูกสร้างได้ค่อนข้างตรงไปตรงมาด้วย WebSockets และ React ขณะที่ htmx ต้องใช้ลอจิกฝั่งเซิร์ฟเวอร์ที่ซับซ้อนกว่าและ JavaScript แบบคัสตอม
  • การปรับแต่งประสิทธิภาพ: เมื่อเวิร์กโฟลว์ใหญ่และซับซ้อนขึ้น React สามารถปรับแต่งการเรนเดอร์ได้ละเอียดด้วย virtual DOM และ hooks อย่าง useMemo, useCallback

ecosystem และบทสรุปสุดท้าย

  • ecosystem ของ React/Next.js มีขนาดใหญ่และเติบโตเต็มที่ จึงมีวิธีแก้เกือบทุกปัญหาที่ Gumroad พบเจอ
  • ใน htmx มักต้องยอมประนีประนอมกับฟีเจอร์หรือสร้างสิ่งต่าง ๆ ขึ้นใหม่เอง และในการเชื่อมต่อกับบริการหรือไลบรารีภายนอกก็มักมี React bindings แต่ไม่มีตัวรองรับสำหรับ htmx
  • หลังย้ายไป React/Next.js แล้ว Gumroad ประเมินว่านี่เป็นทางเลือกที่เหมาะกับการสร้าง UX ที่ซับซ้อนมากกว่า
    • ทีมเคลื่อนที่ได้เร็วขึ้น สร้างประสบการณ์ผู้ใช้ที่ชวนมีส่วนร่วมได้มากขึ้น และใช้ประโยชน์จากเครื่องมือกับไลบรารีที่มีอยู่เดิมได้
    • ยังช่วยยกระดับประสบการณ์การใช้งานแอปสำหรับลูกค้าหลักของ Helper ได้อย่างมาก
  • ข้อจำกัดของ htmx ไม่ได้เป็นสิ่งที่แก้ไม่ได้ แต่กระบวนการแก้ปัญหากลับพาออกจากจุดแข็งของ htmx ไปสู่แนวทางที่เป็นธรรมชาติกว่าในสภาพแวดล้อมที่เน้น JavaScript
  • htmx อาจเป็นตัวเลือกที่ดีสำหรับโปรเจกต์ที่สร้างบนแอปแบบ server-rendered เดิม หรือมีโมเดลปฏิสัมพันธ์ที่เรียบง่าย
  • สำหรับอินเทอร์เฟซที่ซับซ้อนและมีสถานะจำนวนมากอย่าง Helper, React และ Next.js เหมาะกว่า และ Gumroad มองว่าสามารถประเมินเทคโนโลยีสแต็กใหม่ได้ต่อไปตามความต้องการที่เปลี่ยนแปลงและเทคโนโลยีใหม่ ๆ

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

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

 
GN⁺ 2024-10-04
ความคิดเห็นบน Hacker News

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

    • ท่าทีที่ยอมเปิดเผยเองว่า htmx อาจไม่ใช่ทางเลือกที่ดีที่สุดเสมอไป ทำให้ยิ่งเคารพโปรเจกต์นี้มากขึ้น
      เมื่อเทียบกับโปรเจกต์อื่น ๆ ที่อ้างว่าเป็นคำตอบที่ดีที่สุดสำหรับทุกอย่างแล้ว ถือว่าสดใหม่ดี
      โดยเฉพาะประเด็นเรื่อง drag and drop นั้นน่าสนใจ อยากรู้ว่าใน htmx มองว่ายากจริงหรือไม่ และถ้าใช่ มีแผนจะแก้หรือเปล่า
    • CEO ของ Gumroad ยังบอกด้วยว่า Rails เองเป็นหนี้ทางเทคนิค และพอถามเหตุผลก็ตอบเพียงว่า React ดีกว่ามาก
      ทั้งที่ Rails กับ React ก็ใช้งานร่วมกันได้ ไม่ใช่ว่าทำไม่ได้
      ตัวบทความเองดูไม่ค่อยเหมือนประสบการณ์เชิงลบเกี่ยวกับ htmx เท่าไร แต่ดูเหมือนว่าทันทีที่มี drag and drop และการทำงานร่วมกันแบบเรียลไทม์เข้ามา การเลือก ทดลองใช้ htmx ตั้งแต่แรกอาจเป็นทางเลือกที่ผิด
      ก็ไม่ค่อยเข้าใจว่าสกรีนช็อตต้องการแสดงอะไร แต่ถึงอย่างนั้นก็คิดว่าเป็นบทความที่เหมาะจะลงบนเว็บไซต์ htmx
    • การแสดงให้เห็นจุดที่ htmx อาจเหมาะน้อยกว่าเครื่องมืออื่นเป็นสิ่งที่น่าเคารพ
      สำหรับผม htmx ใกล้เคียงกับ ตัวแทนของ jQuery มากกว่าตัวแทนของ React
      htmx และ jQuery เพิ่มการโต้ตอบให้เอกสาร ส่วน React พยายามจะเป็นทั้งเอกสารทั้งหมด
      เครื่องมือควรเปลี่ยนไปตามงาน
    • หลังจากอ่านบทความที่ลิงก์ไว้และ https://htmx.org/essays/htmx-sucks/ แล้ว ก็ทำให้ตัดสินใจว่าจะไม่ใช้ htmx หรือแนะนำให้คนอื่นใช้
    • เธรดอื่นคือ https://news.ycombinator.com/item?id=41727315

  • ส่วนที่ว่า “AI และการรองรับเครื่องมือ: worth noting ด้วยว่าเครื่องมือ AI คุ้นเคยกับ Next.js มาก แต่ไม่ค่อยคุ้นกับ htmx” ถูกเขียนแบบเรียบ ๆ เหมือนเป็นข้อเสีย แต่สำหรับอนาคตของเครื่องมือพัฒนา ไลบรารี เฟรมเวิร์ก และภาษาแล้ว นี่เป็นสัญญาณที่ค่อนข้างน่าขนลุก
    ถ้าจะคาดการณ์ โมเดลภาษาขนาดใหญ่ จะยิ่งขยายปรากฏการณ์ผู้ชนะกินรวบและผลจากการได้เปรียบก่อนให้มากขึ้น และด้วยข้อมูลฝึกที่มีมากกว่าและดีกว่า ก็จะยิ่งส่งเสริมการใช้เครื่องมือโอเพนซอร์สมากขึ้นด้วย

    • ปัญหาเรื่อง AI และการรองรับเครื่องมือ จริง ๆ แล้วเป็นส่วนต่อขยายของปัญหา ชุมชนและระบบนิเวศ
      ก่อนยุคโมเดลภาษาขนาดใหญ่ React ก็ได้เปรียบอยู่แล้ว เพราะคำถามส่วนใหญ่มีอยู่บน StackOverflow แล้ว และมีไลบรารีที่โตเต็มที่สำหรับแทบทุกการใช้งาน
      ตอนนี้เพียงแค่มีคนที่เคยจะไปถาม StackOverflow หันมาถามโมเดลภาษาขนาดใหญ่แทน และผลลัพธ์ก็เหมือนเดิม
      ถ้าใช้สิ่งที่คนอื่นใช้กันมาก ก็จะได้ข้อได้เปรียบ
    • การที่โมเดลภาษาขนาดใหญ่จะเพิ่มแรงผู้ชนะกินรวบและผลจากการได้เปรียบก่อนของเครื่องมือพัฒนา น่าจะจริงสำหรับคนที่พึ่งพาโมเดลภาษาขนาดใหญ่ในการเขียนโค้ด
      แต่ในฐานะกลยุทธ์ระยะยาวสำหรับอาชีพวิศวกรซอฟต์แวร์ ผมมองอย่างหนักแน่นว่าไม่ใช่การเดิมพันที่ดีนัก
    • เครื่องมือ AI ถูกตรึงไว้กับช่วงเวลาหนึ่ง และแม้จะฝึกด้วยข้อมูลใหม่ ปริมาณข้อมูลที่ฝึกได้ก็มีขีดจำกัด
      ผมเคยคิดด้วยซ้ำว่านี่อาจเป็น เรื่องดี
      วงการซอฟต์แวร์ใช้เวลามากเกินไปกับการไล่ตามเครื่องมือใหม่ ฟีเจอร์ภาษาใหม่ และเฟรมเวิร์กใหม่
      การนิ่งลงสักหน่อย แล้วทำงานให้เสร็จด้วยเครื่องมือที่มีอยู่ แทนที่จะสร้างค้อนอันใหม่ทุก 6 เดือน อาจเป็นเรื่องบวกก็ได้
    • ถ้านักพัฒนาทำงานไม่ได้ถ้าไม่มีอะไรสักอย่างมาเขียนโค้ดแทนตัวเอง ก็ไม่รู้เหมือนกันว่าจ้างมาทำไมตั้งแต่แรก
    • ไม่ได้กังวลเรื่องนี้มากนัก และความกังวลของ Gumroad ก็อาจถูกพูดเกินจริง
      จากคอมเมนต์อย่างเดียวบอกไม่ได้ว่าเป็นประสบการณ์ที่ AI จัดการ HTMX ได้ไม่ดีจริง ๆ หรือแค่โยงไปถึงเรื่องขาดแหล่งข้อมูลอื่น
      โมเดลภาษาขนาดใหญ่มักทำงานได้ดีมากในแบบ ตัวแปลภาษาทั่วไป
      ถ้ามันเรียนรู้แพตเทิร์นและแนวคิดทั่วไปของเฟรมเวิร์กยอดนิยม และรู้ไวยากรณ์ของเฟรมเวิร์กที่เล็กกว่าพอสมควร จากประสบการณ์ มันก็สร้างโค้ดของเฟรมเวิร์กเฉพาะทางที่ดีได้พอควร
      คล้ายกับที่โจรสลัดสามารถพูดเรื่องที่ไม่เคยมีใครในข้อมูลฝึกพูดไว้ ด้วยสำเนียงโจรสลัดได้

  • พอเห็นส่วนที่ว่า “เมื่อสร้างฟอร์มซับซ้อนที่มีการตรวจสอบแบบไดนามิกและฟิลด์ตามเงื่อนไข เรากลับต้องเขียนลอจิกฝั่งเซิร์ฟเวอร์ที่ซับซ้อนเพื่อจัดการงานที่ใน React จะเป็นงานฝั่งไคลเอนต์ง่าย ๆ” ก็ทำให้นึกถึงมีม Anakin Padme
    “แต่ก็ยังทำ การตรวจสอบฝั่งเซิร์ฟเวอร์ ด้วยใช่ไหม… ใช่ไหม?”

    • ถ้าฟอร์มบนเว็บซับซ้อนกว่าแบบฟอร์มกระดาษ ผมว่าคงต้องกลับมาคิดใหม่ถึงตัวฟอร์มเว็บนั้นเอง
      ฟอร์มที่ทำง่ายใน React แต่ยากใน htmx นั้นนึกไม่ค่อยออก นอกจากกรณีที่อยากยัด state ระดับแอปแบบ React เข้าไป แล้วใช้ไลบรารีทำให้เสร็จ 90%
    • บนเซิร์ฟเวอร์ก็ตรวจสอบเหมือนกัน
      เพียงแต่ทำ ครั้งเดียวตอน submit ไม่ใช่ทุกหน้า

  • ตรงข้ามกับคำพูดที่ว่า “คิดว่า htmx อาจเป็นทางออกที่ดีในการทำให้ frontend เบามาก” ดูเหมือนว่าทันทีที่เลิกยึด frontend แบบเบา htmx ก็ไม่เหมาะอีกต่อไป
    เริ่มใช้ไลบรารีภายนอกเพื่อเรนเดอร์ UI/UX และการจัดการ state ที่ซับซ้อน
    อีกอย่าง การบอกว่า “ทำ X ใน React ง่ายกว่า” ไม่ใช่การเปรียบเทียบที่ยุติธรรม ถ้าทำสิ่งนั้นด้วยไลบรารีภายนอก
    ที่ไม่ต้องทำเองก็เพราะมีคนอื่นทำให้แล้วเท่านั้น
    ผมเห็นด้วยกับบทความหลายส่วน แต่ถ้ารู้อยู่แล้วว่าต้องใช้ state และการเรนเดอร์ที่ซับซ้อน htmx ก็ไม่ใช่ทางออกที่ดีตั้งแต่แรก

    • เห็นด้วยตรงนั้นเลย
      ผมชอบ htmx แต่บทความนี้แสดงให้เห็นว่าผู้เขียนมีความเข้าใจเชิงเทคนิคค่อนข้างจำกัด
      มันไม่ใช่ข้อดีข้อเสียที่จะเห็นได้จากการรู้จักเว็บแพลตฟอร์มและเอกสาร htmx.org แค่เล็กน้อย แต่ดูเหมือนเป็นการอยากลองใช้ HTMX เพราะกระแสมากกว่า
    • เป็นภาพสะท้อนที่ดีของคนที่ไม่ควรใช้ React ตั้งแต่แรก แล้วมาเขียนว่า “พอเปลี่ยนแอป React เป็น htmx ทุกอย่างก็ดีขึ้นมาก”
    • มุม htmx ปะทะ JavaScript ทำให้นึกถึงการทดสอบแบบ behavior-driven development ของ behave กับการทดสอบของ pytest
      ภาษา Gherkin ดูดีในกรณีเรียบง่าย และโดยหลักการก็ขยายไปยังกรณีซับซ้อนได้ แต่ยิ่งต้องจัดการระดับ abstraction หลายชั้นมากเท่าไร pytest ที่เป็น Python ล้วนก็ยิ่งสะดวกกว่า
    • ผมก็คิดเหมือนกัน
      ขอบเขตโปรเจกต์ไม่ได้ “เรียบง่าย” เลย และถ้าเป็นผมคงไป React ตั้งแต่แรก
    • แค่ดูคำอธิบายฟีเจอร์ที่ต้องการ ก็เห็นชัดว่าจำเป็นต้องใช้ JavaScript หนัก ๆ อย่างเลี่ยงไม่ได้

  • ในส่วนที่บอกว่า “การทำอินเทอร์เฟซแบบลากแล้ววางสำหรับ workflow builder เป็นความท้าทายใหญ่ใน htmx และต้องใช้ทางอ้อมที่ดูเทอะทะเมื่อเทียบกับประสบการณ์ที่ลื่นไหลจากไลบรารี React” นั้น HTMX จะเหมาะกว่าเมื่อให้มันทำเท่าที่จำเป็นสำหรับ frontend bundle และไม่เกินกว่านั้น
    แค่ผูกเข้ากับอีเวนต์ htmx.onLoad แล้วค้นหาและผูกมาร์กอัปที่มีแอตทริบิวต์อยู่ในคอนเทนต์ที่โหลดมา เช่น columns, cards, tasks เป็นต้น
    ตัวอย่างเช่น สามารถ bind sortable.js เข้ากับมาร์กอัปที่เรนเดอร์แล้ว และเชื่อมอีเวนต์ sortable เข้ากับการอัปเดตสถานะผ่าน HTMX ได้
    ค่อนข้างตรงไปตรงมา และในเอกสารก็มีตัวอย่างแบบนี้พอดี: https://htmx.org/docs/#3rd-party

    • ผมกำลังใช้ HTMX ร่วมกับคอมโพเนนต์ UIKit อยู่
      เว็บไซต์สมัยใหม่ที่มี state และมีความเป็นไดนามิก ไม่ได้เข้ากับ HTMX ไม่ได้เลย

  • อ่านบทความแล้วทีมดูคุ้นเคยกับ การพัฒนา frontend มากกว่าการพัฒนา backend
    จากมุมมองของนักพัฒนาแบบเก่า บางครั้งจะเห็นความกลัวและความเข้าใจผิดเล็ก ๆ ในวิธีคิดของนักพัฒนา frontend
    พูดตรง ๆ ผมคิดว่าแค่ปรับวิธีคิดนิดหน่อยก็เข้าใจได้แล้วว่าวิธีนี้ทำงานอย่างไร แต่ก็เข้าใจเช่นกันว่าหลายคนไม่เคยเห็นแนวทาง client/server แบบทั่วไปมาตลอดอาชีพ
    อย่างไรก็ตาม ก็ปฏิเสธไม่ได้ถึงคุณค่าของคอมโพเนนต์ React สำเร็จรูป รวมถึงข้อดีที่หาเอกสารและความช่วยเหลือได้ง่าย

    • ผมคิดว่าไม่ใช่แค่นักพัฒนาเท่านั้น แต่ UX designer ที่ คิดแบบ React ก็เป็นอุปสรรคใหญ่ที่สุดต่อการนำ htmx มาใช้
      ดีไซเนอร์รุ่นหนึ่งออกแบบ mobile กับ web ให้คล้ายกันมาก แล้วโยนความซับซ้อนในการ implement ให้กับนักพัฒนา
      แต่เว็บควรจะแตกต่างจาก mobile ได้ และควรต่างเมื่อเป็นไปได้
      ในบทความบอกว่าดีไซน์ดู “generic” เกินไปเหมือนแอป CRUD แต่นั่นแย่จริงหรือ?
      เรามีความสำเร็จอันยิ่งใหญ่คือ document model ที่ถูกนำไปใช้อย่างแพร่หลาย ซึ่งช่วยสร้างประสบการณ์ผู้ใช้ที่คาดเดาได้ในทุกไซต์ แต่เรากลับมองมันแค่ว่า “น่าเบื่อ”
      เหมือนกับว่าความน่าเบื่อนั้นมีปัญหาโดยเนื้อแท้
      ผมเข้าใจแรงกดดันจากตลาดที่ต้องการประสบการณ์เฉพาะตัวและมีแบรนด์ชัดเจนเหมือน mobile app แต่ก็อดจินตนาการไม่ได้ว่าถ้าดีไซเนอร์คิดแบบ WWW ได้พอ ๆ กับที่คิดแบบ React จะเป็นอย่างไร

  • ผมชอบที่ HTMX นำบทความแบบนี้และบทความคล้าย ๆ กันไปไว้บนเว็บไซต์ของตัวเอง
    ดูเหมือนมีเหตุผลสมควรอยู่ไม่น้อยที่ HTMX อย่างเดียวไม่เหมาะกับกรณีนี้
    ผมไม่ใช่ผู้เชี่ยวชาญ frontend แต่มีความเห็นอยู่บ้าง
    อย่างแรก ยังไงก็ต้องทำ form validation ที่ backend อยู่แล้วไม่ใช่หรือ?
    ผมสงสัยว่าทำไมระบบ backend ถึงส่งผลลัพธ์ไปให้ frontend ได้ยากขนาดนั้น
    หลายกรณีมีเหตุผลที่ดีมากที่จะต้องทำ form validation ทั้งฝั่ง frontend และ backend ดังนั้นในกรณีนั้น HTMX อย่างเดียวอาจไม่พอ แต่การอธิบายปัญหานี้ค่อนข้างทำให้สับสน
    อย่างที่สอง ถ้าใช้แต่ HTMX แอปอาจถูกผลักไปในทิศทางนี้ในระดับหนึ่ง และบางกรณีก็เป็นเรื่องดี แต่ดูเหมือนพวกเขาตัดสินใจว่าต้องใช้วิธีอื่นเพื่อลูกค้า
    อย่างที่สาม ผมอยากรู้มากขึ้นว่าทีมนี้ใช้เครื่องมือ AI อย่างไร จนการพึ่งพาเครื่องมือ AI กลายเป็นปัญหาหลัก
    ถ้าเครื่องมือพัฒนา AI สำคัญขึ้นในอนาคต ก็เป็นคำถามที่น่าสนใจว่าเกณฑ์ในการมีเครื่องมือและ integration มากพอจน framework หรือภาษาโปรแกรมใหม่ ๆ ถูกนำมาใช้ จะสูงเกินไปหรือไม่
    อย่างที่สี่ เช่นเดียวกับข้อร้องเรียนที่พบบ่อยเกี่ยวกับ HTMX บางโปรเจกต์ต้องการมากกว่าสิ่งที่ HTMX ให้ได้
    อย่างที่ห้า หนึ่งในเหตุผลที่ผมชอบ Django และ Python ก็คือชุมชนที่ลึกซึ้ง รวมถึง ecosystem ของ integration และ add-on
    สิ่งที่แนวคิดคล้ายกันแต่มีฟีเจอร์มากกว่า HTMX อย่าง https://unpoly.com/ อาจเหมาะกับพวกเขามากกว่า

  • สำหรับคำว่า “กระบวนการพัฒนาของ Next.js ให้ความรู้สึกเป็นธรรมชาติ” ผมไม่รู้ว่าส่วนไหนของไวยากรณ์ ReactJS นี้ที่เป็นธรรมชาติ
    มันอาจคุ้นเคยได้ แต่ ไม่เป็นธรรมชาติ
    useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

    • เท่าที่ผมรู้ HTMX ไม่มีวิธีแก้ปัญหาที่สวยงามสำหรับ timer และ interval
      สุดท้ายก็คงต้องต่อด้วย JavaScript แบบเก้ ๆ กัง ๆ
    • ตัวอย่างโค้ดนี้ถือว่าค่อนข้างใจดีแล้ว
      ถ้าต้องการ custom hook ที่มี timeout เปลี่ยนแปลงได้ มันอาจซับซ้อนกว่านี้มาก
      Dan ยังต้องเขียนบทความยาวเกี่ยวกับเรื่องนี้: https://overreacted.io/making-setinterval-declarative-with-r...
    • ผมสงสัยว่าโค้ดที่ดูเป็นธรรมชาติสำหรับ use case นี้หน้าตาเป็นอย่างไร
      ลองเขียนโค้ดให้ดูได้ไหม?

  • น่ายกย่องที่ htmx.org โฮสต์บทความนี้

    • ผมคิดว่ามีคุณค่ามากถ้าบริการหรือเครื่องมืออธิบายไม่ใช่แค่ว่าทำไมควรใช้ แต่รวมถึง ทำไมไม่ควรใช้ ด้วย
    • การนำบทความแบบนี้ขึ้นเว็บเป็นท่าทีที่ถ่อมตัวและซื่อสัตย์มาก
      สุดท้ายถ้ามีใครหยิบ htmx ไปใช้แล้วโกรธเพราะมันไม่ตอบโจทย์ของตัวเอง ตอนนี้ก็มีเอกสารให้ชี้ไปหาได้แล้ว
    • มีลิงก์อยู่ใต้หัวข้อ “On The Other Hand…” ใน https://htmx.org/essays/
    • ตอนแรกผมคาดว่าจะเป็น rant หรือบทความเหน็บแนมเล็ก ๆ แต่จริง ๆ แล้วดีใจที่มันเป็นบทความที่ดีและมีประเด็นดี ๆ
      ผมใช้ htmx ในโปรเจกต์ของตัวเองอยู่หลายตัว และมันก็ดีทีเดียว
      บทความแบบนี้กลับทำให้ผมมั่นใจในการใช้ htmx มากขึ้น เพราะมันแสดงให้เห็นค่อนข้างหาได้ยากว่า htmx ทำได้ดีตรงไหนและยังขาดตรงไหน

  • ประเด็นที่สามให้ความรู้สึกน่ากลัว
    ทำให้นึกภาพโลกที่บริษัทต่าง ๆ จ่ายเงินเพื่อให้ framework ของตัวเองถูก oversample ในชุดข้อมูลฝึกโมเดล แล้วใช้สิ่งนั้นไปขายสัญญา
    คล้ายกับ การทำ Search Engine Optimization ที่ถูก baked in อยู่ในเครื่องมือพัฒนา