ชุมชนนักพัฒนาเว็บกำลังถกเถียงกันอย่างคึกคักเกี่ยวกับข้อเสนอที่จะเพิ่มความสามารถในการทำ templating แบบ native เข้าไปในเว็บเบราว์เซอร์โดยตรง การอภิปรายครั้งนี้มุ่งเน้นไปที่การลดภาระงานขนาดใหญ่ที่ web framework สมัยใหม่อย่าง React สร้างขึ้นให้กับผู้ใช้ พร้อมทั้งทำให้การพัฒนาเว็บเข้าถึงได้ง่ายขึ้นโดยไม่ต้องใช้เครื่องมือ build ที่ซับซ้อน
ในปัจจุบัน เว็บแอปพลิเคชันทุกตัวที่ต้องการเนื้อหาแบบไดนามิกจำเป็นต้องดาวน์โหลด แยกวิเคราะห์ และรันโค้ด framework ก่อนที่จะสามารถใช้งานได้ สิ่งนี้สร้างภาระที่สำคัญให้กับผู้ใช้ โดยเฉพาะผู้ที่มีการเชื่อมต่ออินเทอร์เน็ตช้าหรือใช้อุปกรณ์รุ่นเก่า วิธีแก้ไขที่เสนอจะย้ายฟังก์ชัน templating จาก JavaScript library เข้าไปในตัวเบราว์เซอร์เอง ซึ่งอาจช่วยประหยัดให้ผู้ใช้หลายล้านคนไม่ต้องดาวน์โหลดโค้ดที่ซ้ำซ้อน
 |
|---|
| ไซต์ก่อสร้างที่กำลังดำเนินการ เป็นสัญลักษณ์ของความพยายามอย่างต่อเนื่องในการปรับปรุง web development frameworks ด้วยโซลูชัน native templating |
Framework Overhead สร้างผลกระทบจริงต่อผู้ใช้
สถานการณ์ปัจจุบันของการพัฒนาเว็บบังคับให้ทุกเว็บไซต์ต้องส่งมอบ templating solution ของตัวเอง React เพียงตัวเดียวสามารถเพิ่มขนาดการโหลดหน้าเว็บครั้งแรกได้มากกว่า 100KB ในขณะที่แม้แต่ทางเลือกที่เบากว่าก็ยังต้องใช้ JavaScript หลายกิโลไบต์ก่อนที่แอปพลิเคชันจะสามารถโต้ตอบได้ ภาระนี้สะสมไปทั่วผู้ใช้เว็บหลายพันล้านคนทั่วโลก ซึ่งแสดงถึงการสูญเสียอย่างมหาศาลในแบนด์วิดท์และพลังการประมวลผล
การอภิปรายในชุมชนเผยให้เห็นความหงุดหงิดกับสถานการณ์นี้ นักพัฒนาหลายคนชี้ให้เห็นว่าแพลตฟอร์มคู่แข่งอย่างการพัฒนาแอปมือถือแบบ native หรือ desktop framework มีความสามารถ templating ที่มาพร้อมกับระบบ ทำให้มีข้อได้เปรียบอย่างมากเหนือเว็บแอปพลิเคชันที่ต้อง bootstrap solution ของตัวเอง
การเปรียบเทียบ Overhead ของ Framework ในปัจจุบัน:
- React : 100KB+ ในกรณีที่แย่ที่สุด
- ทางเลือกที่มีน้ำหนักเบา: ขั้นต่ำเพียงไม่กี่ KB
- โซลูชันแบบ Native : 0KB สำหรับการดาวน์โหลดเพิ่มเติม
- ผลกระทบระดับโลก: ผู้ใช้หลายพันล้านคนได้รับผลกระทบจากการดาวน์โหลดที่ซ้ำซ้อน
แนวทางทางเทคนิคที่อยู่ระหว่างการพิจารณา
ข้อเสนอแนะให้ใช้ tagged template literals ของ JavaScript เป็นพื้นฐานสำหรับ native templating เพื่อหลีกเลี่ยงความจำเป็นในการเพิ่ม syntax ใหม่ให้กับภาษา แนวทางนี้จะทำงานร่วมกับความรู้ JavaScript ที่มีอยู่ในขณะที่ให้ประโยชน์ด้านประสิทธิภาพของการ implement แบบ native
มีสามโมเดล reactivity หลักที่กำลังได้รับการประเมิน: virtual DOM diffing (ที่ใช้โดย React), template identity (ที่ใช้โดย Lit), และ signals-based fine-grained reactivity (ที่ใช้โดย SolidJS และได้รับการนำมาใช้มากขึ้นโดย framework อื่นๆ) ข้อเสนอมีแนวโน้มไปทางการรวม template identity กับ signals เพื่อประสิทธิภาพและประสบการณ์นักพัฒนาที่เหมาะสมที่สุด
Tagged template literals: ฟีเจอร์ของ JavaScript ที่ช่วยให้ฟังก์ชันสามารถประมวลผล template string ที่มี expression ฝังอยู่ได้ โดยให้วิธีการสร้างภาษาเฉพาะโดเมนภายใน JavaScript
โมเดลการตอบสนองที่เสนอ:
- Virtual DOM Diffing: ใช้โดย React ช้ากว่าแต่คุ้นเคย
- Template Identity: ใช้โดย Lit เร็วกว่าพร้อมความหมายที่เรียบง่าย
- Signals: การตอบสนองแบบละเอียด เร็วที่สุดแต่ต้องการการห่อหุ้มข้อมูล
- แนวทางที่แนะนำ: การผสมผสานระหว่าง template identity กับ signals
ความกังวลของชุมชนเกี่ยวกับการทำมาตรฐาน
ชุมชนนักพัฒนาเว็บยังคงแบ่งแยกความเห็นว่า native templating มาเร็วเกินไปหรือไม่ บางคนโต้แย้งว่านวัตกรรม framework ยังคงเกิดขึ้นอย่างรวดเร็ว ทำให้ยังเร็วเกินไปที่จะล็อคแนวทางเฉพาะเจาะจง คนอื่นๆ กังวลเกี่ยวกับการทำผิดพลาดซ้ำเหมือนในอดีตกับ Web Components ซึ่งหลายคนมองว่าถูกออกแบบมาซับซ้อนเกินไปและไม่ได้ใช้งานเท่าที่ควร
เว็บต้องการ native templating, reactivity และ data binding จริงๆ ฉันไม่สามารถจินตนาการได้เลยว่า CPU และแบนด์วิดท์ถูกสูญเสียไปมากแค่ไหนกับผู้ใช้หลายพันล้านคนที่ดาวน์โหลด แยกวิเคราะห์ และรันสิ่งอย่าง React
นักวิจารณ์ยังชี้ให้เห็นว่าการเพิ่มฟีเจอร์เข้าไปในมาตรฐานเว็บสร้างภาระการบำรุงรักษาถาวรให้กับผู้ผลิตเบราว์เซอร์และทำให้โปรเจกต์เบราว์เซอร์ใหม่แข่งขันได้ยากขึ้น API ใหม่ทุกตัวต้องถูก implement และบำรุงรักษาในเบราว์เซอร์หลักทั้งหมด ทำให้ความซับซ้อนเพิ่มขึ้นอย่างไม่มีที่สิ้นสุด
บริบททางประวัติศาสตร์และบทเรียนที่ได้เรียนรู้
การอภิปรายมักอ้างอิงถึงความพยายามในอดีตที่มีฟังก์ชันคล้ายกัน โดยเฉพาะ XSLT และ XUL framework ของ Mozilla XSLT ให้ความสามารถในการแปลง XML ที่ทรงพลังแต่ประสบปัญหาจากเส้นโค้งการเรียนรูที่สูงชันและ syntax ที่ยาวเยิ่ม XUL ช่วยให้สามารถพัฒนาแอปพลิเคชันที่หลากหลายได้แต่ยังคงเป็นเฉพาะ Firefox และในที่สุดก็ถูกยกเลิก
ตัวอย่างทางประวัติศาสตร์เหล่านี้เน้นย้ำทั้งประโยชน์ที่เป็นไปได้และข้อผิดพลาดของ native templating solution แม้ว่าจะแสดงให้เห็นว่าระบบเช่นนี้สามารถทำงานได้อย่างมีประสิทธิภาพ แต่ก็แสดงให้เห็นว่าการสร้าง solution ที่ได้รับการยอมรับอย่างกว้างขวางและยังคงบำรุงรักษาได้ในระยะยาวนั้นยากเพียงใด
ตัวเลือกการพัฒนาทางเทคนิค:
- Syntax: Tagged template literals (คุณสมบัติที่มีอยู่แล้วใน JavaScript )
- Target: API ที่ใช้ JavaScript แทนที่จะเป็น HTML
- Dependencies: ต้องการให้ข้อเสนอ DOM Parts เสร็จสมบูรณ์
- Browser Support: จำเป็นต้องมีการพัฒนาในเบราว์เซอร์หลักทุกตัว
เส้นทางข้างหน้ายังคงไม่แน่นอน
ข้อเสนอนี้แสดงถึงงานสำคัญที่ต้องการความร่วมมือระหว่างผู้ผลิตเบราว์เซอร์ ผู้เขียน framework และชุมชนนักพัฒนาเว็บในวงกว้าง ความสำเร็จจะขึ้นอยู่กับการหาจุดร่วมระหว่างแนวทางที่แข่งขันกัน ในขณะที่ต้องแน่ใจว่า solution ยังคงมีความยืดหยุ่นเพียงพอที่จะพัฒนาไปตามความต้องการในอนาคต
ยังไม่ทราบแน่ชัดว่าความคิดริเริ่มนี้จะได้รับแรงผลักดันที่จำเป็นสำหรับการทำมาตรฐานหรือไม่ ประวัติศาสตร์ของแพลตฟอร์มเว็บแสดงให้เห็นว่าการเพิ่มเติมที่ประสบความสำเร็จมักต้องการทั้งความต้องการที่ชัดเจนจากนักพัฒนาและเส้นทางการ implement ที่ปฏิบัติได้ซึ่งไม่ส่งผลกระทบต่อฟังก์ชันที่มีอยู่