Một cuộc thảo luận ngày càng sôi nổi trong cộng đồng phát triển web xoay quanh việc liệu các ứng dụng hiện đại có trở nên phức tạp một cách không cần thiết khi phụ thuộc quá nhiều vào các framework JavaScript trong khi các giải pháp HTML đơn giản có thể đã đủ. Cuộc tranh luận này làm nổi bật sự căng thẳng cơ bản giữa các thực hành phát triển web truyền thống và các phương pháp tiếp cận hiện đại dựa nhiều vào JavaScript.
Thách Thức Về Khả Năng Mở Rộng
Nhiều nhà phát triển cho rằng các phương pháp tiếp cận HTML-first gặp phải những hạn chế đáng kể trong môi trường làm việc nhóm và các ứng dụng lớn hơn. Mối quan tâm cốt lõi xoay quanh khả năng bảo trì và tái sử dụng mã. Khi nhiều nhà phát triển làm việc trên các dự án, việc sao chép-dán markup HTML trở thành một cơn ác mộng bảo trì, dẫn đến styling không nhất quán và mã bị trùng lặp trên các trang. Thách thức này trở nên rõ rệt hơn khi các nhóm cần tạo ra các component có thể tái sử dụng để chia sẻ qua các phần khác nhau của ứng dụng.
Vấn đề khả năng mở rộng không chỉ dừng lại ở tổ chức mã. Trong môi trường có nhiều dịch vụ và nhóm, việc để các backend service tạo ra HTML sẽ tạo ra những thách thức phối hợp mà không tồn tại với các JSON API. Các nhóm mất đi tính linh hoạt để phát triển và triển khai độc lập các component frontend và backend.
So sánh HTML và JavaScript cho Forms
| Khía cạnh | Cách tiếp cận HTML | Cách tiếp cận JavaScript Framework |
|---|---|---|
| Độ phức tạp của code | Tối thiểu, khai báo | Cao hơn, yêu cầu quản lý state |
| Tốc độ tải | Tải ban đầu nhanh hơn | Chậm hơn do overhead của framework |
| Khả năng tiếp cận | Tích hợp sẵn (submit bằng phím enter) | Yêu cầu triển khai thủ công |
| Validation | Validation HTML5 cơ bản | Có thể validation tùy chỉnh phức tạp |
| Khả năng tái sử dụng | Hạn chế nếu không có templating | Tái sử dụng component cao |
| Khả năng mở rộng team | Thách thức với team lớn | Tốt hơn cho phát triển dựa trên component |
Mối Quan Ngại Về Thiết Kế API và Tách Biệt Dữ Liệu
Một điểm tranh cãi đáng kể liên quan đến việc liệu server nên trả về dữ liệu HTML hay JSON. Những người ủng hộ JSON API nhấn mạnh sự tách biệt giữa dữ liệu và trình bày, cho rằng phương pháp này cung cấp tính linh hoạt lớn hơn cho các ứng dụng client khác nhau. Khi server trả về HTML, client bị khóa vào các lựa chọn trình bày của server, khiến việc render cùng một dữ liệu theo cách khác nhau trên các giao diện hoặc nền tảng khác nhau trở nên khó khăn.
Tuy nhiên, những người ủng hộ phản hồi HTML phản bác rằng sự tách biệt này thường tạo ra độ phức tạp không cần thiết. Họ chỉ ra rằng cùng một backend có thể phục vụ cả HTML và JSON bằng cách sử dụng content negotiation thông qua HTTP Accept headers, cho phép client yêu cầu định dạng mà họ cần.
Đánh Đổi Về Validation và Trải Nghiệm Người Dùng
Cuộc thảo luận tiết lộ những quan điểm thú vị về validation form và phản hồi người dùng. Trong khi HTML cung cấp khả năng validation cơ bản thông qua các thuộc tính như required và các loại input, các ứng dụng phức tạp thường cần logic validation tinh vi hơn. Validation phía client chủ yếu phục vụ như một cải tiến trải nghiệm người dùng, cung cấp phản hồi tức thì mà không cần round trip đến server.
Validation phía client là một progressive enhancement. Bạn luôn có validation phía server. Validation trong trình duyệt tồn tại để cung cấp phản hồi bổ sung cho phép người dùng có phản hồi realtime về input của họ.
Phương pháp này nhận ra rằng validation thực sự phải luôn xảy ra phía server vì lý do bảo mật, trong khi các kiểm tra phía client cải thiện trải nghiệm người dùng bằng cách phát hiện lỗi sớm.
Cân Nhắc Về Hiệu Suất và Băng Thông
Cuộc tranh luận về hiệu suất tập trung vào việc liệu gửi HTML được render sẵn hay dữ liệu JSON có hiệu quả hơn. Phản hồi HTML loại bỏ nhu cầu về các chu kỳ rendering phía client, nơi JSON được parse, xử lý và chuyển đổi thành HTML. Tuy nhiên, JSON có thể hiệu quả hơn về băng thông cho các ứng dụng cache logic trình bày và chỉ cần cập nhật dữ liệu.
Phương trình hiệu suất trở nên phức tạp hơn khi xem xét các tính năng như sắp xếp, lọc và thao tác dữ liệu phía client. Các thao tác này hoạt động mượt mà hơn với cấu trúc dữ liệu JSON so với các bảng HTML được render sẵn.
Công nghệ Tăng cường Tiến bộ
- HTMX: Cho phép HTML thực hiện các yêu cầu AJAX và cập nhật nội dung trang
- Alpine.js: Framework JavaScript nhẹ để thêm tính tương tác
- Web Components: Công nghệ trình duyệt gốc để tạo các phần tử HTML có thể tái sử dụng
- Server-Side Rendering (SSR): Tạo HTML trên máy chủ, tăng cường bằng JavaScript
- Backend-for-Frontend (BFF): Lớp backend chuyên dụng cho các nhu cầu frontend cụ thể
Con Đường Trung Dung: Progressive Enhancement
Nhiều nhà phát triển có kinh nghiệm ủng hộ phương pháp cân bằng kết hợp điều tốt nhất của cả hai thế giới. Các công nghệ như HTMX và Alpine.js cho phép các nhà phát triển nâng cao HTML với các tính năng tương tác mà không cần xây dựng các ứng dụng JavaScript đầy đủ. Chiến lược progressive enhancement này bắt đầu với HTML hoạt động và thêm chức năng JavaScript khi cần thiết.
Cuộc thảo luận phản ánh một xu hướng rộng lớn hơn trong ngành về việc đặt câu hỏi liệu độ phức tạp của các framework JavaScript hiện đại có luôn được biện minh hay không. Trong khi các công cụ này xuất sắc trong việc xây dựng các ứng dụng tương tác phức tạp, chúng có thể quá mức cần thiết cho các trang web và form đơn giản có thể hoạt động hoàn hảo với HTML được nâng cao và JavaScript tối thiểu.
Cuộc tranh luận cuối cùng làm nổi bật rằng các lựa chọn công nghệ nên phù hợp với yêu cầu dự án thay vì theo xu hướng ngành. Các dự án đơn giản được hưởng lợi từ các giải pháp đơn giản, trong khi các ứng dụng phức tạp có thể thực sự cần sức mạnh và tính linh hoạt mà các framework JavaScript hiện đại cung cấp.
Tham khảo: Just use HTML