แนะนำ HN: HTMX Playground ที่สร้างขึ้น 100% บนเบราว์เซอร์

 (lassebomh.github.io)
6 คะแนน โดย GN⁺ 2024-01-09 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นโค้ดแซนด์บ็อกซ์ที่ให้เริ่ม ทดลองใช้ HTMX ในเบราว์เซอร์ ได้ทันทีโดยไม่ต้องติดตั้งหรือตั้งค่าในเครื่อง
  • จัดการ เอนด์พอยต์และการเรนเดอร์เทมเพลต ใน server.js และคำขอของ HTMX จะถูกดักจับโดยม็อกเซิร์ฟเวอร์ภายในเบราว์เซอร์
  • การจัดการคำขอและรูปแบบเทมเพลตคุ้นเคยสำหรับผู้ใช้ Django และยังนำไปใช้ทดลองไลบรารีอื่นนอกเหนือจาก HTMX ได้
  • การแชร์ทำได้โดยส่งออกผ่าน “Copy as JSON” แล้วนำ Gist raw URL ไปใส่ใน “Load Playground”
  • ควรระวังว่าไม่มีการนำทางระหว่างหน้า รองรับมือถืออย่างจำกัด และการโหลด iframe เริ่มต้นอาจทำให้การอัปเดตสถานะใน on.get("/") สูญหาย

แซนด์บ็อกซ์ HTMX ที่ทำงานอยู่ภายในเบราว์เซอร์

  • HTMX Playground เป็นโค้ดแซนด์บ็อกซ์แบบง่ายที่ให้ ทดลองใช้ HTMX ได้โดยไม่ต้องติดตั้ง
  • มีตัวอย่างที่ดัดแปลงมาจาก htmx.org examples
  • สามารถเขียนโค้ดด้วยโฟลว์คล้ายแบ็กเอนด์ได้ภายในเบราว์เซอร์
    • กำหนด เอนด์พอยต์ ภายใน server.js
    • เรนเดอร์เทมเพลตได้โดยตรง
    • มี ม็อกเซิร์ฟเวอร์ ที่ทำหน้าที่ดักจับคำขอที่ออกจาก HTMX
  • การจัดการคำขอและเทมเพลตเอนจินมีรูปแบบที่ผู้ใช้ Django จะคุ้นเคย
  • ตัวโปรเจ็กต์ไม่ได้จำกัดอยู่แค่ HTMX จึงสามารถลองใช้ไลบรารีอื่นได้ด้วย
  • โค้ดเผยแพร่อยู่บน GitHub

วิธีบันทึก·แชร์ และข้อจำกัดที่ทราบ

  • การบันทึกและการแชร์

    • กด “Copy as JSON” ที่มุมขวาบนเพื่อคัดลอกเนื้อหา
    • อัปโหลดเนื้อหาที่คัดลอกไปยัง Gist
    • ป้อน raw URL ลงใน “Load Playground”
    • เมื่อ URL ของหน้าอัปเดตแล้วก็สามารถแชร์ได้

  • ข้อจำกัด

    • ไม่มี การนำทางระหว่างหน้า
    • การรองรับมือถือ มีอย่างจำกัด
    • server.js สามารถมีสถานะได้เหมือนตัวอย่าง Click to Edit
    • หากอัปเดตสถานะในวิว on.get("/") การอัปเดตนั้นอาจหายไป
      • เพราะการโหลดหน้าเริ่มต้นจะถูกดึงใน iframe แยกก่อนที่ iframe บนหน้าจอจะถูกอัปเดต

  • ไลบรารีที่ใช้

    • Svelte
    • Ace
    • PollyJS
    • Nunjucks

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

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

 
GN⁺ 2024-01-09
ความคิดเห็นจาก Hacker News

  • ผมเป็นคนสร้าง htmx เอง รู้สึกขอบคุณมากที่ทำสิ่งนี้ขึ้นมา และคิดว่ามันเจ๋งมาก

    • อยากรู้ว่ามีวิธีใช้ HTMX โดยเปลี่ยนฝั่งเซิร์ฟเวอร์ให้น้อยที่สุดไหม
      ในหน้าที่มีอยู่เดิม เมื่อกรอกฟอร์มแล้วส่ง คำตอบจะกลับมาเป็นทั้งหน้า ถ้าบอก htmx ได้ว่า “ทั้งหน้าจะถูกส่งกลับมา แต่ให้รีเฟรชเฉพาะ #my-form” ก็น่าจะไม่ต้องใส่เงื่อนไขในเซิร์ฟเวอร์แบบ “ถ้าเป็นคำขอ htmx”
      น่าจะดีสำหรับคนที่อยากให้ไซต์ทำงานได้แม้ไม่มี JavaScript และยังใช้ backend endpoint เดียวจัดการหลายฟีเจอร์ได้ เช่น คอมเมนต์ สมัครรับอีเมล หรือปุ่มไลก์
    • อยากรู้ว่าเคยได้ยิน Phoenix LiveView ไหม และเป็นแนวคิดคล้ายกับ htmx หรือเปล่า

  • เคยคิดจะลองใช้ HTMX อย่างจริงจัง แต่กังวลว่า กลุ่มนักพัฒนา มีขนาดเล็กเกินไป ทำให้จ้างคนยาก
    ผมคุ้นเคยกับเฟรมเวิร์กปิดที่คล้าย Thymeleaf อย่าง isml ของ Intershop และช่วงหลังตั้งใจจะย้ายไปใช้สแตก frontend ด้วย Angular เพราะจ้าง frontend developer เฉพาะทางได้ง่ายกว่า
    แนวทางแบบ htmx อาจซับซ้อนขึ้นได้ และนักพัฒนาไม่อยากสู้กับสัตว์ประหลาดสปาเกตตี อีกทั้งถ้า frontend ทำได้แค่สร้าง HTML แล้ว backend ต้องเอาทุกอย่างมาต่อเข้าด้วยกัน backend developer ก็อาจกลายเป็นคอขวด
    อยากรู้ว่า HTMX ได้คำนึงถึงกับดักเหล่านี้ไหม และรับมืออย่างไร

    • htmx เรียนรู้ได้ค่อนข้างเป็นธรรมชาติมาก ถ้าไม่ใช่คนจบ bootcamp เขียนโค้ดที่เรียนมาแต่ React นักพัฒนาที่รู้หัวข้อวิทยาการคอมพิวเตอร์จริง ๆ น่าจะทำงานได้อย่างมีประสิทธิภาพภายใน ไม่เกินหนึ่งสัปดาห์
    • วิธีรับมือนั้นง่ายมาก HTMX ใช้เวลาเรียน ไม่ถึงครึ่งวัน และมีแนวโน้มว่าจะเร็วกว่านั้นด้วย
      แต่ HTMX ไม่ได้แก้ได้ทุกสถานการณ์ และบางครั้งก็จำเป็นต้องใช้ single-page app ที่ใช้ JavaScript framework
    • พูดถึง Angular แล้วบอกว่า htmx อาจซับซ้อนขึ้นได้นั้นน่าสนใจ เหมือนจะมีมุมมองต่อความซับซ้อนต่างกัน
      เฟรมเวิร์กอย่าง Angular ให้โครงสร้างก็จริง แต่ความซับซ้อนยังอยู่เหมือนเดิม และอาจมากกว่าด้วยซ้ำ
      สุดท้ายสิ่งที่ต้องการคือ frontend developer ที่รู้จัก เว็บสแตก อย่าง JavaScript, CSS, HTML และ browser API เป็นอย่างดี คนแบบนั้นจะเลือกเครื่องมือและเฟรมเวิร์กให้เหมาะกับงานได้ และเรียน HTMX ได้เร็วอยู่แล้ว
    • ไม่มีอะไรโน้มน้าวใจได้เท่าความสำเร็จ และ htmx ได้อันดับ 2 ในหมวดเฟรมเวิร์กของ JS Rising Stars ปี 2023
      https://risingstars.js.org/2023/en#section-framework
      อยู่ถัดจาก React และนำหน้า Vue, Svelte, Angular ดังนั้นในแง่นี้อนาคตดูดี แต่คาดว่าเมื่อกระแสตื่นเต้นช่วงแรกซาลง อันดับก็น่าจะลดลง
      htmx ค่อนข้างเรียบง่าย นักพัฒนาเว็บส่วนใหญ่น่าจะเรียนได้ในเวลาประมาณหนึ่งวัน แต่รูปแบบการพัฒนาจะผลักองค์กรไปทาง พาราไดม์แบบ full-stack ที่นักพัฒนาเป็นเจ้าของฟีเจอร์ทั้งชุด จึงต้องเปลี่ยนวิธีคิดไม่ใช่แค่นักพัฒนา แต่รวมถึง PM และสถาปนิกด้วย
      มีหนังสือออนไลน์ฟรีด้วย: https://hypermedia.systems
      นอกจากเอกสาร (https://htmx.org/docs ใช้เวลาอ่านประมาณหนึ่งชั่วโมง) ยังมีบทความที่พูดถึงประเด็นเชิงปรัชญาและเชิงปฏิบัติของ htmx และ hypermedia โดยรวม: https://htmx.org/essays
      htmx มีไอเดียพื้นฐานน้อยมาก และพยายามทำให้ “ขยายได้” เช่น พฤติกรรมที่มีประโยชน์อย่าง lazy loading ก็ทำได้ด้วย attribute สองตัว: https://htmx.org/examples/lazy-load
      ขณะเดียวกันก็มี hook และฟีเจอร์ที่ลึกกว่า เช่น event หรือ event filter ดังนั้นถ้าลงลึกขึ้นก็ทำพฤติกรรมที่ต้องการได้
      โค้ดสปาเกตตีเป็นความเสี่ยงที่มีอยู่เสมอในการพัฒนาซอฟต์แวร์ทุกแบบ และโดยส่วนตัวไม่มั่นใจว่าไลบรารี single-page app จะป้องกันสปาเกตตีได้
      ใน htmx ควรเน้นความพยายามไปที่ backend และแยกแอปพลิเคชันให้ดีด้วยเครื่องมือที่สภาพแวดล้อมฝั่งเซิร์ฟเวอร์มีให้
      htmx เปิดให้เลือกเทคโนโลยีเซิร์ฟเวอร์ใดก็ได้ จึงมีตัวเลือกและพาราไดม์ในการจัดระเบียบ application logic มากกว่า single-page app ที่มีแอป JavaScript/TypeScript ขนาดใหญ่อยู่แล้วใน frontend จนผลักให้ backend ต้องไปทางนั้นด้วย
      ผมพยายามสรุปไว้ที่นี่ด้วยว่า htmx เป็นตัวเลือกที่ดีสำหรับแอปพลิเคชันแบบไหน: https://htmx.org/essays/when-to-use-hypermedia/
      htmx เป็นเครื่องมือที่ดีในหลายกรณี แต่ก็เป็นแค่เครื่องมือ และไม่ใช่คำตอบครอบจักรวาลของการพัฒนาเว็บ
    • เรื่องการจ้างงานควรดู ทักษะ backend มากกว่าประวัติ HTMX
      เหมือนจ้าง backend developer ที่ทำ frontend ได้นิดหน่อย จึงไม่จำเป็นต้องมี HTMX ในเรซูเม่ แค่มีพื้นฐานอย่าง JavaScript ก็พอ
      นักพัฒนาเว็บส่วนใหญ่เข้าเงื่อนไขนี้อยู่แล้ว

  • ผมใช้ MapLibre ร่วมกับ Django และ htmx มาสักพัก น่าจะลองอัปโหลดตัวอย่างเพื่อแชร์กับคนอื่นดู

    • ผมก็ทำคล้าย ๆ กันที่ https://ratethispad.com และขั้นตอนการทำก็ค่อนข้างสนุก
      ถึงจะไม่มีใครใช้เลย แต่ก็อยากดูโปรเจกต์นั้นเหมือนกัน
    • ไม่มีอะไรที่แชร์แบบสาธารณะได้ แต่ผมทำงานด้วย Django, htmx, SQLAlchemy, Plotly มา และรู้สึกว่าค่อนข้างแข็งแรงดี
    • ถ้าอยากย้ายตัวอย่างทางการมาเพิ่มอีก ให้เปิด issue พร้อมลิงก์ได้ แล้วจะเพิ่มเข้า repository ให้

  • เข้าใจว่า Monaco ถูกออกแบบมาให้ไม่ทำงานบนมือถือ เลยใช้ Ace บนมือถือ
    อย่างน้อยตอนที่ผมเช็ก GitHub issue ครั้งล่าสุดก็เป็นแบบนั้น
    [0] https://github.com/Microsoft/monaco-editor/issues/246

    • Monaco ทำงานบนมือถือได้ดีนะ ผมเพิ่งลองใช้ที่ https://tsdiagram.com

  • อันนี้รองรับ ActiveX ด้วยไหม?

    • เศร้าที่ตัวเองแก่พอจะเข้าใจมุกนี้
    • นึกถึง HP Quality Center ขึ้นมาเลย
      เวอร์ชันแรก ๆ UI ทั้งหมดเป็น ActiveX และยังจำได้ว่ามีแถบความคืบหน้าเพียบตอนติดตั้ง DLL

  • ใช้ Service Worker ทำอะไรแบบนี้ แล้วเปิดหลายหน้าในแท็บอื่น ๆ ให้ท่องดูได้ก็น่าจะทำได้
    ไม่น่าจะยากขนาดนั้น และการสร้างหน้าจะใช้ JavaScript ล้วน ๆ หรืออะไรก็ได้ที่ผู้ใช้ต้องการก็ได้

  • ทำด้วย Svelte เหรอ แล้วพวก MPA purist กับคราดเหล็กไปไหนกันหมด?

    • แม้จะเป็น MPA purist แต่ก็ยอมรับเต็มที่ว่ามีแอปพลิเคชันบางประเภทที่ single-page app เป็นทางเลือกที่ดีที่สุด

  • ชอบแนวคิดของ htmx เลยเริ่มอ่านหนังสือวันนี้ แต่ทุกครั้งที่คิดว่าสักวันต้องรองรับ แอปมือถือแบบเนทีฟ ด้วย ก็ทำให้ลังเลที่จะใช้
    กรณีนั้นคงต้องเขียนใหม่ไม่ใช่แค่ฟรอนต์เอนด์ แต่รวมถึงแบ็กเอนด์ส่วนใหญ่ด้วย
    รู้จัก hyperview.org อยู่ แต่สำหรับ use case ที่สนใจ แอป React Native ยังไม่เพียงพอ

  • สงสัยว่ามีใครทำแอปออฟไลน์ด้วย เซิร์ฟเวอร์เสมือน ที่นิยามไว้ใน Service Worker และรูปแบบ request-response แบบ HTML/HTMX บ้างไหม

    • เป็นคำถามที่ดี
      ชอบ htmx แต่ในสถานการณ์ที่ต้องทำงานแบบออฟไลน์ก็ใช้ไม่ได้
      ถ้ารันโค้ดเซิร์ฟเวอร์ใน worker ได้ตรง ๆ ก็น่าจะเป็นแฮ็กที่ยอดเยี่ยม
    • กำลังทำเซิร์ฟเวอร์/แบ็กเอนด์สำหรับ htmx ที่รันเป็น local service ข้าง ๆ เบราว์เซอร์
      ในทางทฤษฎี ถ้าเป็น server stack ที่โฮสต์เองได้ อะไรก็เป็นไปได้
      เป้าหมายคือทำ single binary ที่ไม่มี dependency ต่อบริการภายนอก และใช้ Go
      คอมโพเนนต์อย่าง local service ที่อัปเดตตัวเองได้ และฐานข้อมูลแบบ replication ก็เตรียมไว้ค่อนข้างมากแล้ว อีกทั้ง cross-compile ไปยังหลายระบบปฏิบัติการและสถาปัตยกรรมได้ง่าย
      ในฐานะทางเลือกแทนการยัดทุกอย่างลงเบราว์เซอร์ ถ้าสมมติว่ารันโปรเซสแยกได้ แนวทางนี้ก็ดูสมเหตุสมผลทีเดียว
      แต่ถ้า Go มีการจัดการสิทธิ์แบบ Deno ก็คงดี
    • มีตัวอย่างจริง: https://github.com/jon49/htmx-todomvc
      ใช้แพตเทิร์นนี้กับแอปส่วนตัวทั้งหมด เพียงแต่ใช้ไลบรารีเล็ก ๆ ที่ทำเองซึ่งคล้าย htmx
      การเปลี่ยนไปใช้ HTMX ก็คงไม่ยากนัก

  • สงสัยว่าการย้าย HATEOAS ไปฝั่งแอปเดสก์ท็อปหรือมือถือจะเป็นไอเดียที่ดีไหม และน่าจะเป็นการทดลองที่สนุกได้

    • ถ้าหมายถึงมือถือแบบเนทีฟ เคยใช้ HATEOAS ในโค้ดเนทีฟราวปี 2013
      มันทำงานได้ดี แต่ไม่ยืดหยุ่นเท่าเว็บ และต้องพัฒนาหน้าจอแต่ละหน้าที่ลิงก์ถึงได้แบบ black box อย่างเข้มงวด
      ตัวการทดลองเองก็น่าสนุก แต่ไม่แน่ใจว่าคุ้มแค่ไหนสำหรับการใช้ในโปรดักชัน
    • มอง HATEOAS เป็นแค่แนวคิดเชิงนามธรรม และไม่เคยรู้สึกกับ UI จริงว่า “ปฏิสัมพันธ์ของผู้ใช้ดีขึ้นจริง ๆ”
      REST เป็นเรื่องน่ายินดีเพราะช่วยทำให้เหล่าสัตว์ประหลาด SOAP เรียบง่ายลง แต่ก็มาพร้อมความยึดมั่นแบบลัทธิไม่น้อย
      เข้าใจจุดประสงค์พื้นฐานของ REST เพราะมันปรับสถาปัตยกรรมแนวคิด ข้อมูล และบริการให้เป็นธรรมชาติกับผู้ใช้
      แต่ HATEOAS ดูเหมือนเป็นผลลัพธ์ของการอยากได้ความยึดมั่นแบบลัทธิและการวางท่ามากขึ้นในประชุมสถาปัตยกรรม มากกว่าจะโฟกัสว่าประสบการณ์ผู้ใช้ดีขึ้นเพราะโมเดลหรือไม่
      สงสัยว่ามีตัวอย่าง UI ที่แสดงให้เห็นไหมว่าทำไมควรยึด HATEOAS เป็นหลักการพื้นฐาน
      โดยพื้นฐานแล้วแต่ละหน้าจะมีลิงก์ไปยัง “สิ่งถัดไปที่ต้องทำ” และ HATEOAS ก็ให้ความรู้สึกเหมือนวิธีที่ดูฉูดฉาดในการนำโมเดลสถานะแบบนั้นไปใส่ในการเรียกบริการ REST
    • สงสัยตั้งแต่แรกว่า HATEOAS เป็นไอเดียที่ดีหรือเปล่า
    • มีอยู่ที่นี่: https://hyperview.org/