- htmx ได้รับเลือกให้เข้าร่วม GitHub Open Source Accelerator รุ่นแรก ทำให้มีโอกาสร่วมงานและเรียนรู้จากโปรเจกต์โอเพนซอร์สที่เติบโตเต็มที่แล้ว
- การเข้าร่วมครั้งนี้เป็นโอกาสในการทำให้แนวทางของ hypermedia และ htmx เป็นที่รู้จักในชุมชนนักพัฒนาที่กว้างขึ้น
- htmx มีแผนจะใช้ช่วงเวลาของ Accelerator เพื่อเริ่มงานบน htmx 2.0
- การเรียนรู้วิธีทำให้งานบน htmx กลายเป็น งานเต็มเวลา ยังคงเป็นโจทย์สำคัญเพื่อให้โปรเจกต์สามารถดูแลรักษาและพัฒนาต่อไปได้
- โปรเจกต์ที่ได้รับเลือกร่วมกันครอบคลุมหลากหลายด้านของโอเพนซอร์ส เช่น ความปลอดภัย เอกสาร การยืนยันตัวตน การแจ้งเตือน และ CMS แสดงให้เห็นถึงขอบเขตของ GitHub Accelerator
โอกาสที่ htmx ได้รับ
- htmx ได้รับเลือกให้เข้าร่วมคลาสแรกของ GitHub Open Source Accelerator
- การได้รับเลือกครั้งนี้ทำให้สามารถเรียนรู้และร่วมงานกับ นักพัฒนาและโปรเจกต์โอเพนซอร์ส ที่ประสบความสำเร็จได้
- htmx มองว่ากระบวนการนี้จะช่วยเผยแพร่ hypermedia และ htmx ให้เป็นที่รู้จักมากขึ้น
- เป้าหมายหลักระหว่างเข้าร่วม Accelerator มี 2 ข้อ
- เริ่มงานบน htmx 2.0
- เรียนรู้วิธีทำให้งานบน htmx กลายเป็น งานเต็มเวลา
โปรเจกต์โอเพนซอร์สที่ได้รับเลือกร่วมกัน
- BoxyHQ: ชุดผลิตภัณฑ์ API สำหรับความปลอดภัยและความเป็นส่วนตัว ช่วยให้ทีมวิศวกรรมสร้างและปรับใช้แอปพลิเคชันคลาวด์ที่เป็นไปตามข้อกำหนดได้เร็วขึ้น
- Cal.com: เครื่องมือจัดตารางเวลาที่ช่วยนัดประชุมโดยไม่ต้องส่งอีเมลโต้ตอบซ้ำไปมา
- Crowd.dev: ช่วยรวมศูนย์ข้อมูลชุมชน ผลิตภัณฑ์ และลูกค้า เพื่อระบุว่าบริษัทใดบ้างที่เข้ามามีส่วนร่วมกับโปรเจกต์โอเพนซอร์ส
- Documenso: ทางเลือกโอเพนซอร์สแทน DocuSign โดยมีเป้าหมายสร้างความไว้วางใจผ่านการโฮสต์เองและการตรวจสอบการทำงานภายในได้
- Erxes: ทางเลือกโอเพนซอร์สแทน HubSpot ที่ช่วยสร้างประสบการณ์ให้เหมาะกับธุรกิจหลากหลายประเภทผ่าน XOS เดียว
- Formbricks: สามารถส่งแบบสำรวจไปยังกลุ่มผู้ใช้ที่แบ่งกลุ่มอย่างละเอียด ณ จุดใดก็ได้ใน user journey และเก็บอินไซต์ได้มากขึ้นสูงสุด 6 เท่าด้วยแบบสำรวจขนาดย่อยแบบเจาะกลุ่มเป้าหมาย
- Forward Email: บริการส่งต่ออีเมลฟรีสำหรับโดเมนแบบกำหนดเอง เป็นบริการอีเมลที่ครีเอเตอร์ นักพัฒนา และบริษัทใช้งานมานานกว่า 6 ปี
- GitWonk: เครื่องมือทำเอกสารเชิงเทคนิคแบบโอเพนซอร์สที่ออกแบบและสร้างขึ้นโดยเน้นประสบการณ์นักพัฒนา
- Hanko: เครื่องมือยืนยันตัวตนและจัดการผู้ใช้แบบโอเพนซอร์สสำหรับยุค passkey สามารถผสานเข้ากับเว็บและแอปมือถือได้ในไม่กี่นาที
- Infisical: แพลตฟอร์มโอเพนซอร์สแบบเข้ารหัสจากต้นทางถึงปลายทางสำหรับจัดการ secrets และการตั้งค่าข้ามทีม อุปกรณ์ และโครงสร้างพื้นฐานอย่างปลอดภัย
- Novu: โครงสร้างพื้นฐานการแจ้งเตือนแบบโอเพนซอร์สสำหรับนักพัฒนา ให้คอมโพเนนต์และ API สำหรับจัดการทุกช่องทางการสื่อสารไว้ในที่เดียว
- OpenBB: ทำให้งานวิจัยการลงทุนเข้าถึงได้อย่างเท่าเทียมผ่านระบบนิเวศการเงินแบบโอเพนซอร์ส และสามารถทำวิจัยการลงทุนได้จากทุกที่ด้วย OpenBB Terminal
- Sniffnet: เครื่องมือมอนิเตอร์เครือข่ายที่ช่วยให้ติดตามทราฟฟิกอินเทอร์เน็ตได้ง่าย
- Typebot: มีบล็อกสำหรับสร้างประสบการณ์แชทที่เป็นเอกลักษณ์ และสามารถฝังในส่วนใดก็ได้ของแอปเพื่อเก็บผลลัพธ์
- Webiny: CMS แบบ serverless ระดับองค์กรโอเพนซอร์สที่เน้นการเป็นเจ้าของข้อมูล การขยายระบบ และการปรับแต่ง
- Webstudio: ได้รับเลือกในฐานะทางเลือกโอเพนซอร์สแทน Webflow
1 ความคิดเห็น
ความคิดเห็นจาก Hacker News
สวัสดีครับ อย่างที่หลายคนทราบ ผมเป็นคนสร้าง htmx และสามารถตอบคำถามที่เกี่ยวข้องได้
htmx ได้รับความนิยมเพิ่มขึ้นอย่างมากจากวิดีโอของ fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) และซีรีส์วิดีโอของ ThePrimeagen สตรีมเมอร์ Twitch ชื่อดัง
สำหรับผู้อ่าน HN รวมบทความที่ผมเขียนเกี่ยวกับ htmx และไฮเปอร์มีเดียโดยรวม https://htmx.org/essays ก็น่าจะน่าสนใจ และหนังสือเกี่ยวกับไฮเปอร์มีเดีย, htmx และ Hyperview ซึ่งเป็นไฮเปอร์มีเดียสำหรับมือถือ ที่ผมเพิ่งออกกับผู้เขียนอีกหลายคน https://hypermedia.systems ก็น่าอ่านเช่นกัน
แน่นอนว่าผมเป็นแฟน htmx แต่แก่นที่ลึกกว่านั้นผมมองว่าคือ ไฮเปอร์มีเดีย เป็นแนวคิดที่ควรค่าแก่การสำรวจ แม้คุณจะไม่มีแผนใช้ htmx ในการพัฒนาประจำวันก็ตาม
ยังมีไลบรารีแนวไฮเปอร์มีเดียที่ยอดเยี่ยมอีกมาก เช่น Hotwire ของ 37signals หรือ https://unpoly.com ซึ่งผมชอบรองจาก htmx
ช่วย นักพัฒนา Django ได้มาก
ตอนทำฟีเจอร์กดไลก์บทความเมื่อไม่กี่เดือนก่อน ก่อนใช้ htmx ผมต้องใช้ jQuery เรียก JSON API server แล้วอัปเดตจำนวนไลก์ แต่พอใช้ HTMX ก็รู้สึกเหมือนเขียน HTML ธรรมดาๆ ร่วมกับลอจิกของ Django
เป็นหนึ่งในสิ่งที่ดีที่สุดที่ผมค้นพบจนถึงตอนนี้ และ การจัดการฟอร์ม ก็ง่ายมาก HTMX ช่วยปรับปรุงทั้งประสบการณ์ผู้ใช้และประสบการณ์นักพัฒนาอย่างมาก
เมื่อคิดว่าแม้แต่โปรเจกต์ที่ได้รับความนิยมมากๆ โดยปกติโค้ดส่วนใหญ่ก็ยังมาจากผู้ร่วมพัฒนาเดิม นี่จึงเป็นสัญญาณการเติบโตที่แข็งแกร่ง
https://devboard.gitsense.com/bigskysoftware/htmx
หมายเหตุ เครื่องมือนี้ผมเป็นคนสร้างเอง
ลองดูเว็บไซต์และตัวอย่างเล็กน้อยแล้ว ดูเหมือนจะเน้นวิธีที่ HTTP response จากเซิร์ฟเวอร์มีมาร์กอัปครบถ้วน และใช้สิ่งนั้นอัปเดตสถานะฝั่งไคลเอนต์ กล่าวคือให้น้ำหนักกับการเขียน DOM ใหม่
ผมสงสัยว่า htmx มีจุดผ่อนปรนให้กับทริกเกอร์เฉพาะฝั่งไคลเอนต์ หรือคอนเทนต์ที่สร้างจากฝั่งไคลเอนต์ด้วยหรือไม่
จุดแข็งของ client framework ที่เน้น JavaScript ในปัจจุบันคือสามารถโยนงานให้เบราว์เซอร์ทำได้มากที่สุดเท่าที่เป็นไปได้ เพื่อลดการใช้ข้อมูลและ CPU ของเซิร์ฟเวอร์ ซึ่งในแอปขนาดระดับเว็บถือว่าสร้างความแตกต่างอย่างมาก
ผมอยากรู้ว่า HTMX สามารถตอบโจทย์เป้าหมายทางวิศวกรรมแบบนี้ได้ด้วยหรือไม่ หรือเป็นโปรเจกต์ที่มีวัตถุประสงค์คนละแบบกันโดยสิ้นเชิง ผมเข้าใจว่าไคลเอนต์อย่าง Facebook ไม่ได้มุ่งแนวไฮเปอร์มีเดีย แต่ไม่ว่าอย่างไร การเปรียบเทียบก็คงหลีกเลี่ยงได้ยาก
มันเป็นธรรมชาติ ให้ความรู้สึกเหมือนอธิบายตัวเองได้ และออกแบบมาอย่างดี รู้สึกเหมือนเป็นส่วนขยายตามธรรมชาติของ HTML จริงๆ
สำหรับผม ชิ้นส่วนเดียวที่ขาดไปใน htmx คือ โมเดลคอมโพเนนต์ และสำหรับคนที่มองหาสิ่งนั้น ดูเหมือนจะเข้ากันได้ดีมากกับ Astro[1] Astro ช่วยให้กำหนดและใช้ HTML component ได้โดยไม่มีภาระรันไทม์แบบ Vue หรือ React
[1] http://astro.build
Htmx ทำให้นึกถึง Tailwind เพราะมันสร้างชื่อและค่าของแอตทริบิวต์ที่ไลบรารีหนึ่งตัวอ่านตอนรันไทม์
การไม่ต้องมี frontend build เป็น ข้อดีใหญ่มาก สำหรับนักพัฒนาส่วนใหญ่ที่ไม่อยากยุ่งกับ npm และ webpack และก็ไม่จำเป็นต้องทำเช่นนั้นด้วย
ขีดจำกัดด้านขนาดของหน้าเว็บดูเหมือนจะอยู่ราวๆ แอปหน้าเดียวขนาดเล็ก และถ้ามันใหญ่เกินไป ก็น่าจะแยกออกเป็นแอปหน้าเดียวอีกตัวได้
สิ่งที่นักพัฒนา React/Vue น่าจะรู้สึกขาดเป็นพิเศษคือมุมมองที่ว่ามีออบเจ็กต์เดียวแทนสถานะทั่วทั้งแอป และมีฟังก์ชันหนึ่งที่นิยามแบบเป็นลำดับชั้นในโค้ดเบสของคอมโพเนนต์เพื่อเรนเดอร์มันออกมาเป็น UI
แต่ตัวมุมมองนี้เองก็เป็นภาระหนัก ก่อให้เกิดความเห็นต่างและการเสียพลังทางอารมณ์จำนวนมาก อีกทั้งยังพ่วง frontend build และรูปแบบแปรผันที่สับสนของมันมาด้วย
ผมยังไม่ได้ใช้ แต่เป็นแฟนตัวยงแล้ว
ถือเป็นข่าวดีครับ
ตลอด 1 ปีที่ผ่านมา ผมใช้ htmx แล้วได้ผลลัพธ์ที่ดีและเป็นประสบการณ์ที่คุ้มค่า โดยเฉพาะตอนทำ server-side rendering ด้วย hiccup ใน Clojure นั้นยอดเยี่ยมมาก
พอเข้าใจ htmx แล้ว จะค่อนข้างทึ่งว่ามันเรียบง่ายและยืดหยุ่นแค่ไหน ถึงขั้นไม่น่าเชื่อว่า HTML ทำไมถึงไม่ได้วิวัฒน์มาเป็นไฮเปอร์มีเดียแบบนี้ตั้งแต่แรก
มันทำให้เห็นชัดมากว่าเว็บดีเวลลอปเมนต์ควรวิวัฒน์มาแบบนี้ตั้งแต่ต้น หวังว่าสักวันหนึ่งสิ่งที่ htmx กำลังทำด้วย JavaScript จะถูกฝังเข้าไปใน HTML และไคลเอนต์เบราว์เซอร์โดยตรง
ถ้าคุณเข้าใจ htmx ผิดว่าเป็นแค่ลูกหลานของ Angular หรือไม่เข้าใจความหมายของการพัฒนาสถาปัตยกรรมไฮเปอร์มีเดีย ผมแนะนำอย่างยิ่งให้อ่านบทความดี ๆ บนไซต์นี้ แล้วคุณจะเข้าใจว่า REST คืออะไร และทำไม HATEOAS ของจริงจึงสำคัญ: https://htmx.org/essays/
มีหนังสือฟรีด้วย: https://hypermedia.systems/
เมื่อ 10–15 ปีก่อน แทนที่เราจะขยายและทำให้ไฮเปอร์มีเดียซึ่งเป็นแนวคิดใหม่และทรงพลังของเว็บยุคแรกให้สมบูรณ์ขึ้น เรากลับเดินผิดทางอย่างแพง ด้วยการพยายามสร้างไคลเอนต์หนา ๆ ขึ้นมาใหม่บนเว็บผ่านสถาปัตยกรรม JSON API
ผมดีใจที่ htmx มีอยู่และเหมาะกับหลายคน แต่ในงานของผม มันมักไม่ใช่ตัวเลือกที่ดีที่สุด และนั่นก็ไม่เป็นไร
เป็นเรื่องยอดเยี่ยมที่เว็บสามารถเติบโตได้หลากหลายรูปแบบ และเราไม่จำเป็นต้องมองว่าเว็บควรวิวัฒน์ไปในทิศทางใดทิศทางหนึ่งเท่านั้น
ความผิดพลาดครั้งใหญ่ที่สุดของเว็บดีเวลลอปเมนต์ในราว 10 ปีที่ผ่านมา คือความคิดที่ว่าต้องมี คำตอบเดียวที่ถูกต้อง
ไม่ว่าจะสร้าง Gmail ตัวถัดไปหรือบล็อกแบบ static แนวคาร์โกคัลต์ในวงการก็มักบอกว่าทุกอย่างต้องทำด้วยวิธีเดียวกัน แต่ถ้าคิดตามสามัญสำนึกแล้วมันไม่ใช่
มันน่าจะเพียงพอสำหรับเว็บมากกว่า 98% ส่วนอีก 1.9% ก็ใช้ไลบรารี JavaScript เล็ก ๆ ได้
ที่เหลืออีก 0.1% เท่านั้นที่เป็นเว็บแอป JavaScript ล้วน
ดูเหมือนเป็นแนวคิดเดียวกัน คือโปรยแอตทริบิวต์ลงใน HTML เล็กน้อยเพื่อทำให้กรณีง่าย ๆ กลายเป็นแบบไดนามิก
เฟรมเวิร์กจำนวนมากอย่าง Angular 1, Vue ฯลฯ ก็เริ่มต้นแบบนี้ และหลังจากได้รับความนิยมระดับหนึ่ง ก็เติบโตเป็นเฟรมเวิร์ก single-page app เต็มรูปแบบ เพราะมีความต้องการจริงสำหรับเคสที่ยากขึ้น
ถ้าต้องเลือกเฟรมเวิร์กที่ “คล้าย Angular 1” ผมจะเลือกตัวที่ระบุขอบเขตไว้ชัดเจนในเอกสาร และให้เส้นทางที่ชัดเจนว่าเมื่อจำเป็นต้องก้าวข้ามขอบเขตนั้น ควรไปใช้เฟรมเวิร์ก single-page app ที่ mature แล้วอย่างไร ถ้าใครรู้จักเฟรมเวิร์กแบบนั้น ช่วยแชร์ด้วยครับ
ผมเป็นแฟนของ HTMX มาตั้งแต่ “ก่อนที่มันจะเท่”
ผมดีใจมากกับความสนใจและความสำเร็จในช่วงหลัง ๆ และก็สนุกไม่น้อยกับคำล้อเลียนปนขำกับแรงต้านจากฝั่งฟรอนต์เอนด์ที่เชื่อว่าเว็บถูกประดิษฐ์ขึ้นในปี 2013 และพวกเขาเป็นคนสร้างเมืองนั้นขึ้นมา
ผมมีอคติมาตั้งแต่ยุค Backbone.js แล้ว ตอนนั้นผมก็เข้าใจความเจ็บปวดอยู่บ้าง แต่ก็ยังค่อนข้างกังขา
หลังจากนั้น React ก็ออกมา และเมื่อคนหนุ่มสาวไฟแรงเริ่มทำเว็บไซต์แสนเรียบง่าย 5 หน้าให้กลายเป็น เครื่องรูบ โกลด์เบิร์ก ของเฟรมเวิร์กฟรอนต์เอนด์ ผมก็ถอนชิปเทคโนโลยีออกมาเป็นเงินสดและไม่แตะของพวกนั้นอีก
รายละเอียดการใช้งานจริงค่อนข้างต่างกัน แต่แนวคิดเรื่อง แอปพลิเคชันที่อิงไฮเปอร์มีเดีย เป็นแกนกลางของทุกอย่างที่เราทำ
น่าเสียดายที่ในระยะยาวมันไม่ได้ชนะใจผู้คน และการพัฒนาที่ขับเคลื่อนด้วยบล็อก หรือพูดอีกอย่างคือคาร์โกคัลต์ ก็เข้ามาแทนที่ความพยายามของเรา
ตอนนี้พอเห็นว่า HTMX ดูจะได้รับความนิยมเพิ่มขึ้น ก็รู้สึกเหมือนได้รับการชดเชยอยู่บ้าง ดีที่ได้เห็นว่าไม่ใช่แค่พวกเราที่คิดด้วยแนวคิดแบบนี้
แน่นอนว่า ถ้าแนวคิดมันแข็งแรง ก็อาจหมายความว่าผมเองทำได้ไม่ดีพอในการลงมือจริง ดังนั้นอาจไม่ควรดีใจมากเกินไปก็ได้
ผมเคยได้ยินว่าวงดนตรีขายกีตาร์แล้วซื้อเทิร์นเทเบิล
ผมเคยได้ยินว่าเขียน HTTP endpoint ใหม่ให้ส่งคืน JSON แล้วนั่นคือ REST
ผมเคยได้ยินว่าวงดนตรีขายเทิร์นเทเบิลแล้วซื้อกีตาร์
ผมเคยได้ยินว่าเขียน HTTP endpoint ใหม่ให้ส่งคืนชิ้นส่วน HTML จากเทมเพลต แล้วนั่นคือ HATEOAS
ผมกำลังเสียความรู้สึกเดิม ๆ ไป ได้มันกลับมา เสียไป แล้วได้กลับมาอีก
เพียงแต่ Backbone ค่อนข้างหลวม และก่อน Angular จะออกมาก็ยังไม่ค่อยให้ความรู้สึกแบบองค์กรขนาดใหญ่เท่าไร
อย่างไรก็ตาม เหตุผลที่กระแสเว็บแอปพลิเคชันแบบนี้ได้รับความนิยมรอบตัวผม คือมันแยกแบ็กเอนด์กับฟรอนต์เอนด์ออกจากกัน และแบ็กเอนด์เดียว ซึ่งมักเป็น REST/JSON สามารถเลี้ยงทั้งไคลเอนต์มือถือและเว็บแยกกันได้
นั่นคือเหตุผลที่เราทำ single-page app แต่ดูเหมือนตอนนี้จะถูกลืมไปอีกแล้ว
ในโลกของผม มันสมเหตุสมผลสำหรับแอปที่อยู่หลังหน้าเข้าสู่ระบบ แต่ “พวกเขา” อยากทำแม้แต่ไซต์สาธารณะบนอินเทอร์เน็ตอย่างเว็บช็อปให้เป็น single-page app ด้วย
อันนั้นผมก็เข้าใจ ผมเคยทำเว็บไซต์ด้วย Gatsby อยู่หลายเว็บ การนำทางเร็วอย่างบ้าคลั่งแต่ยังถูกเสิร์ชเอนจินทำดัชนีได้
เพียงแต่ในบางกรณีมันซับซ้อนขึ้นเรื่อย ๆ และมีแม้กระทั่ง React ฝั่งเซิร์ฟเวอร์ออกมา โชคดีที่ผมไม่จำเป็นต้องแตะมัน
อีกด้านหนึ่ง ผมหวังว่า htmx และโดยทั่วไปกว่านั้นคือ ไฮเปอร์มีเดีย จะถูกยอมรับในฐานะเครื่องมือ มันมีประโยชน์ แต่สุดท้ายก็เป็นเพียงเครื่องมือ
ผมหวังว่าคนฝั่งฟรอนต์เอนด์ที่ไม่ได้คิดลึกเรื่องไฮเปอร์มีเดียมาสักพักก็จะยอมรับมันแบบนั้นเช่นกัน
ผมไม่ได้มองว่าสองแนวทางนี้排斥กัน และเห็นด้วยกับแนวคิด Transitional Web Applications ของ Rich Harris คือวิธีที่ผสมสองแนวทางเข้าด้วยกัน
เพียงแต่เส้นแบ่งว่าตรงไหนควรทิ้งไฮเปอร์มีเดียแล้วขยับไปสู่แนวทางฝั่งไคลเอนต์ที่ประณีตกว่านั้น ผมขีดไว้คนละจุดกับเขาเท่านั้น
ผมคิดแบบนั้นแน่นอน
ผมเริ่มจาก Perl ในปี 1996 และผ่านกระแสแทบทุกอย่างมาแล้ว ตั้งแต่ PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL ไปจนถึง NextJS
Htmx ให้ความรู้สึกเหมือนเป็นกิ่งก้านที่แยกออกจากกระแสนั้น และคุ้มค่าที่จะลองคิดดู
Htmx ตั้งคำถามที่ดีว่า “ความซับซ้อนของงานคุณ โดยเนื้อแท้แล้วอยู่ที่เซิร์ฟเวอร์หรืออยู่ที่ไคลเอนต์?”
สำหรับเว็บไซต์ส่วนใหญ่ ความซับซ้อนโดยเนื้อแท้แล้วอยู่ที่เซิร์ฟเวอร์ พวกเราส่วนใหญ่ไม่ได้กำลังสร้าง Figma หรือ Google Sheets เว็บไซต์จำนวนมาก แม้จะมีการโต้ตอบเยอะ ก็เป็นเพียงแอป CRUD ที่มีอินเทอร์เฟซดูดีเท่านั้น
เฟรมเวิร์กอย่าง NextJS พยายามแก้ปัญหาไคลเอนต์ที่ซับซ้อนเกินไปด้วยการย้าย React ไปไว้บนเซิร์ฟเวอร์ แต่หลายครั้งกลับเพิ่มความซับซ้อนมากกว่าลดลง
ถ้าอย่างนั้น การเอา React ออกจากสแต็กน่าจะถูกต้องไม่ใช่หรือ? ถ้าเป็นไคลเอนต์ที่ซับซ้อน ก็ข้าม DOM กับ JavaScript แล้วใช้ canvas กับ WebAssembly ที่คอมไพล์แล้วได้เลย ถ้าเป็นเซิร์ฟเวอร์ที่ซับซ้อน ก็ใช้การอัปเดต DOM แบบละเอียดที่ขับเคลื่อนโดยเซิร์ฟเวอร์ได้
ปัญหาที่เห็นในแนวทางนี้คือ แม้ความซับซ้อนของเว็บไซต์ส่วนใหญ่จะอยู่ที่เซิร์ฟเวอร์ แต่แทบจะมีงานที่ซับซ้อนสูงบางอย่างที่ต้องอยู่บนไคลเอนต์เสมอ เช่น การแก้ไขภาพ การเรียงลำดับ·กรอง·คำนวณแบบเรียลไทม์ การลากและท่าทางสัมผัส เป็นต้น
จำเป็นต้องมี แนวทางแบบไฮบริด แค่เข้ากันได้ยังไม่พอ htmx กับ React สามารถใช้บนเว็บเพจเดียวกันได้ แต่ต้องแยกกันอยู่ สิ่งที่ผมต้องการไม่ใช่การแยกกัน แต่เป็นการผสานรวมในระดับรากฐาน
เฟรมเวิร์กในอุดมคติควรรองรับการอัปเดต DOM แบบละเอียดเชิง reactive พร้อมทั้งผสานอย่างแนบแน่นกับ WebAssembly ที่คอมไพล์แล้วซึ่งรับผิดชอบงานไคลเอนต์ที่ซับซ้อน
ผมอยากเขียนโค้ดทั้งหมดด้วยภาษาที่ทรงพลัง ไม่ใช่ JavaScript ดีบักเกอร์ควรจัดการได้ทั้งเซิร์ฟเวอร์และไคลเอนต์ และความแตกต่างระหว่างทั้งสองควรหายไป มันควรเป็นการพัฒนาแบบ full-stack ที่แท้จริง หรือก็คือ แอปพลิเคชันสแต็กเดียว
Clojure + ClojureScript ดูเหมือนใกล้เคียงกับแอปพลิเคชันสแต็กเดียว แต่ก็เป็นแค่ในระดับผิวเผิน
ถ้า Common Lisp มี killer framework ออกมา แอปพลิเคชันสแต็กเดียวก็น่าจะลงตัวพอดี
แนวทางแบบไฮบริดคือ แนวทาง islands ที่ Astro เสนอ: https://docs.astro.build/en/concepts/islands/
แนวทางนี้เข้ากันได้ดีกับ htmx และเครื่องมือพวกเดียวกัน และในโปรเจกต์ htmx เรากำลังใช้ JavaScript แบบ vanilla ง่าย ๆ แทรกในส่วนที่ต้องมีการโต้ตอบ
สำหรับโปรเจกต์ขนาดเล็ก·กลางและทีมเล็ก ๆ แค่นี้ก็อาจเพียงพอแล้ว การเปิด developer tools แล้วชี้ไปยังส่วนหนึ่งของหน้า จากนั้นดูแค่ HTML กับชิ้นส่วน JS เล็ก ๆ แล้วเข้าใจส่วนนั้นทั้งหมดได้ เป็นอะไรที่สดใหม่จริง ๆ
ไม่ว่าจะเป็นเซิร์ฟเวอร์หรือไคลเอนต์ ก็เขียนโค้ดด้วย C# ในรูปแบบเดียวกัน ตอนโหลดหน้าแรก ทุกอย่างจะเรนเดอร์ฝั่งเซิร์ฟเวอร์ และหลังจากนั้น WebAssembly จะค่อย ๆ รับช่วงต่อ พร้อมเริ่มโหลดโค้ด C# ไปยังไคลเอนต์เพื่อให้การโต้ตอบของ UI ที่ไม่ต้องใช้ข้อมูลจากเซิร์ฟเวอร์ทำได้รวดเร็ว
มันทำงานได้ดี แต่ความท้าทายในตอนนี้คือการลดขนาดไฟล์ WebAssembly ปัจจุบันอยู่ในระดับหลาย MB
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
ยินดีด้วยครับ การสร้างโปรเจกต์เล็ก ๆ ด้วย Htmx สนุกดี แต่สุดท้ายผมต้องใช้ openlayers เยอะ เลยเลือกอย่างอื่น
ไลบรารีแผนที่ขึ้นชื่อว่าใช้ JavaScript ฝั่งไคลเอนต์หนัก และสำหรับงานนั้น Svelte เป็นเครื่องมือที่ดีกว่า
ผมตั้งใจจะกลับมาใช้อีกในโปรเจกต์ Golang ต่อไป และจะคอยติดตามพัฒนาการ
ถ้าแอปต้องการฟรอนต์เอนด์ที่เรียบง่ายหรือซับซ้อนระดับกลาง โดยเฉพาะถ้าคุณใช้ template fragments[0] อยู่แล้ว ผมแนะนำอย่างยิ่งให้ลอง HTMX แม้มาจากโลก JavaScript ก็ยังทำงานด้วยได้สนุกทีเดียว
และคนดูแลบัญชี Twitter[1] ก็ตลกมากจริง ๆ
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
เป็นเรื่องยากที่จะมอง htmx อย่างจริงจังในฐานะเครื่องมือสำหรับสร้างเว็บแอปหรือเว็บไซต์สมัยใหม่ ผมรู้สึกว่ามันทำให้การสร้างฟีเจอร์ที่ผู้ใช้คาดหวังกลายเป็นเรื่องเป็นไปไม่ได้
ตัวอย่างเช่น faceted search ที่กรองวันที่เป็นก่อนหน้า·ระหว่าง·หลัง แต่แสดงตัวกรองเฉพาะเมื่อผู้ใช้ต้องการ หรือฟีเจอร์ที่เปลี่ยนหน้าผลลัพธ์ไปเป็นมุมมองที่วาดบน canvas เช่น คอลัมน์อื่น แผนที่ หรือชาร์ต
บางส่วนอาจทำได้ด้วย htmx แต่เมื่อถึงจุดหนึ่งคุณก็ต้องใช้ JSON อยู่ดี
Angular ก็ทำแบบนี้ได้ และถ้าใช้ของอย่าง SolidJS ก็สร้างได้ค่อนข้างสนุกจริง ๆ
JSON API สามารถนำไปใช้ซ้ำในแอปอื่นได้ แต่ htmx ให้ความรู้สึกเหมือนมีใครสักคนคิดค้น Thymeleaf ขึ้นมาใหม่
ผมก็เคยคิดแบบเดียวกัน แต่วิดีโอนี้ลงรายละเอียดว่าเขาใช้ htmx ทำ faceted search อย่างไร
ส่วนที่สองคงต้องเขียน JavaScript เอง หรือจัดการด้วย hyperscript
ต้องลองสร้างจริงและใช้งานหนัก ๆ ก่อนถึงจะรู้ว่าเป็นวิธีที่ดีหรือไม่ แต่ก็นึกออกชัดเจนว่ามีสถานการณ์ที่เหมาะมากอยู่เหมือนกัน
ประเด็นเรื่อง JSON API นั้นถูกต้อง หากต้องมี API สาธารณะ ก็ควรนำไปประกอบการตัดสินใจ แต่ไม่ใช่ทุกโปรเจกต์จะมีข้อจำกัดแบบนั้น
แม้แต่สมาร์ตโฟนก็ไม่มีปัญหาในการค้นหาตารางระดับพันแถว
ในกรณีแบบนี้ ผมจะใช้ htmx ส่งข้อมูลช่วงกว้างให้ผู้ใช้ แล้วจากนั้นอนุญาตให้ JS ทำการกรองแบบเรียลไทม์ที่ละเอียดขึ้น
ถ้าต้องการให้ค้นหาได้แม้กระทั่งข้อมูลที่ไม่ได้แสดงตั้งแต่แรก ก็ส่งลงมาพร้อมคลาส CSS สำหรับซ่อนไว้ แล้วเมื่อค้นเจอค่อยเอาคลาสนั้นออก
htmx ก็เหมือนเทคโนโลยีอื่น ๆ คือเหมาะมากกับชุดปัญหาบางประเภท ถ้าไม่ฝืนให้มันเล่นท่าที่ทำได้ไม่ดี ก็ไม่มีปัญหา
สิ่งแบบนี้ซับซ้อนพอที่จะต้องมี scripting เต็มรูปแบบในระดับหนึ่ง ซึ่งผมไม่ได้คัดค้านตัวมันเอง
https://htmx.org/essays/hypermedia-friendly-scripting/
ด้วยเส้นทางอาชีพที่พลิกผันไปมาของผม ผมแทบจะข้ามสงครามเฟรมเวิร์ก JavaScript ฝั่งฟรอนต์เอนด์ไปเลย ดังนั้นจึงดีใจที่ได้เห็น HTML แบบเก่าเรียบง่าย กลับมาในเวอร์ชันที่ทรงพลังขึ้น
นี่ถือเป็นการถอยหลังในแง่ของ progressive degradation
ผมคิดว่าจำเป็นต้องมีกรณีตัวอย่างที่น่าประทับใจซึ่งสร้างด้วย htmx น่าจะดีถ้ามีตัวอย่าง “made with htmx” ที่บุกเบิกประสบการณ์เว็บรูปแบบใหม่
ผู้คนเหมารวม htmx ว่าเป็นของสำหรับกรณีใช้งานง่าย ๆ ที่ยังไม่ถึงขั้นต้องหยิบ “อาวุธจริงจัง” ออกมาใช้
ก็มีส่วนจริงอยู่บ้าง แต่เป็นมุมมองที่จำกัด แนวทาง กลับไปพึ่งเซิร์ฟเวอร์ ที่เกี่ยวข้องกับ htmx เป็นหมวดหมู่แยกต่างหากซึ่งยังไม่ได้ถูกสำรวจตั้งแต่เนิ่น ๆ ด้วยเหตุผลหลายอย่าง
HTMX คือการชุบชีวิต หมวดหมู่แอปแบบเก่า ในแบบที่ไม่ผูกกับแบ็กเอนด์
มันไม่ได้ทำสิ่งใหม่ หรือสิ่งที่พอจะรองรับคำว่า “หมวดหมู่แอปใหม่” ได้
มันเป็นวิธีสร้างไฮเปอร์มีเดีย หรือไซต์ที่เน้นคอนเทนต์ เช่น แคตตาล็อกสินค้า ฟอรัม ฟรอนต์เอนด์สำหรับผู้ดูแลระบบ บล็อก
คล้ายกับ jquery/liveview/turbolinks แต่ไม่ขึ้นกับแบ็กเอนด์ และไม่จำเป็นต้องดูแล logic ฝั่งฟรอนต์เอนด์ JS มากนัก หรืออาจไม่ต้องเลย
ถ้าต้องการปฏิสัมพันธ์หนัก ๆ แบบ Google Docs หรือ Figma ประโยชน์ที่ htmx ให้ก็จะลดลงมาก
https://htmx.org/essays/a-real-world-react-to-htmx-port/
เป็นฟรอนต์เอนด์อีคอมเมิร์ซที่เขียนด้วย HTMX และ Hyperscript
https://www.makaron.cz/
คุณอาจทำฟรอนต์เอนด์ TodoMVC ด้วย HTMX ได้ แต่แบ็กเอนด์จะใช้อะไร? Go, C#, Rust และตัวเลือกอีกไม่กี่อย่างดูเป็นทางเลือกที่เป็นธรรมชาติ แต่ก็ขึ้นอยู่กับสถานการณ์เสมอ
เหตุผลที่พูดถึง C# คือ ASP.Net MVC + Razor ดูเข้ากับ พาราไดม์ของ HTMX ได้อย่างเรียบร้อยมาก
ผมไม่มีความเกี่ยวข้องใด ๆ กับพวกเขา แต่ไซต์นี้สร้างด้วย htmx และ JS บางส่วนสำหรับฟีเจอร์ที่ซับซ้อนกว่า
เมื่อคิดว่า htmx มีเป้าหมายอย่างชัดเจนที่จะขยายแนวทางเก่าที่ดีอยู่แล้ว ผมจึงไม่แน่ใจนักว่ามันจะมอบ “ประสบการณ์เว็บรูปแบบใหม่” ได้หรือไม่
ตอนแรก htmx ดูดี แต่พอพยายามทำสิ่งที่ปกติน่าจะใช้ JavaScript ไม่ว่าจะเป็นวานิลลาหรือเฟรมเวิร์ก เช่น ปุ่มดรอปดาวน์ สุดท้ายก็จะไปพิจารณา hyperscript
แล้วพอดูตัวอย่าง ก็ไม่ชอบที่มีอะไรเหมือนประโยคอยู่ในโค้ด จึงย้ายไปใช้อย่างอื่น
อาจต้องลองใช้ htmx โดยไม่มี hyperscript หรืออาจต้องให้เวลากับ hyperscript มากขึ้น
แต่ถ้าคาดว่าจะต้องบำรุงรักษาไปอีกหลายปี มันดูแปลกใหม่เกินไป และถ้าภายหลังไม่ได้ใช้อีก ก็ไม่อยากถูกผูกติดอยู่กับมัน
ฝั่ง htmx ไม่สนใจเลยว่าใช้เครื่องมือโต้ตอบฝั่งไคลเอนต์อะไร ดังนั้นจึงเป็นคนละประเด็นกับว่า htmx มีประโยชน์หรือไม่
ส่วนตัวถ้าต้องการตัดเครื่องมือ build ของ JS ฯลฯ ออก ผมจะเลือก htmx + Alpine.js
ถ้าขนาดใหญ่ขึ้นและซับซ้อนขึ้น จะรับมือได้อย่างไร?
ผมเคยช่วยแอปพลิเคชันที่ใช้ htmx และพบปัญหาอยู่สองอย่าง อยากรู้ว่ามีใครมีประสบการณ์คล้ายกันไหม เป็นปัญหาที่เกิดจากการใช้เทคโนโลยีผิดวิธีหรือเปล่า หรือกำลังมีงานที่พยายามแก้เรื่องนี้อยู่หรือไม่
อย่างแรก จำเป็นต้องมี มิดเดิลแวร์แบบกำหนดเอง จำนวนมากในคอนโทรลเลอร์ เพื่อ决定ว่า endpoint ควรคืนค่า HTML ทั้งหน้าหรือคืนเฉพาะชิ้นส่วนที่ htmx ต้องการ
ฝั่ง htmx ดูเรียบง่าย แต่คงเป็นส่วนที่ทุกโปรเจกต์ที่ใช้ htmx ต้องสร้างขึ้นมาใหม่
อย่างที่สอง จำเป็นต้องมีการจัดการบันทึกรอบ ๆ
hx-triggerเมื่อ UI ซับซ้อนขึ้น องค์ประกอบจำนวนมากต้องตอบสนองต่อการเปลี่ยนแปลงภายนอกแทนที่จะอ่านสถานะบางอย่างแล้วคาดหวังให้เฟรมเวิร์กจัดคิวการอัปเดตให้ ต้องจัดการรายการอีเวนต์ที่จะตอบสนองด้วยตัวเอง
มีใครรู้สึกคล้ายกันไหม?