การอภิปรายที่เพิ่มขึ้นในชุมชนนักพัฒนาเว็บมีจุดศูนย์กลางอยู่ที่ว่าแอปพลิเคชันสมัยใหม่มีความซับซ้อนเกินความจำเป็นหรือไม่ เมื่อพึ่งพา JavaScript framework อย่างหนักในขณะที่โซลูชัน HTML ที่เรียบง่ายกว่าอาจเพียงพอ การถกเถียงนี้เน้นย้ำถึงความตึงเครียดพื้นฐานระหว่างแนวปฏิบัติการพัฒนาเว็บแบบดั้งเดิมและแนวทางที่เน้น JavaScript หนักในยุคปัจจุบัน
ความท้าทายด้านความสามารถในการขยายตัว
นักพัฒนาหลายคนโต้แย้งว่าแนวทางที่เน้น HTML เป็นหลักเผชิญกับข้อจำกัดที่สำคัญในสภาพแวดล้อมของทีมและแอปพลิเคชันขนาดใหญ่ ความกังวลหลักหมุนรอบการบำรุงรักษาและการนำโค้ดกลับมาใช้ใหม่ เมื่อนักพัฒนาหลายคนทำงานในโปรเจกต์ การคัดลอกและวาง HTML markup กลายเป็นฝันร้ายในการบำรุงรักษา นำไปสู่การจัดรูปแบบที่ไม่สอดคล้องกันและโค้ดที่ซ้ำซ้อนข้ามหน้าต่างๆ ความท้าทายนี้ยิ่งชัดเจนมากขึ้นเมื่อทีมต้องการสร้างคอมโพเนนต์ที่สามารถนำกลับมาใช้ใหม่ได้และสามารถแชร์ข้ามส่วนต่างๆ ของแอปพลิเคชัน
ปัญหาความสามารถในการขยายตัวขยายเกินไปจากเพียงการจัดระเบียบโค้ด ในสภาพแวดล้อมที่มีหลายบริการและหลายทีม การให้บริการแบ็กเอนด์สร้าง HTML ก่อให้เกิดความท้าทายในการประสานงานที่ไม่มีอยู่กับ JSON API ทีมต่างๆ สูญเสียความยืดหยุ่นในการพัฒนาและปรับใช้คอมโพเนนต์ฟรอนต์เอนด์และแบ็กเอนด์อย่างอิสระ
การเปรียบเทียบ HTML กับ JavaScript สำหรับฟอร์ม
| ด้าน | แนวทาง HTML | แนวทาง JavaScript Framework |
|---|---|---|
| ความซับซ้อนของโค้ด | น้อยที่สุด แบบ declarative | สูงกว่า ต้องจัดการ state |
| ความเร็วในการโหลด | โหลดเริ่มต้นเร็วกว่า | ช้ากว่าเนื่องจาก framework overhead |
| การเข้าถึง | มีในตัว (การส่งด้วยปุ่ม enter) | ต้องพัฒนาเองด้วยตนเอง |
| การตรวจสอบข้อมูล | การตรวจสอบพื้นฐานของ HTML5 | สามารถสร้างการตรวจสอบแบบกำหนดเองที่ซับซ้อนได้ |
| การนำกลับมาใช้ใหม่ | จำกัดหากไม่มี templating | การนำ component กลับมาใช้ใหม่สูง |
| การขยายตัวของทีม | ท้าทายสำหรับทีมขนาดใหญ่ | ดีกว่าสำหรับการพัฒนาแบบ component-based |
ข้อกังวลเรื่องการออกแบบ API และการแยกข้อมูล
จุดขัดแย้งที่สำคัญเกี่ยวข้องกับว่าเซิร์ฟเวอร์ควรส่งคืนข้อมูล HTML หรือ JSON ผู้สนับสนุน JSON API เน้นย้ำการแยกระหว่างข้อมูลและการนำเสนอ โดยโต้แย้งว่าแนวทางนี้ให้ความยืดหยุ่นมากขึ้นสำหรับแอปพลิเคชันไคลเอนต์ที่แตกต่างกัน เมื่อเซิร์ฟเวอร์ส่งคืน HTML ไคลเอนต์จะถูกล็อคเข้ากับตัวเลือกการนำเสนอของเซิร์ฟเวอร์ ทำให้ยากที่จะเรนเดอร์ข้อมูลเดียวกันในรูปแบบที่แตกต่างกันข้ามอินเทอร์เฟซหรือแพลตฟอร์มต่างๆ
อย่างไรก็ตาม ผู้สนับสนุนการตอบสนอง HTML โต้แย้งว่าการแยกนี้มักสร้างความซับซ้อนที่ไม่จำเป็น พวกเขาชี้ให้เห็นว่าแบ็กเอนด์เดียวกันสามารถให้บริการทั้ง HTML และ JSON โดยใช้การเจรจาเนื้อหาผ่าน HTTP Accept header ทำให้ไคลเอนต์สามารถขอรูปแบบที่ต้องการได้
การแลกเปลี่ยนระหว่างการตรวจสอบและประสบการณ์ผู้ใช้
การอภิปรายเผยให้เห็นมุมมองที่น่าสนใจเกี่ยวกับการตรวจสอบฟอร์มและการตอบรับของผู้ใช้ ในขณะที่ HTML ให้ความสามารถในการตรวจสอบพื้นฐานผ่าน attribute เช่น required และประเภทอินพุต แอปพลิเคชันที่ซับซ้อนมักต้องการตรรกะการตรวจสอบที่ซับซ้อนกว่า การตรวจสอบฝั่งไคลเอนต์ทำหน้าที่เป็นหลักในการเพิ่มประสบการณ์ผู้ใช้ โดยให้ข้อมูลป้อนกลับทันทีโดยไม่ต้องเดินทางไปเซิร์ฟเวอร์
การตรวจสอบฝั่งไคลเอนต์เป็นการปรับปรุงแบบก้าวหน้า คุณมีการตรวจสอบฝั่งเซิร์ฟเวอร์เสมอ การตรวจสอบในเบราว์เซอร์มีอยู่เพื่อให้ข้อมูลป้อนกลับเพิ่มเติมที่ช่วยให้ผู้ใช้ได้รับข้อมูลป้อนกลับแบบเรียลไทม์เกี่ยวกับการป้อนข้อมูลของพวกเขา
แนวทางนี้รับทราบว่าการตรวจสอบที่แท้จริงต้องเกิดขึ้นที่ฝั่งเซิร์ฟเวอร์เสมอเพื่อเหตุผลด้านความปลอดภัย ในขณะที่การตรวจสอบฝั่งไคลเอนต์ปรับปรุงประสบการณ์ผู้ใช้โดยการตรวจจับข้อผิดพลาดตั้งแต่เนิ่นๆ
การพิจารณาประสิทธิภาพและแบนด์วิดท์
การถกเถียงด้านประสิทธิภาพมีจุดศูนย์กลางอยู่ที่ว่าการส่ง HTML ที่เรนเดอร์แล้วหรือข้อมูล JSON มีประสิทธิภาพมากกว่า การตอบสนอง HTML ขจัดความจำเป็นในการเรนเดอร์ฝั่งไคลเอนต์ ซึ่ง JSON จะถูกแยกวิเคราะห์ ประมวลผล และแปลงเป็น HTML อย่างไรก็ตาม JSON สามารถมีประสิทธิภาพแบนด์วิดท์มากกว่าสำหรับแอปพลิเคชันที่แคชตรรกะการนำเสนอและต้องการอัปเดตเฉพาะข้อมูล
สมการประสิทธิภาพกลายเป็นเรื่องซับซ้อนมากขึ้นเมื่อพิจารณาคุณสมบัติเช่นการเรียงลำดับ การกรอง และการจัดการข้อมูลฝั่งไคลเอนต์ การดำเนินการเหล่านี้ทำงานได้อย่างราบรื่นกว่ากับโครงสร้างข้อมูล JSON มากกว่าตาราง HTML ที่เรนเดอร์แล้ว
เทคโนโลยี Progressive Enhancement
- HTMX: ช่วยให้ HTML สามารถส่งคำขอ AJAX และอัปเดตเนื้อหาในหน้าเว็บได้
- Alpine.js: เฟรมเวิร์ก JavaScript ขนาดเล็กสำหรับเพิ่มการโต้ตอบ
- Web Components: เทคโนโลยีดั้งเดิมของเบราว์เซอร์สำหรับสร้างองค์ประกอบ HTML ที่นำกลับมาใช้ได้
- Server-Side Rendering (SSR): สร้าง HTML บนเซิร์ฟเวอร์ แล้วเสริมด้วย JavaScript
- Backend-for-Frontend (BFF): ชั้นแบ็กเอนด์เฉพาะสำหรับตอบสนองความต้องการของฟรอนต์เอนด์
จุดกึ่งกลาง: การปรับปรุงแบบก้าวหน้า
นักพัฒนาที่มีประสบการณ์หลายคนสนับสนุนแนวทางที่สมดุลซึ่งรวมสิ่งที่ดีที่สุดของทั้งสองโลก เทคโนโลยีเช่น HTMX และ Alpine.js ช่วยให้นักพัฒนาสามารถปรับปรุง HTML ด้วยคุณสมบัติแบบโต้ตอบโดยไม่ต้องสร้างแอปพลิเคชัน JavaScript เต็มรูปแบบ กลยุทธ์การปรับปรุงแบบก้าวหน้านี้เริ่มต้นด้วย HTML ที่ทำงานได้และเพิ่มฟังก์ชัน JavaScript ตามที่จำเป็น
การอภิปรายสะท้อนถึงแนวโน้มอุตสาหกรรมที่กว้างขึ้นในการตั้งคำถามว่าความซับซ้อนของ JavaScript framework สมัยใหม่มีเหตุผลเสมอหรือไม่ ในขณะที่เครื่องมือเหล่านี้เก่งในการสร้างแอปพลิเคชันแบบโต้ตอบที่ซับซ้อน พวกมันอาจเป็นเรื่องเกินความจำเป็นสำหรับเว็บไซต์และฟอร์มที่เรียบง่ายที่สามารถทำงานได้อย่างสมบูรณ์แบบกับ HTML ที่ปรับปรุงแล้วและ JavaScript เพียงเล็กน้อย
การถกเถียงในที่สุดเน้นย้ำว่าการเลือกเทคโนโลยีควรตรงกับความต้องการของโปรเจกต์มากกว่าการติดตามแนวโน้มอุตสาหกรรม โปรเจกต์ง่ายๆ ได้รับประโยชน์จากโซลูชันง่ายๆ ในขณะที่แอปพลิเคชันที่ซับซ้อนอาจต้องการพลังและความยืดหยุ่นที่ JavaScript framework สมัยใหม่ให้จริงๆ
อ้างอิง: Just use HTML