- Để xem các bản demo tương tác trong tutorial CRDT như nội dung tồn tại lâu dài, web component có thể nhúng trực tiếp vào HTML phù hợp hơn so với một framework cụ thể
- Component MDX của Astro mang lại các tiện ích như build, scope CSS, TypeScript, nhưng khi chuyển ra ngoài Astro có thể phát sinh chi phí viết lại
- Web Components cho phép chèn custom tag như
<pixelart-demo></pixelart-demo> vào Markdown và chỉ cần tải script là có thể tái sử dụng dựa trên thẻ ở bất kỳ đâu trên trang
- Framework và TypeScript cũng là các dependency, nên thay đổi về phiên bản, API và khả năng tương thích sẽ tích lũy, và mã bị bỏ lâu càng nhiều dependency thì càng khó phục hồi
- Nền tảng web đủ ổn định để các trang cũ vẫn chạy trên trình duyệt hiện đại, nên với những thứ cần truy cập được sau 5, 10, 20 năm, cách tiếp cận dựa trên tiêu chuẩn sẽ có lợi hơn
Bảo tồn demo tương tác như một dạng nội dung
- Series blog về CRDT cần demo tương tác để thể hiện khái niệm, và ví dụ được dùng là trình chỉnh sửa pixel art cộng tác
- Tiêu chí chọn công nghệ là dù demo được tạo bằng HTML, CSS, JS, nó vẫn gần với nội dung được nhúng trong bài blog hơn
- Gần giống một thứ được chèn vào bài như hình ảnh hay video
- Phải có thể chuyển sang bất kỳ nơi nào có thể render HTML
- Tính đến năm 2023, website được xây bằng Astro, nhưng trước đó đã đi qua trình tạo site tĩnh tự xây, Hugo, CMS tùy biến bằng PHP, Tumblr, Movable Type, WordPress, v.v.
- Dù hiện tại thích Astro, vẫn khó có thể giả định website sẽ mãi chạy trên Astro
Cách Markdown làm giảm chi phí migration
- Lý do migration gần đây khá dễ là vì nội dung được giữ dưới dạng tệp văn bản thuần Markdown
- Khi chuyển hệ thống, khối lượng việc thường gặp được giảm đi
- Xuất dữ liệu từ một hệ thống và nhập vào hệ thống khác
- Sửa các vấn đề tương thích
- Loại bỏ những thành phần không tìm được cách chuyển đi
- Chỉ cần đưa các file Markdown vào website mới là phần lớn vẫn hoạt động nguyên vẹn
- Markdown cho phép viết trực tiếp HTML, nên nếu một sơ đồ tương tác phức tạp có thể biểu diễn bằng thẻ HTML thông thường, nó cũng có thể di chuyển như phần nội dung còn lại
Tiện ích của Astro MDX và giới hạn về tính di động
- Tích hợp MDX của Astro cho phép render component Astro bên trong Markdown
- Component Astro tận dụng nhiều tiện ích của hệ thống build
- Viết HTML, CSS, JS trong cùng một file
- Xử lý scope cho selector CSS
- Biên dịch TypeScript
- Render markup có điều kiện
- Các tối ưu hóa khác
- Vấn đề là tất cả những tiện ích đó chỉ hoạt động ổn định bên trong Astro
- Khi chuyển sang một trình tạo site khác, có thể phải viết lại component
- Có thể phải tách HTML, CSS, JS ra riêng
- Có thể cần cấu hình hệ thống build mới
- Có thể phải tìm lại cách scope style phù hợp
- Vì vậy, các tính năng riêng của Astro tuy tiện lợi nhưng không phải lựa chọn phù hợp cho các demo cần được bảo tồn lâu dài
Web Components giải quyết phần nào
- Web Components là một tập hợp công nghệ tiêu chuẩn web để tạo các phần tử HTML có thể tái sử dụng
- Cách dùng là viết lớp custom element, đăng ký tên thẻ, rồi dùng thẻ đó trong markup
- Demo pixel art được nhúng vào Markdown chỉ với HTML sau
<pixelart-demo></pixelart-demo>
- Không cần cấu hình đặc biệt riêng hay quy trình đặt sẵn một phần tử rồi gọi hàm
- Vẫn cần giữ file JS và liên kết bằng thẻ
<script>, nhưng việc tham chiếu media từ nội dung văn bản thì cũng giống như các loại media khác
- Khi script được tải, tên thẻ sẽ được đăng ký, và dù markup đã có sẵn trước khi JavaScript chạy, nó vẫn hoạt động ở bất kỳ đâu trên trang
Cấu trúc một file và Shadow DOM
- Web Components có thể đóng gói HTML, CSS, JS trong một file duy nhất, không cần hệ thống build riêng
- Khi mã component được gom về một chỗ, gánh nặng tinh thần giảm đi, và single-file component cũng có lợi về mặt trải nghiệm phát triển
- Component ví dụ
<pixelart-demo> kế thừa HTMLElement, gắn Shadow DOM bằng attachShadow({ mode: "closed" }), rồi render markup và style bên trong
import PixelEditor from "./PixelEditor.js"; ở đầu file là ES module import, nên không phụ thuộc vào hệ thống build riêng- Chỉ cần giữ các file liên quan cùng nhau là trình duyệt sẽ xử lý module
- Shadow DOM giúp cách ly component khỏi trang xung quanh
- Có thể hơi gượng nếu cần chia sẻ style với toàn bộ ứng dụng
- Phù hợp khi cần cách ly hoàn toàn
- Có thể giữ nguyên hình thức và hành vi dù được dùng ở đâu, giống như hình ảnh hay video
Nhận cấu hình bên ngoài bằng thuộc tính
- Web Components có thể công khai thuộc tính (attribute) để cấu hình từ bên ngoài
- Thuộc tính có thể được dùng như thuộc tính native
- Biến CSS là một trong số ít giá trị có thể đi vào bên trong Shadow DOM, nên ví dụ range slider đặt màu accent như sau
<range-slider style="--accent: #0085F2"></range-slider>
- Demo pixel art đổi độ phân giải thành 20 bằng thuộc tính và hiển thị thông tin debug của từng pixel
<pixelart-demo debug resolution="20"></pixelart-demo>
- Các lệnh gọi
getAttribute và hasAttribute trong lớp component được dùng để đọc những giá trị thuộc tính này
- Điều này hữu ích khi tái sử dụng cùng một component ở nhiều bước trong tutorial và bật một số tính năng tùy theo giai đoạn
Framework và TypeScript cũng là dependency
- Có những công cụ biên dịch sang web component như Lit, Stencil, Svelte, nhưng framework rốt cuộc vẫn là dependency
- Trade-off đáng lo nhất ở đây là chi phí bảo trì dài hạn
- TypeScript cũng không phải nền tảng native của web, nên cũng là một dependency
- 15 phiên bản TypeScript gần đây có các breaking change, và nhiều thay đổi trong số đó là tính năng mới hữu ích nhưng vẫn cần sửa mã
- Dùng dependency đồng nghĩa phải gánh theo việc phát hành phiên bản mới, thay đổi API, và chi phí kiểm tra tương thích
- Vì không có kế hoạch tiếp tục động vào đoạn mã này, nên không muốn đến lúc buộc phải sửa lại phải xử lý dồn nhiều năm cập nhật một lúc
Kinh nghiệm phục hồi website cũ và sự ổn định của nền tảng web
- Khi xây dựng một bảo tàng trực tuyến, tác giả đã phục hồi mã cũ lưu trên chiếc laptop không bật suốt 10 năm, và nhận ra website càng nhiều dependency thì càng khó hồi sinh
- Trong khoảng 20 năm làm web, tác giả đã chứng kiến sự ra đời, phát triển và suy tàn của jQuery, cũng như quá trình Node.js xuất hiện rồi fork thành io.js và hợp nhất trở lại
- Backbone nhanh chóng bị thay bằng AngularJS, AngularJS bị thay bằng React, và ngay cả React trong khoảng nửa quãng thời gian đó cũng đã trải qua nhiều cách viết component khác nhau
- Trong khi hệ sinh thái thay đổi, chính nền tảng web được thay đổi rất thận trọng để tránh làm hỏng các website cũ, nên vẫn giữ được độ ổn định đáng kể
- Các website cũ vẫn tiếp tục hoạt động trên trình duyệt hiện đại
- Nếu muốn thứ gì đó vẫn truy cập được sau 5, 10, 20 năm, cách phù hợp hơn là giảm các dependency ngoài tầm kiểm soát và bám vào tiêu chuẩn web có khả năng ít bị hỏng hơn
- Dù web có khuyết điểm, khi xây dựng trực tiếp dựa trên đặc tính của nó mà không thêm lớp trung gian, nó vẫn là một nền tảng điện toán bền bỉ, dễ di chuyển và hướng tới tương lai
1 bình luận
Ý kiến trên Hacker News
htmx không phải là framework mà là thư viện, và vì bài viết có nhắc đến nên tôi muốn trả lời vài điểm
Trước hết, bài viết không bàn đến vấn đề đồng bộ trạng thái với máy chủ, trong khi htmx tập trung đúng vào vấn đề đó thông qua trao đổi hypermedia. Vì vậy, xét từ góc nhìn này, htmx và Web Components là hai thứ trực giao với nhau
Vì dependency kéo theo phiên bản mới, thay đổi API và chi phí duy trì tương thích, htmx không có dependency và rất tập trung vào khả năng tương thích ngược. Ví dụ, nó tương thích với IE11, còn intercooler.js, có thể xem như htmx 1.0, ra mắt năm 2013 với một dependency duy nhất là jQuery nhưng hiện vẫn được hỗ trợ
Nhiều thư viện JavaScript có văn hóa viết lại API và nâng cấp khó khăn, nhưng htmx thì rõ ràng không như vậy, và không nên bị gộp vào kiểu khái quát hóa đó. Thay đổi phá vỡ tương thích duy nhất của htmx 2.0 có lẽ chỉ là ngừng hỗ trợ IE
Web Components có tồn tại lâu hơn htmx hay không thì vì nó là một phần của trình duyệt nên có lẽ là có, nhưng htmx sẽ tiếp tục được giữ rất ổn định và ít thay đổi nhất có thể. API về cơ bản đang đi đúng hướng, và tôi cho rằng không cần viết lại toàn bộ chỉ vì sự thuần túy hay cho ngầu
Quan trọng nhất, htmx trả lời một câu hỏi khác với Web Components: làm thế nào để đồng bộ hóa máy chủ và trạng thái
Dùng WebComponent cho phép móc vào vòng đời của các phần tử DOM bị sửa đổi từ bên ngoài, như morphdom của Htmx. Khi thuộc tính thay đổi, phải báo cho React component biết; và khi node bị xóa khỏi DOM, phải báo để React chạy quy trình dọn dẹp. Tôi nghĩ nếu không có WebComponents thì khó làm việc này một cách gọn gàng và hiệu quả
Kết quả là chúng tôi vẫn có thể tiếp tục theo cách của Htmx: đặt toàn bộ trạng thái logic nghiệp vụ trên máy chủ, chỉ giữ một số ít thứ thận trọng ở client như phần tử đang được focus hoặc văn bản đang nhập. Càng đi theo hướng này thì bug và race condition càng ít, trải nghiệm người dùng tốt hơn nhiều, nên rất đáng công sức
https://x.com/jlazaroff/status/1717176726248108469
https://htmx.org/essays/hypermedia-friendly-scripting/
Việc chỉ có form mới POST được, và cách duy nhất để xử lý phản hồi là viết lại toàn bộ trang, có vẻ là những ràng buộc tùy tiện và hạn chế. Nếu htmx trở thành thứ gì đó như HTML6, nó sẽ sống lâu hơn mọi framework JavaScript
Là một kỹ sư chủ yếu tập trung vào backend, phần lớn các thư viện JS tôi đem về dùng đều tạo gánh nặng bảo trì lớn về sau và cũng thường xuyên có thay đổi API lớn. Tôi định thử dùng htmx trong một dự án cá nhân
Có vẻ các template tạo mảnh HTML ở phía máy chủ cũng sẽ bớt phức tạp hơn
Bản thân htmx là một khái niệm thật sự thuyết phục, nhưng tôi ước gì nó có cộng đồng lớn hơn. Đây đúng là vấn đề con gà và quả trứng, nhưng so với các web framework khác thì tài liệu như bài blog hay video không nhiều. Ví dụ, ngay cả nội dung cơ bản như tích hợp xác thực Auth0 vào một ứng dụng htmx cũng khó tìm
Toàn bộ non.io được viết bằng Web Components thuần và là một SPA hoàn chỉnh. Khi vượt ra ngoài các component blog lồng nhau đơn giản, có vài điều tôi đã học được
Quản lý state vẫn chưa có câu trả lời. Nếu không dùng framework bọc bên ngoài, bạn phải tự làm rất nhiều thứ. Một trong những điểm hay của React là quản lý state nhìn chung đã được giải quyết, có sẵn các pattern và kỳ vọng hiện hữu. Với Web Components thì giống như miền Tây hoang dã; vì không thể truyền các object phức tạp qua attribute như JSX, cuối cùng bạn sẽ phải trộn lẫn attribute, event và gọi trực tiếp các hàm của class
Hiệu năng cũng không đem lại lợi ích lớn như kỳ vọng. Với các phần tử nguyên tử nhỏ, chẳng hạn như icon, khi có hàng trăm cái trên một trang thì chi phí tạo instance lớn hơn giá trị mang lại, nên tôi đã rút chúng khỏi Web Components. Các phần tử tĩnh, dù giúp code dễ đọc hơn, cũng không đáng để dùng Web Components, điều này khá đáng thất vọng
Dù vậy vẫn có những điểm tôi thật sự thích. Như tác giả đã nói, việc thêm component vào một trang mới là rất dễ, bất kể framework đang dùng là gì. Nếu được làm bằng Web Components thì thực sự có thể dùng ở bất cứ đâu. Khi xây các site phụ trợ như tài liệu API của nonio, dù stack khác nhau, việc chọn và dùng component mong muốn rất tiện. Nếu cần embed một component, chỉ cần lấy JS về và thêm HTML là xong
Đóng gói style của shadow root cũng khá tốt. Tôi thích việc không phải lo rằng khi làm việc trên một trang sẽ làm vỡ style của component nào đó. Việc phải đoán và kiểm tra xem có ghi đè style của phần tử khác hay không giảm đi, và nhu cầu dùng framework kiểm tra khác biệt trực quan để đảm bảo điều này cũng giảm theo
Kích thước package nhỏ cũng là điểm tốt. Không có thư viện hay phần tải bổ sung nào; mọi thứ đều tích hợp sẵn. Việc chọn đúng những component cần dùng cũng dễ, nên giữ kích thước package ở mức thấp cũng rất đơn giản
Source component của nonio nằm ở đây: https://github.com/jjcm/nonio-frontend/tree/master/component...
Về quản lý state cũng vậy, hoàn toàn không có gì ngăn bạn kết nối bất kỳ giải pháp quản lý state nào mình muốn. Nếu mục tiêu là giảm thiểu dependency, tôi cũng đã thấy khá nhiều giải pháp dùng mô hình event tích hợp sẵn của trình duyệt
Cuối cùng, cá nhân tôi cho rằng viết toàn bộ app bằng Web Components thuần là một ý tưởng khá quá sức. Dùng Lit chỉ 5KB sẽ cho trải nghiệm developer tốt hơn nhiều: https://lit.dev
Các framework này thường đạt hiệu năng bằng cách batch các thao tác DOM trên toàn bộ trang, nhưng với Web Components thì không thể làm như vậy
Chỉ riêng lý do này, tôi đã xem Web Components gần như là ngõ cụt. Có thể nó hữu ích khi bạn chỉ cần những đảo chức năng nhỏ thay vì một trang được render hoàn toàn phía client
Tôi cũng từng thấy giới hạn hiệu năng tương tự nhưng luôn nghĩ đó là do shadow DOM nặng. Giờ thì tôi bắt đầu tự hỏi liệu bản thân việc tạo instance có nặng hay không
Tôi cũng cảm thấy vấn đề tương tự với quản lý state, và đang nghĩ đến việc mượn ý tưởng từ phát triển desktop: đặt một message bus cấp cửa sổ, để mọi component subscribe và filter, còn mọi thay đổi state thì publish lên message bus đó
Ví dụ truyền object phức tạp qua attribute có thể xem zx-listeditor ở đây:
https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
Bản thân Web Component nằm ở đây:
https://github.com/wisercoder/uibuilder/blob/master/WebCompo...
Thư viện nhỏ 500 dòng giúp làm điều này nằm ở đây:
https://github.com/wisercoder/uibuilder/#jsx-for-web-compone...
Pattern cơ bản của LiveState là “dispatch event và subscribe state”. Event và các cập nhật state được gửi qua kết nối WebSocket, còn thư viện frontend và backend là một lớp mỏng nằm trên Phoenix Channels
Hiện tại các hàm event handler được viết bằng Elixir, nhưng đang có công việc để cho phép viết chúng bằng bất kỳ ngôn ngữ nào có thể biên dịch sang WebAssembly
Không kỳ vọng framework JS mình ưa thích sẽ mãi không đổi. Tôi biết vòng đời của chúng ngắn, và tôi thích điều đó
Lý do dùng React, Vue, Svelte v.v. là để tiến lên, có tiến bộ và cải thiện. Hiện tại tôi không muốn một thứ gì đó tĩnh. Vì trong số các framework có thể dùng hiện nay, kể cả Web Components, không có cái nào giải quyết vấn đề một cách đặc biệt tao nhã
Nếu lập luận là site làm bằng Web Components sẽ tồn tại lâu hơn site làm bằng framework JS, tôi muốn cá cược thử. Thành thật mà nói, tôi nghĩ khả năng trong 20 năm tới một phần của stack công nghệ Web Components bị gỡ khỏi Chrome, Safari, Firefox làm ứng dụng hỏng còn cao hơn khả năng một ứng dụng React 16 viết 2 năm trước bị hỏng vì thay đổi của JavaScript
Nếu ghim hoàn toàn mọi phiên bản dependency của ứng dụng React 16 thì có thể nó sẽ không hỏng, nhưng việc đó giống chạy một chương trình cũ trong VM hay trình giả lập hơn là “vẫn có thể tiếp tục làm việc và hack trên ứng dụng React 16”
Kèo có ý nghĩa hơn sẽ là “có thể tiếp tục phát triển trên ứng dụng React ZZZ hay trên ứng dụng làm bằng Web Components”
Nếu đặt điều kiện theo hướng có lợi cho quan điểm của mình nhưng vẫn có ý nghĩa hơn, thì sẽ là “chi phí cập nhật ứng dụng React để bắt kịp N năm cập nhật dependency lớn hơn hay nhỏ hơn ứng dụng Web Components”. Nếu ứng dụng Web Components không nhồi một đống dependency kỳ quặc, tôi nghĩ khả năng rất cao là chi phí cập nhật phía ứng dụng React sẽ lớn hơn
Về cơ bản là đặt cược rằng các nhà cung cấp trình duyệt sẽ ít phá vỡ tương thích ngược hơn các tác giả React
HTML Imports đã bị loại bỏ vì ưu tiên giải pháp thuần JS, và Firefox thậm chí đã từng triển khai nó
Custom Elements v0 cũng bị loại bỏ; Chrome đã triển khai nó và YouTube từng vội vàng viết lại bằng nó. Vì YouTube mất chừng ấy thời gian để chuyển đổi nên phải đợi khoảng 4 năm mới gỡ được phần triển khai
Để giữ mã an toàn, cần cập nhật thư viện. Nhưng các phiên bản thư viện cũ sẽ bị ngừng hỗ trợ, và các lỗ hổng đã biết không thể sửa bắt đầu tích tụ. Kẻ tấn công rất có thể có chương trình quét các website có lỗ hổng đã biết và tự động tấn công
Ngược lại, nếu dùng thư viện hoặc nền tảng coi trọng tương thích ngược như Web Components, có thể duy trì bảo mật trong khi vẫn hỗ trợ mã cũ lâu hơn
Dần tập trung vào con người hơn là công nghệ
Nếu bắt đầu một dự án mới, trước hết tôi xem những người sẽ làm việc trong dự án đó biết gì. Nếu có mẫu số chung hay thực hành tốt nhất như React trong frontend hiện nay, thì cứ dùng nó
Tôi không quá băn khoăn vì những quyết định kỹ thuật kiểu này. Vì thành phần đội ngũ, thị trường ứng viên và thứ hạng công nghệ trên StackOverflow dễ dàng trả lời các câu hỏi đó
Nhưng nếu ai cũng nghĩ như vậy, thì dù có câu trả lời tốt hơn cho việc xây dựng phần mềm, chúng ta sẽ mãi dùng React. Việc chọn dùng thứ phổ biến có nghĩa là phụ thuộc vào những người khác trong việc tìm ra giải pháp kỹ thuật tốt và làm cho nó trở nên phổ biến, để cải thiện stack công nghệ
Nói cách khác, chiến lược này chắc chắn nằm về phía những người chấp nhận ở giai đoạn giữa đến cuối trên đường cong chấp nhận. Phần lớn các bài viết và thảo luận kiểu này nhắm đến những người chấp nhận sớm hơn
Vì có thể viết HTML bên trong Markdown, nên ý rằng nếu cả các sơ đồ tương tác hào nhoáng cũng có thể được biểu diễn bằng thẻ HTML thông thường thì chúng sẽ có tính di động như phần còn lại của Markdown, thực ra MDX cũng có thể làm chính xác điều tương tự
Bản thân công nghệ Web Components ở đây không giúp ích gì. Điều tác giả quan tâm là giao diện giữa markup và đoạn mã áp dụng chức năng runtime. Web Components ở đây chỉ là chi tiết triển khai. Khi viết tên giữa dấu ngoặc nhọn, việc nó tham chiếu đến component React, thứ gì đó của Astro, hay Web Component đều không quan trọng. Điểm cốt lõi là có một thứ khác được gọi
Nhược điểm của Web Components ở đây là trên thực tế chúng chỉ chạy ở phía client. Không có cách nào chuyển nội dung shadow DOM đã render trên server sang client, nên ngay cả khi Web Component hoàn toàn không tương tác, vẫn cần JS phía client để render. Các framework khác thì không như vậy
Không phải ý chính của tác giả là sai. Với tư cách là một cách hệ thống hóa giao diện giữa các đoạn mã, Web Components có lẽ là cách tốt nhất và bền lâu nhất. Nhưng trên server, Web Components chẳng giúp được gì. Chúng không được render, giao diện thì rườm rà, và mã nhiều khả năng vốn đã được viết theo cách có thể xử lý tổng thể. Nếu đang dùng Astro trên server thì cứ tiếp tục dùng Astro. React, Vue hay bất cứ thứ gì khác cũng vậy
Nơi Web Components tỏa sáng là phía client. Khi dùng component bên thứ ba có thể không được viết bằng framework bạn chọn, bạn không cần biết component đặt lên trang được tạo bằng framework nào. Viết thẻ HTML là nó hoạt động. Cơ chế giao diện được nâng lên mức trình duyệt, nên hai framework không cần biết chi tiết triển khai của nhau
Theo nghĩa đó thì đúng là cần một công cụ nào đó. Chỉ là công cụ đó có thể là bất kỳ template engine phía server nào dùng để điền HTML ban đầu và bootstrap
Nhưng shadow DOM đã render trên server có thể được chuyển sang client. Cái này gọi là declarative shadow DOM, và hoạt động trên mọi trình duyệt lớn ngoại trừ Firefox. Firefox cũng đang triển khai và cũng có polyfill
https://developer.chrome.com/articles/declarative-shadow-dom...
Nhân tiện, polyfill này khá dễ, nên có thể dùng được ngay cả khi trình duyệt hiện chưa hỗ trợ
Nếu có Web Components có thể render trên server, nó sẽ mở ra nhiều khả năng cải thiện trải nghiệm người dùng cho các ứng dụng nhiều trang
Thế giới JS vẫn quá ám ảnh với thick client nắm toàn bộ quyền kiểm soát, đến mức bỏ lỡ những điều thú vị đang diễn ra trong thế giới server
Các giải pháp như Rails Hotwire, Phoenix LiveView, Laravel Livewire có thể giải quyết 80% frontend với lượng JS tối thiểu và độ phức tạp trải nghiệm lập trình viên gần như không đáng kể
Tôi cũng từng làm các ứng dụng frontend giàu tính năng đọc ghi database và object storage mà không cần server. Tính di động rất tốt, bước cài đặt chỉ là upload vài file. Có thể chạy trực tiếp từ CDN đơn giản và rất nhanh
Hầu hết frontend developer tôi biết cũng biết hệ Hotwire, nhưng với họ các stack như vậy lại làm tăng độ phức tạp trải nghiệm lập trình viên. Đôi khi người ta nói “độ phức tạp” nhưng thực ra ý là “sự xa lạ”. Frontend và backend đều có thể trở nên quá phức tạp, nhưng không nhất thiết phải như vậy
Khi có sự cố, tôi cho rằng có nhiều quyền kiểm soát hơn vẫn tốt hơn. Đặc biệt trong môi trường tốc độ cao nơi client luôn yêu cầu có ngay thứ họ muốn
Cá nhân tôi thích viết mọi thứ bằng JavaScript/TypeScript hơn là rắc cú pháp đường lên trên HTML
Đưa nó về phía server như Livewire không làm những nhược điểm mạnh như độ trễ biến mất
Tiêu đề có lẽ đúng, nhưng tôi không biết điều đó có quan trọng không. Phần lớn ứng dụng không sống lâu đến vậy
Gần đây tôi đã thử dùng Web Components, và một tính năng rất đơn giản trong bất kỳ framework nào lại cực kỳ rối rắm và phức tạp để thiết lập. Nếu component là thứ đơn giản thì có thể không sao, nhưng nếu làm ứng dụng bằng JS thì slot là tính năng cốt lõi vì nó cho phép tạo component có thể tổ hợp
Debug shadow DOM trong công cụ developer cũng thật sự gây rối
renderProp của React hay scoped slot của Vue được dùng rất phổ biến để bơm dữ liệu từ component cha vào component con. Nhưng tái tạo hành vi đó trong Web Component về cơ bản là bất khả thi nếu không dùng hack MutationObserver. Giả định của Web Component rằng component con và cha không cần biết thông tin của nhau không phù hợp với thế giới thực
Giả định rằng component con luôn được tải và khởi tạo độc lập với component cha cũng sai trong hầu hết framework. Trong đa số framework, component cha quyết định có thực sự tải hoặc khởi tạo component con hay không
Web Components có thể tốt hơn để viết các component cô lập và có thể tái sử dụng, nhưng DOM API dùng để ghép nối đủ thứ nhằm làm cho ứng dụng hoạt động thì đơn giản là quá tệ
Vẫn thấy rõ dấu vết nó được tạo ra để chỉnh sửa tài liệu XML
Còn một lý do nữa khiến người ta không tạo Web Components ngay cả cho các component cô lập và có thể tái sử dụng. Không trình soạn thảo nào hỗ trợ đúng mức những thứ như tự động hoàn thành thuộc tính hay tên sự kiện, kiểm tra lỗi gõ sai
Để làm cho nó hữu ích, bạn phải nối nhiều dependency lại với nhau, và những dependency đó có lẽ sẽ không được bảo trì tốt như React
Tôi từng làm ở một công ty theo triết lý này. Tất cả UI component đều là Web Component có gói npm riêng mà mỗi cái phải tự cài. Nó vẫn hoạt động, nhưng hoàn toàn không có lợi ích gì. Sáu năm trôi qua đến nay vẫn không thấy lợi ích nào. Có lẽ họ đang tối ưu cho một tương lai sẽ không bao giờ đến
Site HTML/CSS sẽ tồn tại lâu hơn tất cả
Vì văn bản, hình ảnh, layout thực sự nằm trong những thứ tĩnh, có thể tồn tại mãi mà không cần đụng tới, không cần chạy mã phức tạp hay duy trì các bán chuẩn mơ hồ thay đổi nhanh
Nếu muốn tạo site bền lâu và có công nghệ bền lâu, hãy học cách xây dựng website HTML được nâng cấp dần. Cách tạo ra các phần tử HTML chưa định nghĩa, vô dụng, có dấu gạch nối như Web Components rồi chạy một đống JavaScript để định nghĩa chúng, hoặc các framework JavaScript thậm chí còn không giả vờ dùng HTML, sẽ chỉ trụ được vài năm
Ít nhất là như vậy cho đến khi trình duyệt bỏ hỗ trợ HTTP/1.1