Web Components sẽ sống lâu hơn các framework JavaScript của bạn

• Bài viết về tính bền vững lâu dài và sự linh hoạt của web components, so sánh với các framework JavaScript
• Tác giả cho rằng việc lựa chọn công nghệ cho dự án nên được quyết định bởi các ràng buộc của dự án thay vì các lựa chọn mặc định
• Lý do tác giả chọn web components bằng vanilla JS cho dự án: tính di động và khả năng render HTML
• Blog của tác giả được xây dựng bằng nhiều công cụ khác nhau như Astro, Hugo, CMS tùy chỉnh viết bằng PHP, Tumblr, Movable Type, WordPress
• Nhấn mạnh lợi ích của việc giữ nội dung trong các tệp văn bản thuần túy viết bằng Markdown, giúp đơn giản hóa quá trình di chuyển nội dung giữa các hệ thống
• Tác giả cho rằng các tính năng riêng của Astro tuy tiện lợi nhưng thiếu tính di động nên đã không được dùng trong dự án
• Web components có thể được viết dưới dạng HTML trong Markdown, nhờ đó có tính di động cao tương đương phần còn lại của nội dung Markdown
• Web components là một bộ tiêu chuẩn W3C để xây dựng các phần tử HTML có thể tái sử dụng, đóng gói toàn bộ HTML, CSS, JS trong một tệp duy nhất, không cần hệ thống build
• Tác giả chỉ ra rằng web components có thể lộ ra các thuộc tính để cấu hình từ bên ngoài, tương tự props gốc
• Do lo ngại về sự đánh đổi giữa bảo trì và phụ thuộc, tác giả quyết định dùng vanilla JS thay vì các framework biên dịch sang web components như Lit, Stencil, Svelte
• Tác giả cho rằng các phụ thuộc như TypeScript có thể cung cấp những tính năng hữu ích, nhưng đòi hỏi thời gian và công sức để duy trì khả năng tương thích với các phiên bản mới và API
• Nhấn mạnh tầm quan trọng của việc tránh các phụ thuộc mà người dùng không kiểm soát được và bám vào các tiêu chuẩn ổn định, đã được kiểm chứng để bảo đảm khả năng truy cập dài hạn và tính bền bỉ của nội dung web
• Kết luận của tác giả là nếu sử dụng web với tư duy hướng đến tuổi thọ lâu dài, đây sẽ là nền tảng điện toán bền bỉ, di động và sẵn sàng cho tương lai nhất

[GN⁺]

Ý kiến trên Hacker News

• Bài viết về tính bền vững lâu dài của Web Components, so sánh với các framework JavaScript
• Những người bình luận chỉ ra rằng thư viện htmx không được nhắc đến trong bài, và rằng nó khác với Web Components ở chỗ tập trung vào việc đồng bộ trạng thái với máy chủ
• htmx được khen ngợi vì không có phụ thuộc và tập trung vào khả năng tương thích ngược, không giống nhiều thư viện JavaScript khác
• Việc quản lý trạng thái của Web Components được xem là vấn đề vẫn chưa được giải quyết, các nhà phát triển phải tự xử lý mà không có framework bao bọc
• Hiệu năng của Web Components không quan trọng như dự đoán, và một số phần tử nhỏ đã bị đưa trở lại do chi phí khởi tạo
• Web Components được khen vì có thể dễ dàng thêm vào trang mới bất kể framework đang dùng, đồng thời cung cấp khả năng cô lập kiểu dáng
• Một số người bình luận bày tỏ rằng họ thích sự tiến bộ và cải thiện của các framework JS hơn là các giải pháp tĩnh như Web Components
• Tầm quan trọng của việc cân nhắc kiến thức và kỹ năng của đội ngũ khi bắt đầu dự án mới được nhấn mạnh
• Các giải pháp phía máy chủ như Rails Hotwire, Phoenix Liveviews, Laravel Livewire được nhắc đến như những bước phát triển thú vị
• Web Components bị chỉ trích vì không thể chạy trên máy chủ, và cần JS phía client để render chúng
• Việc sử dụng slot trong Web Components bị cho là khó hiểu và phức tạp, khiến chúng kém hấp dẫn hơn khi xây dựng ứng dụng
• DOM API bị chỉ trích là không phù hợp để ghép các component lại với nhau nhằm vận hành một ứng dụng
• Web Components bị phê bình vì thiếu hỗ trợ từ trình soạn thảo cho các tính năng như tự động hoàn thành tên thuộc tính và sự kiện
• Một số tính năng cơ bản trong Web Components, ví dụ như các nút bên trong form, vẫn là những vấn đề chưa được giải quyết