ถึงเวลาเหมาะสมในการนำ DOM Templating API มาใช้

 (justinfagnani.com)
1 คะแนน โดย GN⁺ 2025-06-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เว็บแพลตฟอร์ม ยังขาด Declarative Templating API ที่นักพัฒนาจำเป็นต้องใช้
  • แม้ว่า การทำเทมเพลต จะเป็นเทคโนโลยีแกนหลักของเว็บเฟรมเวิร์กสมัยใหม่ส่วนใหญ่ แต่ใน DOM API มาตรฐาน ยังไม่มีวิธีสร้างและอัปเดตเทมเพลตที่ปลอดภัยและมีประสิทธิภาพ
  • ส่งผลให้เกิดความไม่สะดวกและปัญหาด้านประสิทธิภาพต่อทั้ง ผู้ใช้ นักพัฒนา เฟรมเวิร์ก และแม้แต่ในระดับแพลตฟอร์ม
  • ตอนนี้คือช่วงเวลาที่เหมาะกับการนำ Templating API มาใช้ เพราะประสบการณ์จากเฟรมเวิร์กและ ความสามารถของ JavaScript ในช่วงหลังได้สะสมมากพอจนทำให้การนำไปใช้และการทำให้เป็นมาตรฐานมีความเป็นไปได้มากขึ้น
  • มีการเสนอทิศทางของ Templating API รุ่นถัดไป โดยผสานแนวคิดหลายแบบ เช่น เอกลักษณ์ของเทมเพลต และ reactivity แบบอิงสัญญาณ

สรุปข้อเสนอ

  • บทความนี้อธิบายที่มาและความจำเป็นของข้อเสนอให้เพิ่ม Declarative Templating API เข้าไปในเว็บแพลตฟอร์ม
  • DOM API มีพลังมาก แต่ใน DOM มาตรฐานยังไม่มี Template API สำหรับสร้างและอัปเดตหลายโหนดจากข้อมูลได้อย่างปลอดภัยและมีประสิทธิภาพ
  • เฟรมเวิร์กหลักอย่าง React, Vue, Angular ล้วนมี declarative templating เป็นหัวใจสำคัญ และมอบประโยชน์หลายด้าน เช่น ประสิทธิภาพการพัฒนา ความปลอดภัย สมรรถนะ การวิเคราะห์แบบสแตติก และการเรนเดอร์ฝั่งเซิร์ฟเวอร์
  • การไม่มี Templating API ทำให้ทั้งผู้ใช้ นักพัฒนา เฟรมเวิร์ก และตัวแพลตฟอร์มเองต้องเผชิญกับความซับซ้อนที่ไม่จำเป็น ความเสี่ยงด้านความปลอดภัย ประสิทธิภาพที่ลดลง และอุปสรรคในการเริ่มต้นใช้งาน
  • ผู้เขียนยืนยันว่าตอนนี้เป็นเวลาที่เหมาะสมในการนำ API นี้มาใช้ และเสนอแนวทางการทำให้เป็นมาตรฐานแบบค่อยเป็นค่อยไปโดยอาศัยประสบการณ์จากเฟรมเวิร์กเดิมและความสามารถของ JavaScript สมัยใหม่

ความจำเป็นของเทมเพลตและปัญหาในปัจจุบัน

  • DOM API คือรากฐานที่ขับเคลื่อนความสามารถแบบไดนามิกของเว็บแพลตฟอร์ม
  • แต่ใน DOM มาตรฐาน ยังไม่มีวิธีทำเทมเพลตแบบ declarative ที่จะนิยาม DOM tree จากข้อมูลได้อย่างปลอดภัยและอัปเดตได้อย่างมีประสิทธิภาพ
  • เว็บเฟรมเวิร์กสมัยใหม่ทั้งหมด (React, Vue, Angular, Svelte เป็นต้น) ต่างก็มี declarative templating
  • เหตุผลที่ declarative templating ได้รับความนิยมมีดังนี้
    • ให้ การใช้งานที่ดีกว่า และ อ่านง่ายกว่า เมื่อเทียบกับ API แบบ imperative
    • เสริม ความปลอดภัยจาก XSS โดยทำการ escape ข้อมูลภายในเทมเพลตโดยอัตโนมัติ
    • มี ประสิทธิภาพการเรนเดอร์ ที่ดีและรวดเร็ว
    • เพิ่มประสิทธิภาพการพัฒนา เช่น การวิเคราะห์แบบสแตติก การตรวจชนิด และ IntelliSense
    • รองรับการเรนเดอร์ฝั่งเซิร์ฟเวอร์

ปัญหาของสถานการณ์ปัจจุบัน

  • ผู้ใช้: การดาวน์โหลดไลบรารีและความหน่วงในการเรนเดอร์ทำให้การโหลดครั้งแรกช้าลง ขนาดโค้ดฝั่งไคลเอนต์ที่ใหญ่ขึ้นทำให้ UX แย่ลง
  • นักพัฒนา: ต้องใช้ไลบรารีแยกต่างหากเพื่อใช้งานเทมเพลต (npm, CDN ฯลฯ) ทำให้มีอุปสรรคในการเริ่มต้นและต้องพึ่งพาสิ่งที่ไม่ใช่มาตรฐาน
  • เฟรมเวิร์ก: ต้องสร้าง template engine ขึ้นเอง จึงเกิดการแลกเปลี่ยนที่หนักระหว่างประสิทธิภาพ ฟีเจอร์ และขนาดโค้ด
  • แพลตฟอร์ม: เสียเปรียบในการแข่งขันกับแอปเนทีฟ เพราะ Flutter, SwiftUI เป็นต้น มีระบบเทมเพลตในตัว

เหตุผลว่าทำไมตอนนี้จึงเหมาะสม

  • ความพยายามด้านเทมเพลตในอดีต (E4X, E4H, html template literal เป็นต้น) ล้มเหลว แต่ในเวลานั้นยังมีข้ออ่อนเรื่อง การอัปเดต DOM
  • ในช่วงหลัง เฟรมเวิร์กและคอมมูนิตี้ได้สั่งสม best practices ของ Template API ไว้อย่างเพียงพอแล้ว
  • สามารถเสนอ API ที่อิงกับ JavaScript ได้ และในมาตรฐาน JS ปัจจุบันก็มี tagged template literal อยู่แล้ว
  • ความต้องการเครื่องมือจัดการ DOM ที่สะดวกยังเพิ่มขึ้นอย่างต่อเนื่องทั้งในกลุ่ม นักพัฒนา Vanilla JS และ คอมมูนิตี้ Web Components
  • แม้ว่าจะมีข้อเสนอ primitive ระดับล่างอย่าง DOM Parts ควบคู่กันไป แต่ API แบบ declarative ระดับสูงสามารถสร้างประโยชน์ได้มากกว่าและชี้ทิศทางการพัฒนาได้ดีกว่า

การวิเคราะห์ตัวอย่างของไวยากรณ์เทมเพลตที่ดี

  • ระบบเทมเพลตกระแสหลัก (React-JSX, Vue, Svelte, Angular เป็นต้น) ล้วนมีพื้นฐานเป็นไวยากรณ์แบบ markup + binding ที่คล้ายกันมากในระดับลึก
  • ในกรณีของเทมเพลตแบบ JS API โดยทั่วไป expression ของเทมเพลตจะคืนค่าคำอธิบาย DOM และมีฟังก์ชัน render แยกต่างหากที่นำสิ่งนั้นไปสะท้อนเป็น DOM จริง
  • ความพยายามยุคเก่าอย่าง E4X คืนค่า DOM โดยตรง ทำให้โมเดลการอัปเดตด้อยกว่า

ความเป็นไปได้ของ Templating API บนพื้นฐาน JavaScript

  • ผ่าน tagged template literal จึงสามารถออกแบบ Templating API ได้โดยไม่ต้องเพิ่มความสามารถใหม่ให้กับ JavaScript
  • มีกรณีพิสูจน์แนวคิดอยู่แล้วหลายแบบ เช่น JSX-to-Lit

ประเด็นเรื่องการผสาน JSX

  • การทำ JSX ให้เป็นมาตรฐานต้องนิยามความหมายและ runtime semantics ที่ซับซ้อน เพราะ JSX เองเป็นเพียงไวยากรณ์เท่านั้น
  • JSX แบบไม่เป็นมาตรฐานที่ใช้อยู่ในปัจจุบันเป็นเพียงการแปลงไวยากรณ์ล้วน ๆ ดังนั้นหากมีการนำมาตรฐาน Template API มาใช้ในอนาคต ก็สามารถเชื่อมต่อผ่านคอมไพเลอร์ที่แปลง JSX -> template literal ได้
  • หากในอนาคตมีการทำ JSX ให้เป็นมาตรฐานจริง ก็จะปรับไปใช้โครงสร้างชนิดข้อมูลที่สอดคล้องกับ Template API ได้ไม่ยาก

ความสัมพันธ์กับ Templating API แบบอิง HTML

  • นักพัฒนาและคอมมูนิตี้จำนวนมากเรียกร้องระบบเทมเพลตแบบ HTML
  • อย่างไรก็ตาม ระบบที่อิง HTML ต้องออกแบบไวยากรณ์และ expression ใหม่สำหรับ binding, ภาษานิพจน์, คำสั่งควบคุม เป็นต้น จึงเป็นงานที่ใหญ่กว่ามาก
  • เหตุผลเดียวกันนี้เองที่ทำให้เฟรมเวิร์กยุคหลัง (เช่น Lit) ย้ายจาก HTML template ไปสู่ JS API
  • ดังนั้น Templating API ที่อิง JS จึงควรถูกนำมาก่อน และค่อยขยายต่อไปสู่ HTML API แบบเป็นขั้นเป็นตอนในอนาคต

ความสุกงอมของประสบการณ์ด้าน reactivity

  • โมเดล reactivity หลายแบบได้รับการพิสูจน์แล้ว เช่น VDOM diffing (React), เอกลักษณ์ของเทมเพลต (Lit), และสัญญาณ (fine-grained signals, Solid/Svelte/Vue เป็นต้น)
  • แนวทางอิง VDOM ช้ากว่า ขณะที่การผสาน เอกลักษณ์ของเทมเพลต + โมเดลสัญญาณ ให้ทั้งความเร็ว ประสิทธิภาพ และความอธิบายได้ที่ดีกว่า
  • แนวทางอิงสัญญาณแม้จะต้องห่อข้อมูลทั้งหมดเป็นสัญญาณ แต่ก็ยังสามารถใช้ปะปนกับข้อมูลทั่วไปได้

เส้นทางการพัฒนาและผลที่คาดหวัง

  • Declarative JS Templating API ที่เสนอจะให้ประโยชน์โดยตรงกับทั้ง Vanilla JS, Web Components และเฟรมเวิร์กใหม่
  • ยังสามารถใช้กับเฟรมเวิร์กเดิมได้ในฐานะ compile target, runtime backend หรือ API ที่รองรับโดยตรง
  • รองรับทั้งแนวทาง re-rendering และ reactivity แบบอิงสัญญาณ
  • ยังเป็นการปูพื้นฐานไปสู่การขยายต่อในอนาคต เช่น เทมเพลต declarative แบบอิง HTML และ custom elements แบบ declarative
    • ขอบเขตของ API แคบและชัดเจน และเชื่อมกับ API ที่มีอยู่เดิม (เช่น DOM Parts) ได้ง่าย
  • แม้ API และไวยากรณ์ภายนอกจะดูเรียบง่าย แต่ในชั้นการทำงานด้านล่างยังมีพื้นที่การพัฒนากว้าง ทั้ง DOM Parts และ scheduler รวมถึงต้องอาศัยความร่วมมือด้านมาตรฐานและการทดสอบ

บทส่งท้าย

  • ผู้เขียนกำลังหารือข้อเสนอนี้ใน GitHub issue และเชิญชวนให้คอมมูนิตี้รวมถึงวิศวกรแพลตฟอร์มเข้ามามีส่วนร่วม

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

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

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

  • เหตุผลที่อดขำไม่ได้เมื่อได้ยินคำว่า "เรารู้ว่าไวยากรณ์เทมเพลตที่ดีเป็นอย่างไร" ก็เพราะในความเป็นจริง เรายังไม่เคยตกลงกันได้ชัดเจนด้วยซ้ำว่าเกณฑ์นั้นคืออะไร ผมคิดว่าในเรื่องเทมเพลต ประสบการณ์เชิงภาพ (visual) สำคัญกว่ามุมมองเชิงสัญลักษณ์ (symbolic) นี่เองที่อธิบายว่าทำไมเครื่องมืออย่าง Dreamweaver ในอดีตถึงประสบความสำเร็จมาก และทำไมนักออกแบบจำนวนมากถึงเริ่มเรียนรู้ผ่านเครื่องมืออย่าง Photoshop เช่นกัน ผมเลยรู้สึกเสียดายนิดหน่อยที่ความพยายามครั้งนี้ดูเหมือนเป็นการพยายามสร้าง XSLT ขึ้นมาใหม่ แก่นปัญหาของการทำเทมเพลตก็คือการนำโครงสร้างที่ไม่ได้ออกแบบมาดีนักมาประกอบให้ได้ผลลัพธ์ที่ออกมาดี ยิ่งไปกว่านั้น ยังมีปัญหาเรื่องการแสดงเอนทิตีที่เชื่อมโยงกันแต่ไม่ได้อยู่ใน tree เดียวกัน เช่น label กับ for ถ้าผมเสกได้ ผมก็อยากให้เลิกพยายามยัดทุกอย่างให้เข้ากับเลย์เอาต์เอกสารมาตรฐานแบบแปลก ๆ เสียที แค่ใช้ absolute positioning ให้ดี ก็แก้ปัญหา UI ได้อย่างมีประสิทธิภาพหลายอย่างอยู่แล้ว เลยสงสัยว่าทำไมถึงพยายามบังคับให้เครื่องมารับภาระทำคณิตศาสตร์เหล่านี้ซ้ำแล้วซ้ำเล่า

    • เห็นด้วยกับเรื่องที่ว่ามันเหมือนพยายามสร้าง XSLT ใหม่ ถึงผมจะไม่ชอบ XML เอง แต่ XSLT นั้นทรงพลังจริง ๆ และทุกวันนี้ก็ยังได้รับการรองรับอย่างกว้างขวางในเบราว์เซอร์ XML มีข้อเสียชัดเจนในงานอย่าง configuration หรือ IPC แต่ในจุดที่มันจับคู่กับภาษามาร์กอัปที่ยอดเยี่ยมและได้พลังการแปลงของ XSLT เข้ามาเสริม กลับเป็นส่วนที่น่าเสียดายว่าไม่เคยถูกใช้อย่างเต็มที่ เหตุผลที่ XSLT ไม่ได้รับความนิยมก็เพราะมันเป็น DSL แบบประกาศเชิงฟังก์ชันอย่างแท้จริง หลายคนพูดถึง DSL ในเชิงบวก แต่ของที่นิยมกันจริงมักเป็นแค่การเอาความหมายเชิงกระบวนวิธีของภาษายอดนิยมมาห่อไว้บาง ๆ เท่านั้น ผมคิดว่าด้วย DSL ที่ออกแบบมาดี เราสามารถจัดการงานซับซ้อนได้อย่างเรียบง่าย แต่ผู้คนแค่ไม่ค่อยอยากลงแรงเรียนรู้มัน

    • คุณบอกว่าไวยากรณ์เทมเพลตที่ดีนั้นแก่นสำคัญคือความเป็นภาพ ผมอยากรู้ว่าทำไมถึงได้ข้อสรุปแบบนั้น สำหรับผมมันฟังดูเหมือนเป็นความไม่พอใจกับ HTML+CSS เอง หรือก็คือวิธีการสร้างมันมากกว่า และก็สงสัยด้วยว่าทำไมถึงยก absolute positioning ขึ้นมาพูด แม้มันจะมีประโยชน์ในจุดที่เหมาะสม แต่ถ้าใช้เพื่อเลย์เอาต์ทั้งระบบกลับดูแลยากกว่า และพังได้ง่ายตามขนาดหน้าจอหรือปริมาณเนื้อหา แม้แต่เลย์เอาต์หนังสือพิมพ์เองก็ยังมีรายละเอียดอ่อน ๆ ของตัวอักษรและ typography มากมาย จนแก้ด้วย absolute positioning อย่างเดียวไม่ได้ เวลาทำ CSS ลึก ๆ ผมมักพบว่าการเอาเลย์เอาต์ที่เริ่มจาก absolute positioning มาปรับใหม่เป็น flex หรือ flow ในภายหลัง กลับแก้ปัญหาได้เร็วและง่ายกว่า calc() กับ viewport unit ก็อาจมีความหมายในบางกรณี แต่ในทางปฏิบัติ ถ้าเนื้อหาหรือ viewport ไม่ได้ตายตัวจริง ๆ absolute positioning ก็ไม่เหมาะนัก

    • ผมเคยเห็นคนพูดว่า ผู้คนอ้อมซับซ้อนเกินไปเพื่อให้ได้ผลแบบเดียวกับสิ่งที่ absolute positioning ที่ใช้ดี ๆ ทำได้ง่ายและเร็ว แต่บนเว็บมีข้อกำหนดว่าหน้าเอกสารต้องดูดีบนทุกอุปกรณ์ ทุกขนาด ทุกการวางแนว และทุกระดับประสิทธิภาพ แอปทั่วไป เช่น แอปบนวินโดวส์ ไม่ต้องกังวลแบบนี้ และแอปมือถือก็มักพิจารณาแค่ขนาดหน้าจอมาตรฐาน เว็บเท่านั้นที่ต้องรองรับทุกอย่างพร้อมกัน

    • ผมคิดว่าการตอบกลับคำว่า "ไวยากรณ์เทมเพลตที่ดี" แบบประชดประชันนั้นไม่ค่อยสุภาพนักกับคนที่กำลังพยายามผลักดันความก้าวหน้า และผมก็คิดว่าตอนนี้เรามีไวยากรณ์เทมเพลตที่ดีอยู่แล้ว โดยมี jsx เป็นตัวอย่างเด่น ผมไม่ใช่แฟน React แต่คิดว่า jsx ได้สร้างความเปลี่ยนแปลงครั้งใหญ่ให้การพัฒนาเว็บ และระบบเทมเพลตฝั่ง js ส่วนใหญ่ก็แทบลู่เข้าหากันที่แนวคิดแบบ "เทมเพลตในฐานะ expression", "การประกอบผ่านการซ้อนกัน" และการใช้ JavaScript จัดการ control flow

    • React กับ Svelte ดูคล้ายกันแค่ภายนอก แต่รูปแบบการทำงานจริงต่างกันพอสมควร แก่นของ React คือการให้ฟังก์ชัน JavaScript ที่ (เกือบ) ปกติคืนค่า markup แบบ lazy ในรูปของ JSX จุดต่างสำคัญคือมันไม่มีไวยากรณ์เทมเพลตเฉพาะสำหรับ loop หรือ conditional rendering ทุกอย่างจัดการด้วย JavaScript ปกติทั้งหมด

  • ผมได้เรียนรู้ซ้ำแล้วซ้ำเล่าว่า API กับ ABI (application binary interface) ไม่มีวันเป็นของสุดท้ายตลอดไป ความต้องการของแอปไม่เคยหยุดนิ่งและเปลี่ยนไปเรื่อย ๆ ตามเวลา ดังนั้นจึงไม่มี API ที่สมบูรณ์แบบและใช้ได้ตลอดกาล ข้อเสนอนี้เป็นตัวอย่างที่ดี ปัญหามักถูกแก้ในไลบรารีระดับผู้ใช้ก่อน เช่น React แล้วสุดท้ายค่อยไหลลงมาเป็นมาตรฐาน Polyfill ก็เป็นแพตเทิร์นเดียวกัน ต่อให้ข้อเสนอพวกนี้สำเร็จ สุดท้ายมันก็จะกลายเป็นเทคโนโลยีเก่า แล้วผู้คนก็จะหาทางใหม่เพื่อเลี่ยงมัน DOM API, ECMA, เบราว์เซอร์เก่า ล้วนมีชะตาแบบเดียวกัน เรื่องนี้ทำให้ผมสงสัยว่าเราควรมอง technical entropy, extensibility และ backward compatibility เองว่าเป็น use case มาตรฐานหรือไม่

    • การเพิ่มฟีเจอร์ใหม่ให้เว็บสแตนดาร์ดสุดท้ายแล้วหมายถึงภาระโค้ดมหาศาลในด้านการบำรุงรักษา และเมื่อจะสร้างเบราว์เซอร์ที่สอดคล้องตามมาตรฐาน ก็ต้องเพิ่มโค้ดที่ต้อง implement ขึ้นเรื่อย ๆ โปรเจกต์อย่าง Servo ที่พยายามไล่ตามให้ทันจึงต้องวิ่งตามแต่ส่วนขยายตลอด ผมเองก็อยากให้เว็บแพลตฟอร์มมีความสามารถทั้งหมดของสภาพแวดล้อมแบบเนทีฟด้วยเหมือนกัน ภายใต้ข้อจำกัดเรื่อง privacy และ sandbox และก็อยากให้ประสบการณ์นักพัฒนาดีขึ้น แต่ถ้าจะไปถึงฝันนั้น เราต้องคิดถึงต้นทุนด้านความซับซ้อนที่เพิ่มขึ้นด้วย ผมยังสงสัยว่า native templating ที่กำลังคุยกันอยู่ครั้งนี้จะยกระดับประสบการณ์นักพัฒนาได้ชัดเจนจริงหรือไม่

    • ถ้ายังคง backward compatibility เอาไว้และไม่เปลี่ยน interface งั้น versioning ก็ทำหน้าที่นั้นอยู่แล้วไม่ใช่หรือ

    • แม้จะมีการอ้างว่าพอเก่าแล้วก็ต้องมีการอ้อมหรือ patch กันซ้ำ ๆ แต่ในกระบวนการนั้นก็มีผลดีคือความสามารถพื้นฐานถูกยกระดับขึ้นหนึ่งขั้น incremental update ยังมีคุณค่าเพียงพอ แม้ว่าความต้องการของผู้ใช้จะค้นพบช่องว่างและ use case ใหม่ ๆ อยู่เรื่อย ๆ ก็ตาม

    • ผมไม่เห็นด้วยกับคำกล่าวที่ว่า "API และ ABI ไม่มีวันเสถียรตลอดไป" ตัวอย่างเช่น getElementById ก็ยังคงเสถียรมากว่า 25 ปีแล้ว การบอกว่า API ที่ไม่เปลี่ยนเลยนั้นเป็นไปไม่ได้ ฟังดูคล้ายการยอมแพ้ส่วนบุคคลมากกว่า เพราะในโลกจริงมีข้อยกเว้นมากมาย ความต้องการมีไม่สิ้นสุดอยู่แล้ว ถ้าต้องรองรับเพิ่ม ก็เพิ่ม API ใหม่เข้าไปได้ ไม่จำเป็นต้องทำลาย API ที่ใช้งานอยู่

    • บนเว็บ เมื่อ API ถูกเปิดเผยออกไปแล้ว ก็จะมีคนที่พึ่งพารูปแบบนั้นไปตลอดชีวิต เพราะอย่างนั้นแรงสะเทือนจากการตัดสินใจเมื่อ 20 ปีก่อนจึงยังตามหลอกหลอนอยู่ได้จนถึงทุกวันนี้ ตัวอย่างเช่นกรณี "smooshgate"

  • มีการพูดถึงกระแส reactive programming พร้อมกับบอกว่าระบบระดับผู้ใช้ได้ลองพื้นที่นี้มามากพอแล้ว และตอนนี้เราสามารถรวบรวมข้อดีของแนวทางต่าง ๆ มาสร้างระบบมาตรฐานที่แท้จริงได้ แต่ผมคิดว่าในกลุ่มอย่าง Ryan Carniato/Solid JS ก็ยังคงสำรวจความเป็นไปได้ใหม่ ๆ ด้วย signals อยู่ จึงยังไม่ใช่ว่าการสำรวจจบแล้ว ยังมีพื้นที่ให้พัฒนาได้อีกมาก

  • เว็บต้องการ native templating, reactivity และ data binding จริง ๆ ทรัพยากร CPU และแบนด์วิดท์ที่สูญเปล่าไปกับการที่ผู้ใช้หลายพันล้านคนทั่วโลกต้องดาวน์โหลด, parse และรันเฟรมเวิร์กหนัก ๆ อย่าง React นั้นมากเกินจะจินตนาการได้

    • พอเทียบกับการสิ้นเปลืองทรัพยากรอย่างมหาศาลจาก LLM และการคำนวณเข้ารหัสแล้ว ความสิ้นเปลืองแบบนี้กลับรู้สึกว่าเล็กน้อยไปเลย

    • ตอนนี้ใน TC39 มี proposal ที่เกี่ยวกับ signals ออกมาแล้ว ซึ่งทำให้เราขยับไปได้อีกก้าวหนึ่ง

    • ของที่จำเป็นจริง ๆ สำหรับการพัฒนาก็แค่ data binding สองทางกับตัว clone ของ jsx ประมาณนั้นก็พอ

    • React ไม่ใช่ระบบเทมเพลต

  • ระหว่างที่ติดตามการถกเถียงเรื่องการนำระบบเทมเพลตระดับสูงเข้าสู่เว็บสแตนดาร์ด ผมกลับคิดว่าสิ่งที่ควรมีให้ก่อนคือ API ระดับต่ำที่เบราว์เซอร์มีให้ในตัว แทบเป็นไปไม่ได้เลยที่ทุกคนจะเห็นพ้องกับระบบเทมเพลตมาตรฐานเพียงแบบเดียว ในทางกลับกัน ถ้าเบราว์เซอร์มี API ระดับต่ำสำหรับ apply diff ลงบน DOM ให้ก็พอแล้ว เช่น อยากให้มีเมธอดเนทีฟประมาณนี้: element.applyDiff(DocumentFragment | string, { method: 'innerHTML' | 'outerHTML' }) ถ้า apply diff แบบนี้ ก็จะอัปเดตได้แบบไม่ทำลายสภาพเดิม พร้อมคง focus, ค่า input, สถานะ audio/video ฯลฯ ของ element ปัจจุบันเอาไว้ได้ มีไลบรารี js อย่าง Idiomorph อยู่แล้ว แต่โซลูชันแบบเนทีฟน่าจะเร็วกว่าได้มาก

    • ในบทความมีลิงก์ไปยัง DOM parts proposal อยู่ ข้อเสนอนี้มีประโยชน์มากในฐานะ API ระดับต่ำ มันอาจไม่ค่อยเข้ากับเฟรมเวิร์กสาย VDOM แต่สำหรับเฟรมเวิร์กอื่น ๆ จะช่วยให้ implementation ง่ายขึ้น และเปิดช่องให้ optimize ได้มากขึ้น ถ้ามี signals proposal ตามมาด้วย ก็จะใช้งานได้ดีมากแม้ไม่พึ่งเฟรมเวิร์ก

  • ผู้เขียนบทความนี้ถูกแนะนำว่าเป็นคนที่มีประสบการณ์ระดับแนวหน้าที่สุดในสายงานนี้ เขามีส่วนสำคัญกับ Lit, Polymer, web components ของ Google และ DOM spec แกนหลักอีกหลายตัว

    • แต่ก็มีคำวิจารณ์ว่าบรรดาสเปกจำนวนมากที่เขาผลักดันกลับสร้างปัญหามากกว่าเดิม เขาทำให้ต้องมีเว็บสเปกมากกว่า 20 ตัวเพื่อรองรับโซลูชันตื้น ๆ ที่ยังขัดเกลาไม่เสร็จ ทั้งยังนำสิ่งที่ทำได้อยู่แล้วใน userland ไปทำให้เป็นมาตรฐานด้วยวิธีที่ซับซ้อนเกินจำเป็น นอกจากนี้ยังมีการพูดถึงว่า Safari เรียกร้องความจำเป็นของแนวทางเชิงประกาศมาตั้งแต่ 15 ปีก่อนแล้ว แต่กลับถูกเพิกเฉย

  • แทนที่จะใช้แนวทางแบบ JSX ผมอยากได้แนวทางด้านไวยากรณ์ที่คล้ายกับสิ่งที่ Kotlin ทำ โดยทำ DSL ให้เป็นเรื่องทั่วไปผ่าน receiver กับ builder วิธีแบบนี้มีประโยชน์มาก ไม่ใช่แค่กับเทมเพลต HTML ธรรมดา แต่รวมถึงลำดับชั้นของคอมโพเนนต์ การตั้งค่า (config) และสถานการณ์อีกหลากหลาย ความหมายที่แท้จริงของ templating กับ data binding สุดท้ายแล้วก็เป็นเพียงชุดฟังก์ชันมาตรฐานที่ใช้ความสามารถเชิงไวยากรณ์พวกนี้ ซึ่งมีความคล้ายกับ Jetpack Compose

    • ฟีเจอร์ที่จำเป็นจริง ๆ มีแค่ไม่กี่อย่าง: loop, conditional ของ attribute, conditional ของ node เป็นต้น อันที่จริง แค่มีโครงสร้างแบบนี้ก็สามารถนำไปใช้ข้ามภาษาได้แล้ว

  • ผมไม่เคยมั่นใจเสมอไปว่า declarative templating ดีกว่า jQuery ผมใช้ React มาเกือบ 10 ปี แต่ยิ่ง SPA ของผมซับซ้อนขึ้นเท่าไร ก็ยิ่งคิดถึงการควบคุม DOM แบบ imperative มากขึ้นเท่านั้น abstraction ของ DOM มักรั่วออกมาอยู่เสมอ และบางครั้งแพตเทิร์นเรียบง่ายอย่าง "last-write-wins" กลับชัดเจนกว่า แม้เทมเพลตแบบประกาศจะบอกว่าช่วยแก้ปัญหาเหล่านี้ได้ แต่พอเริ่มแชร์ mutable state ระหว่างคอมโพเนนต์ ข้อจำกัดของมันก็โผล่มาเร็วมาก

    • ความรู้สึกนี้ส่วนหนึ่งก็มาจากฝั่งนักพัฒนา React ที่มองว่าการเรียก DOM API โดยตรงเป็นเรื่องต้องห้าม การใช้ ref อย่างจริงจัง หรือแม้แต่การหาและจัดการคอมโพเนนต์โดยตรงผ่าน id ก็ไม่ได้มีปัญหาอะไร อันที่จริง ไลบรารีฟอร์มที่เร็วและ rerender น้อยหลายตัวก็ทำงานแบบนี้

    • ผมไม่ได้ชอบ React เป็นพิเศษ แต่คิดว่าในการหลุดออกจาก DOM เชิงประกาศไปใช้ innerHTML, ref และอื่น ๆ นั้นไม่มีอุปสรรคอะไร จะบอกว่าทำได้ด้วย imperative control ก็จริง แต่ในทางปฏิบัติ สิ่งที่ declarative ทำไม่ได้จริง ๆ นั้นมีไม่มาก attachShadow() หรือ showModal() เอง แค่เพิ่มโค้ดสัก 10 บรรทัด ก็ห่อให้กลายเป็น declarative ได้ง่าย ๆ

  • ถ้า proposal ของ Records และ Tuples เดินหน้าต่อไปได้ JSX ก็น่าจะใช้โครงสร้างเหล่านั้นเพื่อมี semantics แบบใหม่ได้ แต่ในความเป็นจริง proposal นั้นไม่ได้แค่ชะงัก แต่ถูกถอนทิ้งไปเลย (ดู issue) และถูกแทนที่ด้วย composites proposal

  • ผมคิดว่าควรหยุดการถกเถียงเรื่องมาตรฐานฟีเจอร์ระดับสูงแบบนี้ได้แล้ว แล้วหันไปขยายคุณสมบัติระดับล่างแทน เพื่อให้มีคุณค่าต่อการ implement ไลบรารีระดับบนมากกว่า ถ้าข้อเสนอมาตรฐานไม่มีข้อได้เปรียบที่ชัดเจนกว่าไลบรารี ก็ไม่มีความหมายอะไร ผมคิดว่าควรเริ่มคุยเรื่องการทำให้เป็นมาตรฐานเฉพาะสิ่งที่ถูกพิสูจน์มาแล้วอย่างกว้างขวางในรูปแบบไลบรารีอย่างน้อย 5-10 ปีเท่านั้น