ชุมชนนักพัฒนาเว็บกำลังมีส่วนร่วมในการอภิปรายอย่างเข้มข้นเกี่ยวกับทิศทางอนาคตของ HTML, CSS และ Document Object Model (DOM) การถกเถียงครั้งนี้เกิดขึ้นจากความกังวลที่เพิ่มขึ้นเกี่ยวกับความซับซ้อนที่เพิ่มมากขึ้นของมาตรฐานเว็บ และว่าพื้นฐานปัจจุบันเหมาะสมสำหรับการพัฒนาแอปพลิเคชันสมัยใหม่หรือไม่
 |
|---|
| สไลด์การนำเสนอที่แสดงคุณสมบัติ CSS layout ต่างๆ และผลกระทบต่อมาตรฐานเว็บ |
ภาวะที่กลืนไม่เข้าคายไม่ออกของการรองรับเวอร์ชันเก่า
หนึ่งในประเด็นหลักของการถกเถียงครั้งนี้เกี่ยวข้องกับการรองรับเวอร์ชันเก่า แพลตฟอร์มเว็บได้รักษาความเข้ากันได้กับโค้ดที่มีอายุหลายสิบปี ซึ่งเป็นทั้งพรและคำสาป แม้ว่าแนวทางนี้จะทำให้เว็บไซต์จากยุคแรกๆ ของอินเทอร์เน็ตยังคงทำงานได้ แต่ก็นำไปสู่ความซับซ้อนและความล้นเหลือที่สำคัญในมาตรฐานเว็บสมัยใหม่ ชุมชนแบ่งออกเป็นสองฝ่ายเกี่ยวกับว่าความมุ่งมั่นในการรองรับเวอร์ชันเก่านี้คุ้มค่ากับหนี้ทางเทคนิคที่เกิดขึ้นหรือไม่
นักพัฒนาบางคนโต้แย้งว่าการรองรับเวอร์ชันเก่าสามารถรักษาไว้ได้ผ่านไลบรารี polyfill ที่อยู่บนระบบใหม่ คล้ายกับวิธีที่ฟีเจอร์ JavaScript สมัยใหม่ถูกทำให้ใช้งานได้กับเบราว์เซอร์เก่า แนวทางนี้อาจช่วยให้มีระบบหลักที่สะอาดและมีประสิทธิภาพมากขึ้น ในขณะที่ยังคงรองรับโค้ดเก่าได้
โซลูชันที่เสนอและทางเลือกอื่น:
| แนวทาง | คำอธิบาย | ข้อแลกเปลี่ยน |
|---|---|---|
| การเรนเดอร์แบบ Canvas-based | ข้ามการใช้ HTML/CSS ทั้งหมด เรนเดอร์โดยตรงไปยัง canvas | ประสิทธิภาพดีกว่า แต่สูญเสียฟีเจอร์การเข้าถึง |
| มาตรฐานแยกสำหรับแอป/เอกสาร | API ที่แตกต่างกันสำหรับแอปพลิเคชันและเอกสาร | สามารถลดความซับซ้อน แต่เพิ่มการแยกส่วน |
| WebAssembly + WebGPU | ใช้เทคโนโลยีระดับต่ำกว่าเพื่อการควบคุมที่ดีกว่า | การพัฒนาซับซ้อนมากขึ้น แต่อาจมีประสิทธิภาพดีกว่า |
| ความเข้ากันได้แบบ Polyfill-based | ระบบหลักใหม่พร้อมชั้นความเข้ากันได้ | สามารถเปิดใช้สถาปัตยกรรมที่สะอาดกว่าในขณะที่รักษาความเข้ากันได้แบบย้อนหลัง |
ความแตกแยกระหว่างแอปพลิเคชันกับเอกสาร
ประเด็นสำคัญที่เป็นจุดขัดแย้งคือว่าเว็บควรจะพยายามให้บริการทั้งเอกสารและแอปพลิเคชันด้วยเทคโนโลยีเดียวกันต่อไปหรือไม่ สมาชิกชุมชนหลายคนเชื่อว่า HTML ถูกออกแบบมาสำหรับเอกสารในตอนแรก และถูกยืดเยื้อเกินจุดประสงค์เดิมเพื่อรองรับแอปพลิเคชันที่ซับซ้อน
ปัญหาคือ DOM ไม่เพียงพอโดยสิ้นเชิงสำหรับการอธิบายการจัดวางหน้า และยิ่งไม่เพียงพอสำหรับแอปพลิเคชันเว็บ ผู้ใช้มักไม่พอใจกับแอปพลิเคชันเว็บเนื่องจากวิธีที่เบราว์เซอร์จำกัดฟังก์ชันการทำงานที่มีประโยชน์ และโปรแกรมเมอร์ต้องดิ้นรนกับการแก้ไขปัญหาชั่วคราวและความล้นเหลือของเบราว์เซอร์เพื่อทำสิ่งง่ายๆ ให้สำเร็จ
สิ่งนี้นำไปสู่ข้อเสนอแนะในการสร้างมาตรฐานแยกกัน - หนึ่งที่ปรับให้เหมาะสมสำหรับหน้าเว็บแบบดั้งเดิม และอีกหนึ่งที่ออกแบบมาเฉพาะสำหรับแอปพลิเคชัน การแยกแบบนี้อาจช่วยให้แต่ละกรณีการใช้งานได้รับการบริการที่ดีขึ้นด้วยเทคโนโลยีที่ออกแบบมาเฉพาะสำหรับความต้องการของตน
เทคโนโลยีเว็บหลักที่อยู่ในการอภิปราย:
- DOM (Document Object Model): อินเทอร์เฟซการเขียนโปรแกรมสำหรับเอกสาร HTML ที่แสดงโครงสร้างหน้าเว็บในรูปแบบต้นไม้ของออบเจ็กต์
- WebAssembly (WASM): รูปแบบคำสั่งแบบไบนารีที่ช่วยให้โค้ดที่เขียนด้วยภาษาอื่นนอกเหนือจาก JavaScript สามารถทำงานในเว็บเบราว์เซอร์ได้
- WebGPU: มาตรฐานเว็บสำหรับเข้าถึงคุณสมบัติของหน่วยประมวลผลกราฟิก (GPU) จากแอปพลิเคชันเว็บ
- CSS Grid: ระบบเลย์เอาต์ที่ช่วยให้นักพัฒนาสามารถสร้างเลย์เอาต์แบบกริดที่ซับซ้อนได้
- Flexbox: วิธีการจัดเลย์เอาต์ CSS สำหรับจัดเรียงรายการในแถวหรือคอลัมน์ด้วยการปรับขนาดแบบยืดหยุ่น
 |
|---|
| ผังงานที่แสดงกระบวนการจัดวางแบบเก็งกำไร โดยเน้นให้เห็นว่าส่วนต่างๆ ของเว็บแอปพลิเคชันมีปฏิสัมพันธ์กันอย่างไร |
ความกังวลเรื่องประสิทธิภาพและประสบการณ์นักพัฒนา
ชุมชนได้แสดงความกังวลอย่างมากเกี่ยวกับผลกระทบด้านประสิทธิภาพของเทคโนโลยีเว็บปัจจุบัน แอปพลิเคชันเว็บสมัยใหม่มักต้องการทรัพยากรจำนวนมากเพื่อทำงานที่จะเป็นเรื่องง่ายในแอปพลิเคชันดั้งเดิม สิ่งนี้นำไปสู่ความหงุดหงิดในหมู่นักพัฒนาที่พบว่าตนเองต้องต่อสู้กับแพลตฟอร์มแทนที่จะทำงานร่วมกับมัน
DOM API ถูกวิพากษ์วิจารณ์เป็นพิเศษว่าใช้คำพูดมากและยากต่อการทำงานโดยตรง นักพัฒนาหลายคนได้หันไปใช้เฟรมเวิร์กที่ทำนามธรรมความซับซ้อนเหล่านี้แทนการจัดการ DOM โดยตรง แต่สิ่งนี้นำไปสู่ชั้นของการทำนามธรรมเพิ่มเติมและขนาดบันเดิลที่เพิ่มขึ้น
ทางเลือกและโซลูชันที่เกิดขึ้นใหม่
โซลูชันที่มีศักยภาพหลายอย่างได้เกิดขึ้นจากการอภิปรายของชุมชน WebAssembly (WASM) และ WebGPU กำลังถูกสำรวจเป็นวิธีการให้การควบคุมการเรนเดอร์และการคำนวณโดยตรงมากขึ้น นักพัฒนาบางคนกำลังทดลองกับแนวทางที่ใช้ canvas ที่หลีกเลี่ยงการเรนเดอร์ HTML แบบดั้งเดิมโดยสิ้นเชิง
Flutter for web ถูกอ้างถึงเป็นตัวอย่างของวิธีที่แอปพลิเคชันสามารถถูกสร้างขึ้นโดยใช้การเรนเดอร์ canvas ในขณะที่ยังคงทำงานในเบราว์เซอร์ อย่างไรก็ตาม แนวทางนี้มาพร้อมกับข้อแลกเปลี่ยน โดยเฉพาะอย่างยิ่งเกี่ยวกับฟีเจอร์การเข้าถึงเช่นการตรวจสอบการสะกดและการรองรับวิธีการป้อนข้อมูลที่เบราว์เซอร์ให้โดยอัตโนมัติสำหรับองค์ประกอบ HTML แบบดั้งเดิม
 |
|---|
| มุมมองทางเทคนิคของโครงสร้าง HTML ของตัวแก้ไขอินพุตของเว็บแอปพลิเคชัน โดยเน้นมาตรฐานเว็บปัจจุบัน |
เส้นทางไปข้างหน้า
ชุมชนดูเหมือนจะรวมตัวกันรอบแนวคิดที่ว่าการวิวัฒนาการมากกว่าการปฏิวัติอาจเป็นแนวทางที่ปฏิบัติได้มากที่สุด แม้ว่าหลายคนจะยอมรับข้อจำกัดของเทคโนโลยีเว็บปัจจุบัน แต่ระบบนิเวศขนาดใหญ่และข้อได้เปรียบในการปรับใช้ของแพลตฟอร์มเว็บทำให้ยากที่จะละทิ้งโดยสิ้นเชิง
นักพัฒนาบางคนสนับสนุนการปรับปรุงแบบค่อยเป็นค่อยไปและ API ใหม่ที่สามารถอยู่ร่วมกับมาตรฐานที่มีอยู่ ในขณะที่คนอื่นผลักดันให้เกิดการเปลี่ยนแปลงที่มีพื้นฐานมากขึ้น ความสำเร็จของเทคโนโลยีเช่น CSS Grid และ Flexbox ซึ่งได้ปรับปรุงความสามารถในการจัดวางอย่างมีนัยสำคัญ แสดงให้เห็นว่าความก้าวหน้าที่มีความหมายสามารถทำได้ภายในกรอบที่มีอยู่
การถกเถียงนี้สะท้อนความตึงเครียดที่กว้างขึ้นในอุตสาหกรรมเทคโนโลยีระหว่างการรักษาเสถียรภาพและการผลักดันนวัตกรรม ขณะที่แอปพลิเคชันเว็บกลายเป็นสิ่งที่ซับซ้อนมากขึ้น ชุมชนยังคงต่อสู้กับวิธีการสร้างสมดุลระหว่างความต้องการที่แข่งขันกันเหล่านี้ในขณะที่ให้บริการทั้งนักพัฒนาและผู้ใช้ปลายทางอย่างมีประสิทธิภาพ
อ้างอิง: HTML is Dead, Long Live HTML