Trong thế giới phát triển web luôn thay đổi, một cuộc tranh luận nóng hổi đã tái xuất xoay quanh ưu điểm của việc sử dụng JavaScript thuần so với các framework phổ biến như React, Vue, hoặc Svelte. Cuộc thảo luận tập trung vào một mô hình được gọi là Writing JavaScript Views the Hard Way (Viết giao diện JavaScript theo cách khó), phương pháp này ủng hộ việc thao tác DOM trực tiếp bằng JavaScript thuần thay vì dựa vào các lớp trừu tượng do các framework cung cấp.
 |
|---|
| Kho lưu trữ GitHub cho "Writing JavaScript Views the Hard Way," nổi bật như một dự án quan trọng trong cuộc tranh luận giữa JavaScript thuần túy và các framework |
Sức hấp dẫn của việc không sử dụng Framework
Nhiều nhà phát triển trong cộng đồng bày tỏ sự nhiệt tình khi từ bỏ các framework để sử dụng JavaScript thuần. Họ đề cập đến những lợi ích đáng kể về hiệu suất, việc gỡ lỗi dễ dàng hơn và kết nối trực tiếp hơn với nền tảng web. Một nhà phát triển đã chia sẻ trải nghiệm gần đây của họ khi xây dựng ứng dụng bằng TypeScript thuần với Vite, lưu ý rằng họ ngày càng đặt câu hỏi về các phương pháp tốt nhất cho front end sau khi thấy được lợi ích của phương pháp trực tiếp. Sức hấp dẫn không chỉ nằm ở những lợi thế kỹ thuật mà còn bao gồm lợi ích giáo dục, vì làm việc trực tiếp với DOM buộc các nhà phát triển phải hiểu sâu hơn về các công nghệ web cơ bản.
Tôi không thể kết luận nó có khả năng mở rộng hay không, dù điều đó có nghĩa là gì, nhưng tôi có thể kết luận rằng có những lợi ích to lớn về hiệu suất, nó thú vị, dạy cho bạn nhiều điều, việc gỡ lỗi đơn giản, hiểu kiến trúc là điều đơn giản, bạn không cần phải có bằng tiến sĩ về kỹ thuật render/memoization/v.v.
Lợi ích của "Viết JavaScript Views theo cách khó"
- Hiệu suất: Hiệu suất gần như tối ưu với các thao tác không cần thiết được giảm thiểu
- Không phụ thuộc: Không cần nâng cấp hoặc quản lý các thư viện bên ngoài
- Tính di động: Mã có thể được sử dụng với bất kỳ framework nào
- Khả năng bảo trì: Tuân theo các quy ước nghiêm ngặt để tổ chức mã một cách dễ dự đoán
- Hỗ trợ trình duyệt: Tương thích với tất cả các trình duyệt (với các tùy chọn tương thích cho trình duyệt cũ hơn)
- Gỡ lỗi dễ dàng hơn: Các stack trace nông giúp việc theo dõi vấn đề đơn giản hơn
- Phương pháp tiếp cận hàm: Sử dụng các hàm đơn giản mà không có hệ thống phân cấp lớp phức tạp
DOM như một nguồn dữ liệu chính
Một mô hình thú vị xuất hiện trong cuộc thảo luận là sử dụng chính DOM như nguồn dữ liệu chính cho trạng thái ứng dụng, thay vì duy trì các biến trạng thái riêng biệt. Một số nhà phát triển ủng hộ việc đọc và ghi trực tiếp vào các phần tử DOM thông qua getters và setters thay vì giữ các biến JavaScript riêng biệt cần được đồng bộ hóa với DOM. Phương pháp này loại bỏ nhu cầu duy trì trạng thái ở hai nơi nhưng làm dấy lên lo ngại về khả năng dễ bị tổn thương trước các tiện ích mở rộng trình duyệt có thể sửa đổi DOM một cách bất ngờ, hoặc thách thức khi xử lý trạng thái dư thừa trên nhiều thành phần UI.
Mối quan ngại về khả năng bảo trì
Mặc dù phương pháp Hard Way hứa hẹn sự đơn giản, nhiều nhà phát triển bày tỏ sự hoài nghi về khả năng bảo trì của nó trong môi trường làm việc nhóm và các ứng dụng lớn hơn. Mô hình này phụ thuộc nhiều vào các quy ước hơn là cấu trúc bắt buộc, điều này có thể dẫn đến sự không nhất quán khi các thành viên khác nhau trong nhóm đóng góp vào codebase. Như một người bình luận đã chỉ ra, mẫu thiết kế này chỉ dựa trên quy ước. Điều này có nghĩa là nhà phát triển có thể tự do đi chệch khỏi quy ước bất cứ khi nào họ muốn. Điều này trái ngược với các framework buộc phải tuân theo các mẫu nhất định thông qua API và công cụ của chúng.
Quản lý trạng thái: Thách thức thực sự
Một chủ đề lặp lại trong các bình luận là khó khăn thực sự trong phát triển frontend không phải là tạo các phần tử DOM mà là quản lý trạng thái và giữ cho UI đồng bộ với trạng thái đó. Các framework phản ứng tồn tại chính xác để giải quyết vấn đề này. Khi ứng dụng trở nên phức tạp hơn, việc theo dõi thủ công những phần nào của UI cần cập nhật khi trạng thái thay đổi trở nên ngày càng khó khăn. Một nhà phát triển lưu ý rằng vấn đề cơ bản là khi một phần trạng thái thay đổi, tất cả UI phụ thuộc vào trạng thái đó cần được cập nhật, và việc duy trì các hàm cập nhật này theo cách thủ công trở nên khó khăn khi ứng dụng mở rộng.
Cấu trúc của các thành phần "Hard Way"
- Template: Sử dụng
document.createElement('template')cho cấu trúc HTML - Hàm clone: Tạo các phiên bản mới từ template
- Hàm init: Thiết lập phiên bản thành phần với:
- Biến DOM (tham chiếu đến các phần tử)
- Biến trạng thái (giá trị dữ liệu)
- Hàm cập nhật DOM (để thay đổi các phần tử)
- Hàm cập nhật trạng thái (để thay đổi dữ liệu)
- Hàm cập nhật (để nhận props từ thành phần cha)
Cân nhắc về bảo mật
Một số nhà phát triển đã nêu lên mối lo ngại về các lỗ hổng bảo mật tiềm ẩn trong các phương pháp tạo template viết tay. Sử dụng template literals để tạo chuỗi HTML có thể dẫn đến các lỗ hổng cross-site scripting (XSS) nếu đầu vào của người dùng không được xử lý đúng cách. Mặc dù việc làm sạch dữ liệu phía máy chủ có thể giúp ích, nhưng nhiều người cho rằng các framework hiện đại cung cấp sự bảo vệ tốt hơn bằng cách xử lý điều này tự động. Cuộc thảo luận đã làm nổi bật việc các nhà phát triển có thể dễ dàng gây ra các vấn đề bảo mật khi tạo HTML thủ công, đặc biệt là những người chưa từng trải qua thời kỳ phát triển web trước khi có framework.
Tóm lại, mặc dù phương pháp Hard Way mang lại những lợi ích hấp dẫn cho một số trường hợp sử dụng nhất định—đặc biệt là về hiệu suất, kiểm soát và cơ hội học tập—cộng đồng vẫn còn chia rẽ về việc liệu nó có phù hợp cho các ứng dụng sản xuất ở quy mô lớn hay không. Cuộc tranh luận cuối cùng phản ánh sự căng thẳng giữa sự đơn giản và cấu trúc, giữa kiểm soát trực tiếp và sự tiện lợi trừu tượng, điều đã đặc trưng cho sự phát triển web trong nhiều năm. Khi các trình duyệt tiếp tục phát triển và cung cấp các API gốc mạnh mẽ hơn, cuộc trò chuyện này có thể sẽ tiếp tục phát triển.
Tham khảo: Writing JavaScript Views the Hard Way