Datastar - เฟรมเวิร์กไฮเปอร์มีเดียน้ำหนักเบาสำหรับสร้างเว็บแอปแบบโต้ตอบ

 (data-star.dev)
16 คะแนน โดย GN⁺ 2025-10-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Datastar เป็น เฟรมเวิร์กน้ำหนักเบา ที่ใช้สร้างได้ตั้งแต่เว็บไซต์สแตติกแบบง่าย ๆ ไปจนถึง เว็บแอปทำงานร่วมกันแบบเรียลไทม์ โดยเริ่มต้นได้เพียงเพิ่ม script tag เดียวลงใน HTML
  • ใช้แนวทาง hypermedia-first ที่ขยาย HTML เพื่อให้สร้าง UI แบบโต้ตอบที่ขับเคลื่อนจากแบ็กเอนด์ ได้
  • ให้ความสามารถด้านการตอบสนองจากฝั่งแบ็กเอนด์แบบ htmx ขณะเดียวกันก็รองรับการตอบสนองจากฝั่งฟรอนต์เอนด์แบบ Alpine.js และ ทำงานได้โดยไม่ต้องมี npm package หรือ dependency
  • ฝั่งฟรอนต์เอนด์ใช้คุณสมบัติ data-* มาตรฐานเพื่อสร้างพฤติกรรมเชิงตอบสนอง ส่วนฝั่งแบ็กเอนด์ใช้ event เพื่อ แก้ไข DOM และเปลี่ยนสถานะ
  • มุ่งลดความซับซ้อนของ การพัฒนาเว็บแอปแบบ reactive ที่ขับเคลื่อนโดยแบ็กเอนด์ ด้วยการอัปเดตแบบเรียลไทม์บนพื้นฐาน SSE(Server-Sent Events) และ SDK สำหรับหลายภาษา

ภาพรวมของ Datastar

  • Datastar เป็น เฟรมเวิร์กแบบไฮเปอร์มีเดียที่ขยาย HTML โดยมีโครงสร้างที่ทำให้สามารถสร้างเว็บแอปแบบโต้ตอบเรียลไทม์ได้ด้วยการจัดการ DOM จากแบ็กเอนด์โดยตรง
  • ฝั่งเบราว์เซอร์เพียงโหลดสคริปต์ขนาด 10.7KB ก็เปิดใช้ความสามารถทั้งหมดได้ โดยไม่ต้องใช้ build tool หรือติดตั้งเฟรมเวิร์กเพิ่มเติม
  • สืบทอดหลักการของ Hypermedia Systems ที่ให้เซิร์ฟเวอร์เป็นผู้กำหนดสถานะของ UI และให้ไคลเอนต์สะท้อนผลนั้นแบบ reactive
  • ลดตรรกะฝั่งฟรอนต์เอนด์ให้น้อยที่สุดด้วยการจัดการ การอัปเดตข้อมูล, การเปลี่ยนสถานะ, และ DOM patching ผ่าน event จากแบ็กเอนด์

วิธีติดตั้ง

  • วิธีที่ง่ายที่สุดคือเพิ่มสคริปต์ผ่าน CDN ดังนี้
  • หรือจะดาวน์โหลดไฟล์โดยตรง หรือใช้ Datastar bundler เพื่อสร้าง bundle ของตนเองก็ได้
  • ไม่จำเป็นต้องติดตั้ง npm หรือตั้งค่า environment ของ Node แต่อย่างใด

คุณสมบัติ data-* และความเป็น reactive

  • หัวใจสำคัญคือการกำหนดพฤติกรรมแบบประกาศผ่าน คุณสมบัติ data-* ของ HTML
    • ตัวอย่าง: data-on-click="alert('Hello!')"
  • คุณสมบัติ data-on ใช้ระบุ Datastar expression ที่จะทำงานเมื่อเกิด event ที่กำหนด และสามารถใช้ JavaScript ปกติได้เช่นกัน
  • มี ส่วนขยาย VSCode และ ปลั๊กอิน IntelliJ สำหรับการเติมข้อความอัตโนมัติและช่วยด้านไวยากรณ์

DOM patching ที่ขับเคลื่อนโดยแบ็กเอนด์

  • Datastar ทำงานในรูปแบบที่ เซิร์ฟเวอร์เป็นผู้ขับเคลื่อนฟรอนต์เอนด์
    • เมื่อเซิร์ฟเวอร์ส่ง HTML fragment มา Datastar จะผสานเข้ากับ DOM ด้วย กลยุทธ์ morphing
    • morphing จะอัปเดตเฉพาะส่วนที่เปลี่ยนแปลง ช่วยคงสถานะเดิมและเพิ่มประสิทธิภาพ
  • ตัวอย่าง: 
    <button data-on-click="@get('/endpoint')">Open the pod bay doors, HAL.</button>  
<div id="hal"></div>
    หากเซิร์ฟเวอร์ตอบกลับเป็น HTML fragment, Datastar จะสลับแทนที่ element id="hal" โดยอัตโนมัติ

การสตรีมบนพื้นฐาน Server-Sent Events (SSE)

  • เซิร์ฟเวอร์สามารถส่ง event datastar-patch-elements เพื่ออัปเดต DOM แบบเรียลไทม์ได้

  • ตัวอย่างต่อไปนี้เป็นการแสดงบทพูดของ HAL แล้วรีเซ็ตกลับอีกครั้งหลังผ่านไป 1 วินาที

    event: datastar-patch-elements  
data: elements <div id="hal">I’m sorry, Dave. I’m afraid I can’t do that.</div>  

event: datastar-patch-elements  
data: elements <div id="hal">Waiting for an order...</div>

  • เพื่อรองรับสิ่งนี้ Datastar มี SDK สำหรับหลายภาษา:

    • Clojure, C#, Go, Java, Kotlin, PHP, Python, Ruby, Rust, Node.js
    • แต่ละ SDK จะส่ง event สำหรับ DOM patching ผ่านคลาส PatchElements หรือ ServerSentEventGenerator

Datastar Inspector และเครื่องมือ

  • นอกจากเครื่องมือสำหรับนักพัฒนาในเบราว์เซอร์แล้ว ยังสามารถใช้ Datastar Inspector เพื่อดู event ของ SSE ในรูปแบบภาพได้
  • นอกจากเอกสารทางการแล้ว ยังมีทรัพยากรอีกมาก เช่น DeepWiki ที่สร้างด้วย AI, ตัวอย่างโค้ดสำหรับ LLM, และ เอกสารหน้าเดียว

บทสรุป

  • Datastar เป็นแนวทางสมัยใหม่ที่ช่วย ทำให้การพัฒนาแอปพลิเคชันไฮเปอร์มีเดียที่ยึด HTML เป็นศูนย์กลางง่ายขึ้น
  • เบากว่าเฟรมเวิร์ก SPA แบบเดิม และมอบ ประสบการณ์การพัฒนาแบบ reactive ที่สมดุลระหว่างแบ็กเอนด์กับฟรอนต์เอนด์
  • เหมาะกับโปรเจกต์ที่ต้องการ การสตรีมแบบเรียลไทม์, การควบคุม UI จากเซิร์ฟเวอร์, และ การดีพลอยโดยไม่มี dependency

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

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

 
GN⁺ 2025-10-12
ความคิดเห็นจาก Hacker News

  • ทีมงาน Datastar เป็นคนที่มีความเชื่อและปรัชญาชัดเจนมาก และยังสละเวลาให้มือใหม่แบบไม่กั๊กด้วย แม้ประเด็นถกเถียงเรื่องเวอร์ชัน Pro จะกลบเรื่องนี้ไป แต่สิ่งนี้ไม่ใช่กลยุทธ์หารายได้แต่อย่างใด เพราะบริษัทจดทะเบียนเป็นองค์กรไม่แสวงหากำไร แนวทางคือแยกเฉพาะฟีเจอร์ที่มีคนต้องการเพียงส่วนน้อยไปไว้ใน Pro เพื่อควบคุมภาระการซัพพอร์ตที่เพิ่มขึ้นอย่างมีประสิทธิภาพ เนื่องจากคนกลุ่มเล็กที่ต้องการฟีเจอร์เหล่านี้มักเป็นกลุ่มที่เข้ามาสอบถามมากที่สุด ผมมองว่านี่เป็นวิธีที่ทั้งสร้างสรรค์และยุติธรรม เพราะ (a) ส่งสัญญาณว่าฟีเจอร์เหล่านี้เป็นฟีเจอร์ที่ควรระวังเพราะอาจกลายเป็นภาระ, (b) ให้คนที่ต้องการการซัพพอร์ตมากที่สุดหรือได้รับคุณค่าจาก Datastar มากที่สุดช่วยจ่ายเพิ่มเล็กน้อย, และ (c) ทำให้ทีมมีเวลาไปทุ่มให้ชุมชนโดยรวมได้มากขึ้น ซึ่งเป็นผลดี

    • ถ้าฟีเจอร์อย่าง data-animate, data-on-resize, data-scroll-into-view เป็น "ภาระถ่วง" จริง ก็แปลว่าออกแบบมาไม่ดี และผมก็ไม่คิดว่าฟีเจอร์แบบนี้จะมีแค่คนส่วนน้อยที่ต้องใช้ จะเก็บเงินกับสิ่งที่พวกเขาอยากขายก็ไม่เป็นไร แต่ไม่จำเป็นต้องหาเหตุผลมาอ้างขนาดนั้น

    • ผมสงสัยว่าฟีเจอร์ copy-to-clipboard มันสร้างภาระการซัพพอร์ตสูงจริงหรือ ถ้า Datastar อยู่ในสภาพที่แย่มากจนแม้แต่ฟีเจอร์ง่าย ๆ ยังต้องพึ่งการซัพพอร์ตเยอะเพื่อให้ใช้งานได้จริง แบบนั้นผมคงเห็นด้วยยาก

  • ถ้าคุณคิดว่า Datastar ไม่พอสำหรับงานแบบเรียลไทม์/ทำงานร่วมกัน/มัลติเพลเยอร์ หรือคิดว่าฟีเจอร์ Pro เป็นสิ่งจำเป็น ลองดูเดโม 3 ตัวที่รันอยู่บน VPS ราคา 5 ดอลลาร์ และอยู่รอดบนหน้าแรกของ HN ได้โดยไม่ใช้ฟีเจอร์ Pro แล้วจะเห็นว่า Datastar เป็นงานวิศวกรรมที่น่าทึ่งมาก

    • https://checkboxes.andersmurphy.com/

    • https://cells.andersmurphy.com/

    • https://example.andersmurphy.com/ (Game of Life แบบมัลติเพลเยอร์)
      ในตัวอย่าง checkboxes/cells การเรนเดอร์วิวเป็นแบบปรับตัวได้ จึงซูมออกได้ค่อนข้างมาก และยังมี back pressure กับ virtual scroll ด้วย

    • ถึงจะบอกว่าอยู่รอดบนหน้าแรกของ HN แต่บนหน้าจอแรกก็เขียนตัวใหญ่ว่า "bring your own backend" ดังนั้นมันไม่ได้อยู่รอดเพราะ Datastar

  • รวมเธรด HN ที่เกี่ยวข้องซึ่งกำลังคุยกันอยู่:

  • ผมไม่ค่อยเข้าใจว่าทำไมชุมชนถึงมีท่าทีเป็นศัตรูกันขนาดนี้ Datastar ส่วนใหญ่เป็นโอเพนซอร์ส ใช้ได้กับทุกภาษา และยังเป็นโปรเจกต์ที่น่าสนใจเพราะกำลังคิดหาทุนพัฒนา ผมคิดว่าเป็นเรื่องปกติที่คนจะผลักดันโปรเจกต์ของตัวเองในแบบของตัวเอง ผมเองก็ว่าจะลองแฮ็กอะไรด้วย golang ดู ขอบคุณสำหรับความทุ่มเทนะ มีฟีดแบ็กอยู่ข้อเดียวคือ สำหรับประเทศผม 299 ดอลลาร์เป็นเงินก้อนใหญ่มาก และบางฟีเจอร์ Pro อาจจำเป็นจริง ๆ เลยรู้สึกว่าราคาโหดเกินไป อยากให้พิจารณาระบบราคาตามประเทศแบบ Steam หรือระบบซัพพอร์ตแบบบริจาคด้วย ฟีเจอร์อย่างแอนิเมชันใน sveltekit ก็ให้ฟรี ไม่ใช่ว่าผมแค่อยากได้ฟรี แต่ผมจ่ายไม่ไหวจริง ๆ น่าจะตั้งราคาสูงขึ้นสำหรับองค์กร แล้วให้โซโล่เดฟจ่ายถูกลง ผมไม่เคยจ่ายเงินให้คอมมูนิตี้หรือโปรเจกต์ออนไลน์ไหนมาก่อน แต่กับ Datastar ถ้าราว 5–10 ดอลลาร์ผมยินดีช่วยสนับสนุน อยากให้ราคา solo tier ลงมาแค่ประมาณเกม Switch อย่าง silksong ก็พอ แม้จะเป็นโปรเจกต์ที่เจ๋งมาก แต่ก็น่าเสียดายที่ปฏิกิริยาจากชุมชนดูวิจารณ์หนักผิดปกติ

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

    • จุดตั้งต้นของคำวิจารณ์ผมมีดังนี้

      • บนหน้าโฮมเพจไม่มีการพูดถึง Pro เลย ต้องไปคุ้ยเอกสารถึงจะรู้สึกเหมือนโดนล่อให้ติดกับ
      • Pro ไม่ได้รวมแค่การซัพพอร์ตหรือชุดตัวอย่าง แต่รวมฟีเจอร์จริงด้วย
      • ถ้าพึ่งฟีเจอร์ Pro ก็จะผูกติดกับ Datastar และสิทธิในการดูแลรักษาจะผูกกับผู้ขาย
      • ถ้าไม่มี Pro แล้วเว็บทำงานไม่ได้เลย ปัญหา vendor lock-in ก็ยิ่งหนักขึ้น
      • ไม่มีเดโมทดลองให้เห็นว่าซื้อ Pro แล้วได้อะไร เหมือนที่ Alpine.js หรือ React Flow Pro มีให้ลองในเบราว์เซอร์
      • ถึงจะได้ซอร์สโค้ดมา ก็ยังแชร์การปรับปรุงกลับไม่ได้
      • ประเด็นไม่ได้อยู่ที่ราคา แต่อยู่ที่โครงสร้างและคุณค่า บางคนอาจมองว่าถูก บางคนอาจมองว่าแพง
      • ตัวอย่างโมเดล Pro ที่พออ้างอิงได้: Alpine.js Pro, React Flow Pro

    • บริษัทเล็ก ๆ ก็ยังต้องซัพพอร์ตเองอยู่ดี ดังนั้นในประเทศค่าครองชีพสูง เงิน 5 ดอลลาร์คงไม่พอแม้แต่จะปิดตั๋วซัพพอร์ตได้สักเคส

  • ผมพัฒนาฟรอนต์เอนด์ที่ใช้ Go กับ Templ บน Datastar มาหลายเดือนแล้ว และชอบฟีเจอร์ @actions กับวิธีที่หน้าเพจอัปเดตตาม response มาก แต่ส่วนตัวผมยังลังเลกับฟีเจอร์ signals มันโอเคกับฟิลด์เดี่ยวหรือ dropdown อะไรแบบนั้น แต่แบ็กเอนด์ของผมเป็น API สไตล์ Kubernetes พอจะเก็บ JSON resource ลงใน signal มันกลับไม่ค่อยเข้ากัน เพราะ Datastar จะพาร์สโครงสร้างเป็น sub-signal โดยเฉพาะโครงสร้างแบบ Kubernetes label ที่ key มี hostname prefix แปะอยู่ มันจัดการไม่ได้เลยและทำให้ signals เละเทะ การ data binding ใช้กับ key path แบบเรียบง่ายได้ดี แต่พอเป็น path ที่ต้องใช้อินเด็กซ์หรือ key แบบ hostname แล้วไปไม่รอด อีกอย่างกฎการแปลง HTML attribute อัตโนมัติใน JS (เช่น snake→camel) และการจัดการ modifier ก็ซับซ้อนและทำให้เกิดข้อผิดพลาดได้ง่าย ถึงอย่างนั้นผมก็ยังชอบแนวคิดที่รวมความสามารถของ HTMX/Alpine ไว้เป็นหนึ่งเดียวแล้วทำในสไตล์ hypermedia และยังชอบที่มันช่วยให้เลี่ยง ecosystem ของ NodeJS ได้ เคยมีช่วง RC ที่ wire format เปลี่ยนไป แต่เพราะผมใช้ Fiber และทำเองโดยไม่ใช้ Go SDK จึงอัปเดตค่อนข้างลำบาก ถึงอย่างนั้นผมก็คิดว่าการเปลี่ยนฟอร์แมตเป็นการเปลี่ยนที่ดี ทีมกำลังไปในทิศทางที่ถูกต้อง ก็หวังว่าจะพัฒนาต่อไปได้ดี

  • ไอเดียของ Datastar ดูยอดเยี่ยมมากจนผมเคยคิดจะเอาไปใช้เหมือนกัน แต่ก็มีความกังวลว่าเวอร์ชันโอเพนซอร์สถูกจำกัดไว้เพื่อไม่ให้แข่งกับ Pro อาจเป็นทางลัดสู่การเกิด hard fork ได้เร็ว เพราะมันเองก็ยังไม่ได้มี ecosystem ใหญ่มากพอจะทำให้คนไม่ย้าย
    [edit: โมเดล open-core ที่ปิดปลั๊กอินบางส่วนไว้ก็อาจสมเหตุสมผลมาก และถึงไม่ใช่ก็ยังมีตัวเลือกอีกมากมาย ขอให้ทั้งนักพัฒนาและผู้ใช้ Datastar ประสบความสำเร็จ]

    • ถ้ากังวลเรื่อง hard fork จริง ๆ การ fork ปลั๊กอินจากยุคก่อน Pro แล้วปรับให้เข้ากับ Datastar Pro เวอร์ชันปัจจุบันก็น่าจะเป็นประโยชน์กับทุกฝ่าย โค้ดมันเล็กมาก แค่ราว 50 บรรทัด เรียกว่าง่ายสุด ๆ

    • คำว่า "จำกัด" อาจแรงเกินไป เพราะ attribute/event ที่มีเฉพาะใน Pro มีอยู่ไม่กี่อย่าง และไม่ใช่ฟีเจอร์แกนหลักด้วยซ้ำ เอาจริง ๆ ก็แทนที่ได้ด้วย JS เล็กน้อยที่ส่งมาจากเซิร์ฟเวอร์แทบทั้งหมด ดูรายการได้ที่นี่: https://data-star.dev/reference/datastar_pro

    • ผมเชียร์ให้มีคน fork จริง ๆ อยากให้ใครสักคนทำเลย

  • อาจเป็นเพราะผมชินกับ ecosystem ของ React มากเกินไป แต่พอต้องทำอะไรที่ซับซ้อนเกินระดับหนึ่ง วิธีนี้กลับรู้สึกยากกว่าอย่างมีนัยสำคัญในเชิงตรรกะ ถ้าผมไม่ได้เข้าใจผิด Datastar คือแพตเทิร์นแบ็กเอนด์-ฟรอนต์เอนด์ที่ให้แบ็กเอนด์คืนค่า HTML ซึ่งจากประสบการณ์ที่เคยทำมา นั่นคือแนวทางที่ผมไม่อยากกลับไปแตะอีก โดยเฉพาะผู้ใช้ที่เน็ตช้า (ซึ่งยังมีอีกมาก ทั้ง dsl, ดาวเทียมยุคเก่า, 2G ฯลฯ) จะรู้สึกว่าช้าลงมาก เพราะแทนที่จะรับ JSON จำนวนน้อยหลายครั้ง กลับต้องรับ HTML ก้อนใหญ่หลายครั้ง

    • จากประสบการณ์ผม เวลาจะใช้ react app บน 2G/3G หลายครั้งมันไม่ขึ้นเลยด้วยซ้ำ ในทางกลับกัน ถ้าเป็น HTML โหลดทีเดียว อย่างมากก็ 1–2 วินาทีคอนเทนต์ก็มักจะขึ้นแล้ว วิศวกรมักชอบสร้าง time out ขึ้นมาใหม่เองแบบไร้เหตุผล ตอนนี้การตรวจจับความคืบหน้าทำใน socket ได้ แต่ในตัวแอปกลับไม่รู้สึกอะไรเลย ผมอยากให้เลิกพยายามทำให้ทุกอย่างดู "ฉึบฉับ" เกินจำเป็น

    • แพตเทิร์นแบบ "แบ็กเอนด์คืนค่า html" นี่คือวิธีที่เว็บยุคโมเด็ม 56k เคยเป็น และผมยังจำได้ว่าตอนนั้นใช้แท็ก table ซ้อนกันเป็นสิบชั้นเพื่อจัดเลย์เอาต์

    • ฟรอนต์เอนด์มีขอบเขตกว้างมาก ถ้าเป็นเว็บอย่างบล็อกส่วนตัวหรือร้านค้า ที่คอนเทนต์คงที่เยอะ โหลดไว และมีปฏิสัมพันธ์ไม่มาก เครื่องมือสาย htmx ก็เหมาะดี แต่ถ้าจะทำแอประดับ Figma หรือ Discord วิธีนี้ไม่พอ คนที่ไปสุดทางจริง ๆ มองว่า DOM เป็นคุก และจะพอใจกับการผสมกันของ canvas กับการคำนวณบน GPU เท่านั้น

    • ถ้าต้องออฟไลน์เต็มรูปแบบ แน่นอนว่าต้องไปอีกแนวทางหนึ่ง แต่เว็บไซต์ส่วนใหญ่ไม่ได้ต้องการสถานะที่คงอยู่ตลอดเวลาอยู่แล้ว แค่ page caching หรือ event state ก็ใช้งานได้ดีพอ เอา datastar js sdk ไปรันใน service worker แล้วซิงก์เฉพาะ state ที่จำเป็นลง browser storage ก็ทำหน้าที่เป็นแบ็กเอนด์ได้ แม้การเชื่อมต่อจะช้า ถ้าใช้การบีบอัดกับ sse stream แบบหนัก ๆ ถึงจะมีข้อมูลซ้ำเยอะก็ยังได้อัตราการบีบอัดเกิน 90% อินเทอร์เน็ตช้ามักมาคู่กับอุปกรณ์ช้า ดังนั้น Datastar จึงเบากว่า React, css-in-js และของหนักอื่น ๆ มาก แถมในเชิงฟังก์ชันก็แทบไม่เสียอะไร แต่เรียบง่ายขึ้นมหาศาล

  • นี่ไม่ใช่แพตเทิร์นใหม่อะไรเป็นพิเศษ ตอนยุคเปลี่ยนผ่านจาก DHTML ไป XHR วงการก็เคยผ่านแนวทางนี้มาแล้วครั้งหนึ่ง และสุดท้ายก็แทบเลิกใช้เพราะ trade-off หลายอย่าง เทคโนโลยีใหม่อย่าง DOM patching เองก็ยังติดปัญหาเดิม ๆ ทั้งการ coupling แน่น ความไม่เสถียร ขนาดที่ใหญ่ และ latency อยู่ดี Datastar ดูจะเป็นโซลูชันที่ช่วยให้บริษัทเล็ก ๆ ลดต้นทุนการพัฒนามากกว่า ไม่ใช่การทะลุข้อจำกัดใหม่ของเทคโนโลยี ไม่ได้แย่ แต่ก็ให้ความรู้สึกว่าประวัติศาสตร์กำลังวนซ้ำ

    • ในฐานะผู้เขียน Datastar ผมตั้งใจให้มัน "ไม่มีอะไรใหม่เลย" นั่นแหละ ช่วงดี ๆ ที่ jQuery แค่แตะหน้าเพจนิดหน่อยแล้วทุกอย่างยังง่ายอยู่มันหายไปหลังจาก SPA พยายามดึงทุกอย่างไปทำที่ฝั่งฟรอนต์จนลืมสาระสำคัญว่าแบ็กเอนด์ต่างหากที่ถือสถานะจริง สิ่งที่ผมอยากทำไม่ใช่นวัตกรรม แต่คือการทำให้ทุกอย่างกลับสู่ภาวะปกติ

    • ผมกลับคิดว่า Astro แก้ปัญหานี้ไปแล้วหรือเปล่า

  • วิดีโอ (หนัง) ตรงท้ายหน้าดีมากจนทำให้อยากเอาไปใช้ในโปรเจกต์ถัดไปเลย โดยเฉพาะช่วง "The planet uncomplicanus" ที่น่าประทับใจมาก

  • ผมชอบสิ่งที่ https://www.zjax.dev/ ทำออกมาเหมือนกัน