Web Components vẫn ổn

 (nolanlawson.com)
2 điểm bởi GN⁺ 2024-10-01 | 1 bình luận | Chia sẻ qua WhatsApp
  • Tranh luận về web components không phải là vấn đề phải chọn duy nhất giữa hiệu năng cao nhất và tiêu chuẩn nền tảng, và ngay từ tiền đề rằng chúng phải thay thế mọi JavaScript framework đã là một giả định quá mức
  • Custom Elements dùng DOM làm giao diện nên có overhead, nhưng trong sản phẩm thực tế cần đánh giá cùng lúc không chỉ hiệu năng mà còn khả năng bảo trì, bảo mật, tính dễ dùng và khả năng truy cập
  • Chi phí hỗ trợ web components trong framework có thể được hấp thụ bằng một vài kiểm tra đơn giản, và việc là tính năng chuẩn không có nghĩa mọi framework bắt buộc phải chấp nhận
  • Web components có điểm yếu ở server-side rendering (SSR), khả năng truy cập và một phần tính tương tác liên vận hành, nên vẫn còn những tình huống React, Solid và Svelte phù hợp hơn
  • Trong những môi trường như Salesforce, nơi ứng dụng render phía client, có marketplace cho component và cần tương thích ngược lâu dài, web components có thể là một lựa chọn thực tế

Điểm khởi đầu của cuộc tranh luận và vị trí của tác giả

  • Cuộc tranh luận gần đây tiếp nối từ bài “Web Components Are Not the Future” của Ryan Carniato và “Web Components Are Not the Future — They’re the Present” của Cory LaViska
  • Trọng tâm không phải là công kích phe đối diện, mà gần hơn với câu hỏi liệu các lập trình viên có những ràng buộc khác nhau có thể tìm được điểm chung hay không
  • Ryan Carniato được đánh giá rất cao nhờ Solid cùng công việc thiết kế framework và hiệu năng thể hiện qua js-framework-benchmark
  • Bản thân web components cũng có phạm vi sử dụng thực tế gắn với việc triển khai framework, tạo component, Web Components Community Group, nhóm Accessibility Object Model, cùng các công việc về shadow DOM, custom elements và khả năng truy cập

Hiệu năng: chi phí của DOM là có thật, nhưng không phải là tất cả

  • Điểm yếu cơ bản của web components nằm ở chỗ chúng dựa trên Custom Elements
    • Mọi giao diện đều phải đi qua DOM nên phát sinh overhead hiệu năng
    • Nếu mục tiêu là framework nhanh nhất một cách tuyệt đối thì cần giảm số DOM node nhiều nhất có thể, và theo tiêu chí này web components ở thế bất lợi
  • Tuy vậy, hiệu năng không phải là tiêu chí duy nhất trong phát triển phần mềm
    • Cần cân nhắc cả khả năng bảo trì, bảo mật, tính dễ dùng và khả năng truy cập
    • Không render các thuộc tính aria-* có thể giúp DOM render nhanh hơn đôi chút, nhưng chúng có thể cần thiết cho giao diện có khả năng truy cập
    • Những vi tối ưu hóa như for loop nhanh hơn .forEach() hoặc var nhanh hơn const/let thường không đáng để đánh đổi nhiều
  • Việc tối thiểu hóa DOM node là ý tưởng cốt lõi của virtualization
    • Dù không phải lựa chọn nhanh nhất, đôi khi một cách tiếp cận đơn giản hơn đã là đủ
    • components as elements cũng không phải tối ưu nhất, nhưng mục tiêu không phải lúc nào cũng phải là tối ưu tuyệt đối
  • Cách dùng chung custom elements được tạo bởi các framework khác nhau cũng có ý nghĩa trong thực tế
    • Có thể cần chuyển dần từ Framework A sang Framework B
    • Cũng có trường hợp phải kết hợp nhiều micro frontend
    • Đây không phải giao diện nhanh nhất, nhưng có thể là đánh đổi cần thiết
  • Trong hiệu năng web thực tế, những điểm cải thiện chi phí thấp như layout thrashing, network waterfall hay rerender không cần thiết thường phổ biến hơn
    • Những cuộc so tài như js-framework-benchmark thú vị với tác giả framework, nhưng không phải lúc nào cũng mang tính quyết định trong bối cảnh sản phẩm thông thường
    • Nếu ở môi trường tài nguyên hạn chế mà từng mili giây đều quan trọng, lựa chọn bỏ web components cũng là hợp lý

Chi phí hỗ trợ của framework và quyền lựa chọn

  • Tác giả không đồng ý với lập luận rằng hỗ trợ web components là chi phí quá lớn với người viết framework
    • Việc phát hiện props và attributes có thể xử lý bằng kiểm tra prop in element
    • Việc xuất ra web components có thể gây đau đầu, nhưng không phải việc mọi framework đều bắt buộc phải làm
    • Vue 2 dùng riêng một web component wrapper library, còn Remount tồn tại mà không cần đầu vào từ team React
  • Framework vẫn có thể rất tốt dù bỏ qua các tính năng được thêm vào web platform từ sau năm 2011
    • jQuery v1 vẫn còn chạy trên nhiều website
    • Khi đội ngũ hiệu năng trình duyệt tối ưu cho các mẫu hành vi của lập trình viên web trong quá khứ, mã cũ đôi khi còn chạy nhanh hơn trên trình duyệt mới
  • Việc tiếp nhận các tính năng mới của web platform kéo theo những cân nhắc mới
    • Các tính năng như Symbol, Proxy, Promises cũng thuộc cùng nhóm này
    • Nhờ tính tương thích ngược của web, mã đã viết vẫn có thể tiếp tục chạy sau 10 năm nữa
  • Hoàn toàn có thể có những framework không quan tâm hoặc không muốn hỗ trợ web components
    • Có thể xây toàn bộ UI bằng web components
    • Cũng có thể chỉ trộn một phần HTML web components
    • Hoặc chọn không dùng chúng chút nào
    • Một framework “no web components” vẫn có thể có người hâm mộ

Tiêu chuẩn là điểm tham chiếu, không phải nghĩa vụ

  • Khi một tính năng trở thành tiêu chuẩn, lập trình viên sẽ tự nhiên coi đó là mốc so sánh mặc định
    • Người viết component cần quyết định liệu <slot> của mình có nên hoạt động như <slot> native hay không
    • Họ cũng phải chọn sẽ dùng IntersectionObserver hay <img loading="lazy">, hoặc tự tạo abstraction riêng
  • Tiêu chuẩn cung cấp điểm tham chiếu chung và từ vựng chia sẻ
    • Nhờ đó có cơ sở để so sánh và đối chiếu những cách tiếp cận khác nhau
    • Nhưng không phải cứ là tiêu chuẩn thì bắt buộc phải dùng
  • Trên web luôn tồn tại song song các tính năng có thể không dùng tới và các API cũ
    • Những API deprecated như document.domain, with, <frame> vẫn tiếp tục được hỗ trợ
    • Các tính năng của web platform có thể được chọn dùng hoặc bỏ qua

Nơi web components phù hợp và không phù hợp

  • Web components làm tốt nhiều việc, nhưng không phải công cụ để thay thế mọi JavaScript framework
  • Các điểm yếu gồm server-side rendering (SSR), khả năng truy cập và một phần tính tương tác liên vận hành
  • Vẫn còn rất nhiều tình huống mà các framework như React, Solid hay Svelte tỏa sáng hơn
  • Câu nói “web components không phải là tương lai” có thể đúng với một số lập trình viên hoặc dự án nhất định
  • Cốt lõi của cuộc tranh luận là thực tế rằng những con người khác nhau đang xây những thứ khác nhau dưới các ràng buộc khác nhau

Trường hợp Salesforce và đánh giá mang tính thực dụng

  • Salesforce cho thấy một môi trường mà web components có thể rất phù hợp
  • Nếu không có những điều kiện đó, có thể không cần xây toàn bộ UI bằng web components, shadow DOM và toàn bộ cấu hình liên quan
  • Trên web platform, game, dự án nghệ thuật và ứng dụng SaaS doanh nghiệp được tạo nên bằng nhiều tính năng khác nhau như WebGL, Wasm và Service Workers vẫn cùng tồn tại
  • Khi nền tảng có thêm tính năng mới, sự sáng tạo không bị giới hạn đi mà cơ hội biểu đạt theo những cách trước đây chưa thể tưởng tượng lại tăng lên
  • Có thể đọc thêm bài của Lea Verou tại đây và bài của Baldur Bjarnason tại đây

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-01
Ý kiến trên Hacker News

  • Tôi đã cố hiểu bài viết được tham chiếu “Web Components Are Not the Future”, nhưng không thấy có nhiều lập luận thuyết phục
    Tình trạng hiện nay của framework frontend khá hỗn loạn, và tôi không muốn học những thứ ma thuật (useState, createSignal, v.v.) không thể hiểu được nếu chưa đọc tài liệu hay các framework phức tạp
    Nếu bắt đầu từ Web Components thì cảm giác trực quan hơn, và còn có những khả năng không nơi nào khác có như cách ly Shadow DOM
    Tôi cho rằng thứ duy nhất đáng giữ lại từ thời React là JSX, nên đã tạo một thư viện dùng Web Components cùng với JSX: https://webjsx.org

    • Câu “không muốn học các framework phức tạp” trộn lẫn nhiều ý nên khó diễn giải
      Không rõ là người đó không muốn học bản thân framework, hay muốn thứ gì đó có cảm giác ma thuật đến mức không cần học, hay có muốn đọc tài liệu hay không
      Tôi chủ yếu dùng Vue, và dù hệ sinh thái SPA phức tạp, tôi cũng không rõ còn hệ thống nào khác khả thi để quản lý các ứng dụng client có trạng thái phức tạp
    • Cũng có khác biệt ở cách nhìn nhận UI
      Mẫu cơ bản của jQuery là tập trung vào hiệu ứng phụ, chọn phần tử rồi thay đổi nó, còn React hay Vue.js cho phép tạo các component mà trạng thái UI được quyết định bởi dữ liệu
      Khi dữ liệu thay đổi, UI được cập nhật với số thay đổi DOM tối thiểu; cách này khiến các widget UI theo từng vị trí dễ đọc và dễ bảo trì hơn nhiều
      Website và ứng dụng desktop dựa trên web ngày nay phức tạp hơn nhiều so với 20 năm trước, nên nếu không chỉ làm UI đơn giản thì đổi mới ở khía cạnh quản lý trạng thái là rất quan trọng
    • Để viết ứng dụng React, không cần biết useState hoạt động bên trong như thế nào, và cách áp dụng nó khá trực quan
      Ngược lại, thư viện được đưa ra có vẻ ngay từ đầu đã đòi hỏi một mô hình tư duy phức tạp hơn
      Hiểu sâu chi tiết của framework tất nhiên là lý tưởng, nhưng React đã thành công ở chỗ cho phép tạo các ứng dụng khá tinh vi dù gần như không biết mô hình nội bộ của nó
    • Angular không khó đến vậy; khoảng một tuần là có thể học đến mức xây được site phức tạp hoặc gửi PR ổn
      Có lẽ cũng vì tôi là lập trình viên đã làm từ thời beta của C#, từ những ngày đầu của HTML/JS/CSS, nhưng tôi hiểu nó khá nhanh
      Khi thay thế một cổng quản trị hạ tầng lõi cũ kỹ và phức tạp, chúng tôi chọn Angular, và nó ổn định, nhanh, đẹp mắt, mọi người đều hài lòng
      “Đường cong học tập dốc” có vẻ chủ yếu đến từ những lập trình viên bước vào ngành chỉ biết JavaScript và một chút React; nếu có nhiều kinh nghiệm hơn thì có thể nắm bắt ngay
    • Nếu là lập trình viên tò mò về bên trong useState, bạn có thể đi đến câu trả lời hợp lý và đúng chỉ trong vài giây
      Nó không phức tạp hay ma thuật, và một triển khai tối thiểu tương tự React hook có thể làm trong vài trăm dòng
      Việc triển khai useState và runFunctionComponent cơ bản còn dễ hơn hầu hết bài tập học kỳ 3 ngành khoa học máy tính ở đại học
      Nếu chừng đó đã là tiêu chuẩn của ma thuật, thì xung quanh ta toàn là những Warlock cấp 20 có thể tạo ra Eldritch Invocation mới ngay trong bữa sáng

  • Tôi nghĩ một lý do khiến hai bên trong cuộc tranh luận này lệch pha là vì họ đang tối ưu cho những đối tượng khác nhau
    Nếu bạn đang ở một startup được VC đầu tư, cần di chuyển nhanh và xây dựng sản phẩm cốt lõi sẽ được bảo trì liên tục, framework có thể rất phù hợp
    Nhưng trong phòng thí nghiệm học thuật, thường không có nhiều tiền để bảo trì ứng dụng đã làm, và nó vẫn phải tiếp tục hoạt động sau khi khoản tài trợ chuyển sang dự án mới
    Tôi gần như đã hoàn tất việc viết lại một ứng dụng Vue bằng Web Components, vì các dependency đã mục nát đến mức không thể cập nhật
    Trước đây tôi đã tốn thời gian sửa địa ngục dependency, và có lẽ sau này cũng sẽ tiếp tục như vậy; nhưng khi thử Web Components thì thấy tốt ngay nên đã chuyển sang
    Số dependency giảm từ khoảng 15 xuống còn khoảng 1 (d3js), và tôi không hối tiếc
    Ứng dụng cũ https://bam.iobio.io/, ứng dụng mới https://bam2.iobio.io/

    • Đôi khi tôi thấy khó hiểu lập luận này
      Không ai ép phải nâng framework lên phiên bản mới nhất, nên lẽ ra cứ ở nguyên phiên bản Vue đang dùng cũng được
      Nếu không có lý do đặc biệt, có thể dùng cùng một phiên bản đến cùng cũng ổn
      Điều này không có nghĩa là ngay từ đầu trường hợp đó không cần Vue, hay việc loại bỏ dependency là lựa chọn tệ; nhưng nếu thích Vue thì dường như không có sức ép bắt buộc phải ở phiên bản mới nhất
    • Nếu đã có thể loại bỏ dependency và chỉ còn d3js, liệu có thể làm cùng việc đó mà vẫn giữ dependency Vue không
      Tôi tò mò liệu lý do Vue cần thêm dependency có nằm ở phía hệ thống build hay không
    • Khi đã quen, tôi nghĩ phát triển Web Components sẽ không chậm hơn bất kỳ framework nào
      Vì vậy tôi không rõ vì sao hệ sinh thái VC lại không thể trụ được nếu không có framework
    • Khó tin rằng họ đang viết tay tất cả Web Components, và cũng khó cho rằng hoàn toàn không có dependency bên ngoài

  • Tôi thích việc Svelte hỗ trợ tạo Web Components thông qua Custom Elements API
    Vì Svelte biên dịch thành JS/HTML/CSS thông thường, nên việc tạo component tái sử dụng chạy được trong bất kỳ framework nào hoặc vanilla JS là điều tự nhiên: https://svelte.dev/docs/custom-elements-api

    • Chính Rich cũng thừa nhận đây không phải mục tiêu ưu tiên cao nhất của Svelte, nên nếu thực tế không đạt như lời hứa thì cũng không có gì đáng ngạc nhiên
    • Vue cũng cung cấp tính năng này: https://vuejs.org/guide/extras/web-components

  • Tôi đã theo dõi các cuộc thảo luận về Web Components suốt vài năm, nhưng với tư cách là một full-stack developer, tôi vẫn chưa rõ nó có thể làm gì để cuộc sống tốt hơn
    Hầu hết các ví dụ này chỉ ở mức đưa dữ liệu vào HTML dưới dạng template, mà việc đó thì đã có thể làm bằng handlebars
    Có phải tôi đang bỏ sót điều gì không

    • “Web” có một mô hình xem HTML như tài liệu, và một mô hình xem HTML như scene graph của một ứng dụng phức tạp hơn
      Nếu dùng HTML như tài liệu, Web Components có thể thêm các tính năng tương tác thời gian thực hấp dẫn hơn
      Ví dụ như trình giả lập terminal kết nối với WebSocket, bộ chọn ngày, phần tử form tùy chỉnh, bản đồ, bảng dữ liệu, widget tab, hay các component tùy chỉnh mà jquery-ui ngày xưa cung cấp
      Không có Web Components vẫn làm được, nhưng nếu biến chúng thành component tùy chỉnh thì HTML sẽ gọn gàng hơn nhiều và vẫn giữ được chất “tài liệu”
      Sẽ tốt nếu có một thư viện Web Components nhất quán, và với HTMX cùng server-sent events thì có vẻ cũng có thể làm chat thời gian thực khá ổn
    • Có thể có cách ly native hoàn toàn
      Trình duyệt cách ly toàn bộ HTML, CSS, JS mà không cần thủ thuật riêng
      Điểm hay là bạn có thể tạo Web Component, định nghĩa rõ API JS, HTML, CSS theo biến, rồi đưa vào bất kỳ môi trường nào cũng không bị vỡ, hoặc không phải tạo ra mê cung namespace CSS phức tạp và phụ thuộc framework
    • Rất tốt cho progressive enhancement
      Ví dụ, có thể thêm các tính năng như lọc hoặc sắp xếp kéo-thả bằng một Web Component bọc quanh bảng, và nếu JS bị tắt hoặc tải thất bại thì người dùng vẫn nhận được bảng và nội dung cơ bản
      Trước đây cách này tốt hơn nhiều so với màn hình trắng của frontend framework, nhưng giờ server-side rendering đã phổ biến nên lợi thế này giảm đi
      Việc đóng gói style cũng tốt, nhưng ngày nay các thư viện headless UI và scoped styles của framework đã phổ biến, nên nó có vẻ không còn cấp thiết như 10 năm trước
      Tuy nhiên, để dùng slot thì phải chọn Shadow DOM, nên khi tạo component tái sử dụng nội bộ, việc không thể style bằng cách đưa một stylesheet vào trang là điều khá khó chịu
    • Lý do các ví dụ né API động có lẽ là vì phần đó rất xấu và nhiều state
      Nếu demo trình bày 200 dòng điều chỉnh DOM thủ công thì khó mà nói Web Components là tương lai
    • Web Components cho phép dùng UI component được tạo bằng framework khác trong framework của mình
      Chỉ có vậy thôi, và với hầu hết các mục đích khác thì nó khá tệ
      Ngoài ra, có thể phát hành UI component để chạy trên mọi framework mà không phải làm 7 phiên bản

  • Phần tệ nhất của Web Components và Shadow DOM là nó có thể khiến browser extension hoạt động không đúng hoặc hoàn toàn không hoạt động
    Các nhà cung cấp trình duyệt cũng không vội sửa tình trạng này

    • Khả năng cấu hình của user agent là tính năng sát thủ của web

  • Tôi cho rằng một trong những “sai lầm” lớn nhất của Web Components là trong đầu mọi người, nó bị gắn liền với Shadow DOM
    Trong phát triển ứng dụng, nếu bám vào live DOM thì Web Components trở thành một lựa chọn rất nhẹ và dễ
    Bạn vẫn có thể tiếp tục dùng các công cụ CSS mình muốn như bootstrap, tailwind, đồng thời gần như không tốn chi phí mà có được khả năng đóng gói chức năng rất tốt; đặc biệt ổn nếu dùng thứ như lit-html làm renderer
    Các đội nhìn chung thấy việc làm việc với Web Components native khá mới mẻ, và developer đến từ thế giới framework sau khoảng một tuần thích nghi thì không muốn quay lại nữa
    Chỉ với các thuộc tính class đơn giản và việc gọi thủ công hàm render trong set(), bạn đã có được lợi ích của reactivity mà không phải chịu sự rườm rà của framework
    Vấn đề là không có nhiều tài liệu chỉ cách bắt đầu ở “chế độ dễ”
    Hầu hết tài liệu nhập môn đẩy người ta thẳng vào các kỹ thuật đau đầu như Shadow DOM, CSS parts, vốn phù hợp với tác giả thư viện hơn là developer ứng dụng
    Có lẽ cần viết một hướng dẫn kiểu “The Good Parts” về cách làm Web Components giúp cuộc sống dễ hơn

    • Tôi dùng Shadow DOM hằng ngày, nhưng đây cũng thường là phần khiến mọi người bối rối nhất trong Web Components. Có lẽ vì họ không cần nó
      Một lựa chọn thay thế là “HTML web components”, chỉ dùng live DOM, ưu tiên server-side rendering và phù hợp để thay thế kiểu “rắc thêm jQuery”: https://adactio.com/journal/20618
      Ngoài ra còn có “Shadow gristle”, dùng Shadow DOM ít nhất có thể, và nếu cần styling hoặc composition thì để ở live DOM: https://glazkov.com/2023/03/02/shadow-gristle/
    • Nếu bạn viết về chuyện này thì tôi muốn đọc. Nghe cũng được
      Công nghệ này có vẻ vừa là phước lành vừa là lời nguyền tùy theo cách dùng, nên tôi đang thu thập tài liệu và bình luận liên quan
    • Ở công ty cũ, chúng tôi dùng đúng stack đó, tức WC không có Shadow DOM và chỉ có lit-html, và nó rất tốt
      Điểm tuyệt nhất là không rơi vào địa ngục phụ thuộc mỗi hai tuần
    • Chính xác là chỗ đó. Thứ hiện còn thiếu là slot cho light DOM

  • Khả năng tương tác là lợi thế lớn nhất từ góc nhìn người dùng, nhưng có vẻ mọi người đang đánh giá thấp việc cái giá phải trả là chi phí hiệu năng: mỗi component được dùng có thể kéo theo runtime không cần thiết
    Cách được khuyến nghị là dùng các framework như Lit cùng với Web Components; theo thời gian khi framework mới xuất hiện và component bị khóa vào phiên bản cũ, chi phí này sẽ tích lũy
    Tôi không muốn khuyên ai đi theo hướng có nhiều thư viện trùng lặp trên một trang, và nếu điều đó được đưa vào best practice thì về dài hạn là không tốt
    Tôi đã theo dõi bài viết, mạng xã hội và video của những người ủng hộ Web Components trong nhiều năm, và đáng lẽ tôi chính là nhóm người dùng mục tiêu, nhưng ngoài “thuế khả năng tương tác” ra thì nó còn đầy những nhược điểm mà các framework chủ đạo không có
    Trong từng hệ sinh thái framework, khả năng tương tác hoạt động tốt; chính những động lực khiến developer tìm đến khả năng tương tác cũng khiến họ tụ lại quanh một số ít framework chủ đạo
    Tôi cho rằng Web Components không theo kịp về mặt công nghệ, và thêm nhiều độ phức tạp vào web platform vì một thiết kế từ đầu thập niên 2010: https://x.com/Rich_Harris/status/1840116730716119356

    • Tôi đã nói trong bài khác, nhưng nhìn rộng ra thì không phải web app nào cũng nhạy cảm về hiệu năng với từng kB bổ sung. Thương mại điện tử thì có, nhưng công cụ năng suất thường thì không
      Cũng có nhiều framework có runtime nhỏ như Svelte; tôi không nói là đưa 100 cái lên một trang, nhưng 5–6 cái thì tôi nghĩ vẫn ổn
      Không có nghĩa đó là lý tưởng, nhưng nó có thể hữu ích cho migration từng bước hoặc micro-frontend
      Nhân tiện, React 17 cũng đã giới thiệu khả năng đặt nhiều phiên bản React trên cùng một trang: https://nolanlawson.com/2021/08/01/why-its-okay-for-web-components-to-use-frameworks/, https://bundlephobia.com/package/svelte@4.2.19, https://legacy.reactjs.org/blog/2020/10/20/react-v17.html
    • Nói vậy cũng đúng, nhưng nhìn vào phần lớn web app được xây dựng ngày nay thì vấn đề nhiều thư viện có vẻ gần như chỉ là sai số làm tròn
      React cộng với react-dom đã hơn 100KB, còn Svelte và Lit chỉ ở mức vài KB
      Có thể nhét vào khá nhiều framework mới tiệm cận được mức phình to mà mọi người hằng ngày vẫn vô tư dùng
    • Nhìn rộng hơn, Web Components cần thuyết phục được các tác giả framework
      Những tín hiệu tôi liên tục thấy đến nay không tốt; cộng đồng đó ở trên X, và Web Components không giải quyết được vấn đề của họ, ngay cả trong tình huống tối ưu cũng không được dùng tốt
      Tôi hy vọng việc thuyết phục sẽ thành công, nhưng nhìn chung họ thường nói Web Components đã thất bại và xét tổng thể là có hại cho web
    • Thành thật mà nói tôi không hiểu lắm lập luận này
      Phần lớn runtime khá nhỏ, và việc hai runtime chạy đồng thời không tạo overhead hiệu năng lớn
      Các web framework hiện đại đều reactive, nên nếu không có gì cần phản hồi thì chúng không làm gì cả
      Một phần của trang dùng React, phần khác dùng Lit, phần khác nữa dùng Svelte thì tôi không thấy lý do gì khiến trải nghiệm người dùng hay mức tiêu hao pin tệ đi đáng kể so với một trang dùng một framework duy nhất
      Tweet được trích dẫn nói về việc Web Components có phải là “primitive hữu ích để tạo framework” hay không, và ngay cả các fan từng dùng thực tế cũng thường sẽ không nói là có
      Web Components là cơ chế phân phối, và nếu lựa chọn thay thế chỉ là tạo cùng một thư viện 7 lần cho React, Preact, Svelte, Solid, Vue và vanilla JS, thì điều đó thật kinh khủng

  • Tôi thích Web Components và lạc quan về khả năng chúng giúp chúng ta thoát khỏi địa ngục frontend hiện tại do chính mình tạo ra
    Gần đây tôi có một bài trình bày ngắn về tương lai của frontend, và có vẻ những người khác cũng đang mong chờ một lối thoát
    Tôi đã tạo một data table cho GUI cơ sở dữ liệu, và dù tải hàng trăm nghìn dòng thì cuộn vẫn rất mượt
    Tôi cũng sắp công bố thư viện Web Component; nó còn sớm và thô, nhưng tôi mong có thêm nhiều người xem: www.astra-ui.com

    • Tôi nghĩ con đường duy nhất để thoát khỏi địa ngục frontend hiện tại là có client-side import: https://github.com/whatwg/html/issues/2791
    • Tôi đã xem tài liệu, và việc render trên Safari 18.0 của iPhone 15 Pro Max rất kỳ lạ
      Có lẽ nên cân nhắc responsive design cho màn hình nhỏ bằng cách bố trí lại sidebar, và đặt max-width cho body thay vì width
      Nút “explore components” ở cuối trang chủ dường như không liên kết tới đâu cả
      Bạn nói “hãy học từ các triển khai component có cấu trúc tốt và có khả năng truy cập”, nhưng tôi không tìm thấy link tới phần triển khai trong tài liệu
      Bạn nói “không có dependency nào cần quản lý hay cập nhật”, nhưng chẳng phải bản thân astra-ui cũng là một dependency sao, và còn có cả changelog nữa: https://www.astra-ui.com/changes/
      Bạn cũng nói “toàn quyền kiểm soát code và styling”, nhưng tôi không hiểu làm sao có thể kiểm soát hoàn toàn trong khi vẫn phụ thuộc vào triển khai do thư viện cung cấp
      Tôi tò mò vì sao bạn quyết định công bố thư viện này. Open source phần mềm nội bộ có thể hữu ích khi công ty có mục tiêu cụ thể, nhưng thường dễ trở thành việc tốn thời gian mà không có bù đắp
      Thư viện component phải chiến đấu để được hệ sinh thái chấp nhận; nếu không, sẽ không có khán giả và lý do công bố cũng không nhiều
    • Lý do gì để dùng cái này thay vì một thứ như Vue component?
    • Vì sao Web Components vẫn chưa thực sự đứng vững hoặc chưa được dùng rộng rãi hơn?
      Nó trông như một giải pháp tuyệt vời
    • Tôi đã viết lại mã quảng cáo frontend của công ty bằng Web Components

  • Vài tháng trước, ở công ty mới, tôi tiếp quản một codebase JS khoảng 250.000 dòng
    Một class khổng lồ cùng vài subclass làm mọi việc, và có file dài tới 30.000 dòng
    Không có framework cũng không có tính phản ứng, nên khi bấm nút phải dùng event listener để cập nhật thủ công mọi thứ trên màn hình
    Code trông như thể ai đó chỉ cầm một cuốn sách JavaScript cơ bản rồi bị nhốt trong phòng tu viện vài năm để viết ra
    Vì phải làm từng chút một, tôi bắt đầu refactor bằng Web Components, việc này giúp ích rất nhiều và đến nay đã giảm được 50.000 dòng
    Tuy nhiên mục đích thật sự là học hết những gì code hiện tại đang làm trước khi viết lại

    • Mấu chốt để hiểu một codebase cũ kỹ và khó nắm bắt là refactor từng phần nhỏ một
      Làm lại bằng Web Components là một cách để đạt mục tiêu đó, và điểm hay là không vứt bỏ toàn bộ để bắt đầu lại từ đầu
      Tuy vậy, nếu làm được một mức nào đó rồi chuyển sang dự án khác, có rủi ro là người tiếp theo sẽ đến và bắt đầu refactor theo phong cách của họ, khiến nó trở thành một codebase khó hiểu với ba phong cách khác nhau
      Dù vậy vẫn tốt hơn là viết lại toàn bộ 250.000 dòng trong một lần

  • Một điểm tôi thích ở Web Components là ít nhất về lý thuyết, chúng vẫn có thể hoạt động ngay cả khi JS bị tắt
    Tôi đã làm như vậy vài lần để cải tiến lũy tiến
    Nhìn chung tôi đồng ý với Nolan. Web Components còn đủ nhiều góc cạnh thô ráp nên khó có thể thống trị thế giới ở trạng thái hiện tại, nhưng khá tốt cho một số trường hợp sử dụng cụ thể
    Tuy nhiên tôi không rõ nhận định rằng chúng không hợp với server-side rendering, vì tôi vẫn làm mà không gặp vấn đề gì

    • Tôi tò mò vì sao lại nói vậy
      Theo tôi thấy, để đăng ký template cho một tag cụ thể thì có vẻ cần JavaScript: https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_templates_and_slots
    • Tôi không biết chuyện này được kỳ vọng hoạt động như thế nào
      Với ReactJS, bạn có thể render component hoặc template ở server, và tôi xem JSX là một ngôn ngữ template khá tốt
      Theo tôi hiểu, Web Components không có sẵn một ngôn ngữ template tốt tích hợp, nên bạn phải tự mang vào
      Tôi không biết có cơ chế chuẩn nào để lấy phần JS component gắn với một tag rồi render HTML cần thiết mà không chạy JS hay không
    • Tôi là tác giả bài viết. Tôi đã bàn ở bài khác, nhưng về cơ bản, lợi thế tương tác liên thông mà bạn có ở client hiện chưa có trên server
      Nếu trong tương lai có thể render 3 framework Web Component khác nhau trên server, chúng kết hợp được với nhau, và hydrate sạch sẽ, thì có thể xem là vấn đề đã được giải quyết: https://nolanlawson.com/2023/08/23/use-web-components-for-what-theyre-good-at/