Hotwire: Công nghệ HTML over the wire

 (hotwired.dev)
2 điểm bởi GN⁺ 2024-06-03 | 1 bình luận | Chia sẻ qua WhatsApp
  • Hotwire là một cách tiếp cận để xây dựng ứng dụng web hiện đại bằng cách truyền HTML thay vì JSON, hướng tới lần tải đầu nhanh và tính phản hồi tốt mà không cần nhiều JavaScript
  • Vì việc render được giữ lại ở template phía máy chủ, quy trình phát triển có thể được duy trì đơn giản bất kể ngôn ngữ sử dụng
  • Các framework do 37signals tạo ra cho HEY được kết hợp với nhau, tạo thành hệ sinh thái Hotwire trải dài từ web đến nhiều nền tảng khác
  • Thành phần cốt lõi là Turbo xử lý chuyển trang, gửi form, tách component và cập nhật từng phần dựa trên WebSocket mà không cần viết JavaScript
  • Những tương tác tùy chỉnh mà Turbo chưa đáp ứng đủ sẽ được Stimulus bổ sung, còn Hotwire Native cho phép tạo ứng dụng di động native dựa trên ứng dụng web hiện có

Cách tiếp cận render HTML trên máy chủ rồi gửi đi

  • Hotwire là một cách tiếp cận thay thế để xây dựng ứng dụng web hiện đại theo kiểu HTML-over-the-wire
  • Thay vì JSON, nó truyền HTML qua mạng, giúp xây dựng ứng dụng mà không cần nhiều JavaScript
  • Mục tiêu là tải trang đầu tiên nhanh, duy trì render template phía máy chủ, và mang lại trải nghiệm phát triển đơn giản, hiệu quả hơn
  • Đây là hướng đi không đánh đổi tốc độ và tính phản hồi thường được kỳ vọng ở các ứng dụng một trang truyền thống
  • HTML-over-the-wire có thể được dùng như một cách tham khảo để tự xây dựng công cụ, hoặc có thể dùng trực tiếp các framework Hotwire mà 37signals đã tạo cho HEY

Vai trò của Turbo, Stimulus và Hotwire Native

  • Turbo là thành phần cốt lõi của Hotwire
    • Cung cấp các kỹ thuật bổ trợ để xử lý nhanh việc chuyển trang và gửi form
    • Chia các trang phức tạp thành component và stream các cập nhật từng phần của trang qua WebSocket
    • Cung cấp các tính năng này mà không cần viết JavaScript
  • Stimulus được dùng khi cần mã tùy chỉnh mà chỉ Turbo thôi là chưa đủ
    • Turbo thường xử lý được ít nhất 80% các tương tác vốn trước đây cần JavaScript
    • Stimulus cho phép xử lý trạng thái và kết nối theo cách lấy HTML làm trung tâm
  • Hotwire Native là framework ưu tiên web để tạo ứng dụng di động native
    • Cung cấp các công cụ cần thiết để xây dựng ứng dụng di động bằng cách tận dụng ứng dụng web hiện có

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-06-03
Ý kiến trên Hacker News

  • Có một phiên bản ít được marketing hơn của chức năng này là htmx: https://htmx.org/
    Nó cho phép làm những việc như vậy chỉ với một file JavaScript, và tôi thường thấy nó được dùng cùng backend Go, nhưng trông có vẻ khá linh hoạt. Tôi đã nghĩ sẽ thử dùng nó từ khoảng một năm trước

    • Ít nhất theo tiêu chuẩn Hacker News, tôi nghĩ htmx được nhắc đến nhiều hơn hẳn
      Chỉ trong năm qua đã có hàng trăm bài gửi lên HN 0, và cũng có bài vượt 1000 điểm. Trong khi đó Hotwire có chưa đến 30 bài gửi trong năm qua 1, và bài phổ biến nhất trong số đó chính là bài này
    • Tôi không hiểu nói htmx ít được marketing là sao. Đây là lần đầu tôi nghe đến Hotwire, còn htmx thì thấy quá nhiều ở khắp nơi
      Chỉ cần lướt YouTube một chút cũng thấy các influencer lập trình liên tục đẩy htmx lên, kèm thumbnail có mặt họ
    • Cũng đáng nhắc đến https://unpoly.com, vốn bao gồm cả các chức năng khác
    • HTMX có lẽ là một trong những framework được marketing tốt hơn hầu hết
      Twitter cũng rất sôi động, nó thường xuyên xuất hiện trên kênh YouTube của The Primeagen và khá phổ biến
    • Ít được marketing ư? Có cảm giác htmx đang tràn ngập trên mọi nền tảng mạng xã hội

  • Nếu tìm thứ tương tự trong PHP/Laravel, tôi rất khuyến nghị Livewire: https://laravel-livewire.com/
    Với các dự án phức tạp hơn tôi vẫn dùng React, nhưng việc có thể viết toàn bộ bằng Blade/PHP trong khi vẫn duy trì các thành phần UI phản ứng luôn đem lại cảm giác mới mẻ. Tôi nhớ từng thấy một package cho phép render component React/Vue bên trong Livewire khi cần: https://minglejs.unitedbycode.com/. Nó trông như một lối thoát thú vị khi cần kéo các package hiện có vào

  • Trước đây tôi khá tiêu cực với Hotwire/Livewire, nhưng giờ tôi xem chúng là công cụ phù hợp tùy hoàn cảnh
    Gửi partial template qua wire là cách tiếp cận hypermedia, chỉ là ngày nay chúng ta không còn thường xây dựng ứng dụng hypermedia tốt nữa. Tôi đi đến đây sau khi đọc lại htmx và bài luận REST của RTF; tôi không cho rằng hypermedia về bản chất là một kiến trúc ưu việt hơn, nhưng nó là một lựa chọn chính đáng ngang hàng giữa nhiều lựa chọn, và thật tốt khi nó vẫn tiếp tục tiến hóa, dù chậm

  • Đây gần như là cách dễ nhất để tạo PWA mà không rơi vào hố thỏ React/Vue/Svelte
    Tôi cũng đã dùng những thứ đó và nghĩ chúng rất tuyệt, nhưng so với htmx thì chúng có cảm giác thiên về trải nghiệm nhà phát triển hơn là lấy công nghệ làm trung tâm. Cuộc cạnh tranh giữa chúng rốt cuộc có lẽ sẽ phụ thuộc vào việc tích hợp tốt hơn với backend framework nào

    • Nếu ứng dụng di động chỉ đơn giản là WebView thì có thể đúng. Nếu không, bạn phải duy trì cả REST API cho ứng dụng di động lẫn các handler request Hotwire/Livewire để trả về các mảnh HTML
      Cá nhân tôi cho rằng PWA là vấn đề phía client, và nên xử lý ở phía client thay vì thêm phụ thuộc vào server
    • Tôi tò mò vì sao cách này lại ít “hố thỏ” hơn các lựa chọn thay thế đã nhắc đến

  • Cuộc thảo luận trên HN năm 2020, gần thời điểm thứ này lần đầu xuất hiện hơn, ở đây: https://news.ycombinator.com/item?id=25507942

  • Cảm giác như gần như đã đi một vòng. Tôi nhớ khoảng năm 2005 hay 2006, chúng tôi chặn các cú nhấp, gắn thêm tham số, chỉ nhận về mảnh HTML đã render rồi thay phần nội dung bằng .innerHTML

    • Trước khi AJAX xuất hiện vào đầu thập niên 2000, Adam Rifkin từng cho xem demo của startup KnowNow của ông ấy; lúc đó việc một trang web tự cập nhật mà không cần refresh thật sự gây sốc
      Mẹo là giữ HTTP request mở liên tục và thỉnh thoảng server gửi cập nhật xuống, mà các cập nhật đó cũng là HTML. Khi ấy có khi còn chưa thao tác DOM được, nên có thể đúng nghĩa là một trang có các thẻ không bao giờ đóng
    • Nói là đi một vòng thì không hẳn; chính xác hơn là các paradigm UI web khác nhau đang mở rộng phạm vi của mình
      Các framework render phía server đang làm cho tương tác phía client dễ hơn, còn React thông qua RSC đang làm cho render phía server dễ hơn. Nếu là web app có mức độ tương tác rất cao thì SPA vẫn có lợi thế
    • Mỗi khi Hotwire hay thư viện tương tự nổi lên lại nghe chuyện này, nhưng thực tế CRUD đơn giản dựa trên AJAX chưa bao giờ biến mất
      Dù có rất nhiều dự án SPA, điều đó không mô tả toàn bộ mọi website trên đời
    • https://animasci.com/ đang dùng cách tương tự
      Pagination được triển khai kiểu: khi cuộn xuống và bấm “Show more”, nó yêu cầu trang tiếp theo từ server dưới dạng mảnh HTML, tải vào một iframe ẩn, rồi sau khi tải xong thì gắn vào trang hiện tại
    • Cuối thập niên 2000 tôi khá thích Wicket và ghét JavaScript, nhưng việc quản lý trạng thái UI và template trên server trong môi trường nhóm rất dễ thành cái bẫy về hiệu năng và khả năng mở rộng
      Nghĩ đến việc web, JavaScript và TypeScript đã tốt lên rất nhiều trong thời gian đó, thật khó để hào hứng trở lại với cách tiếp cận này

  • Tôi không xử lý nhiều web app cần frontend tương tác cao, nhưng trong các cửa hàng thương mại điện tử và app Rails nội bộ, Turbo và Stimulus đã giảm đáng kể lượng kiến thức mà lập trình viên mới phải học

    • Nếu giữ stack đơn giản thì vốn dĩ nó đã không khó đến mức đó
      Ví dụ, trong một dự án Django, chúng tôi dùng KnockoutJS đã được kiểm chứng để nhanh chóng dựng trọn một công cụ văn phòng, và điều này cũng phần nào gần với tinh thần của HTMX. Arrow.JS, dù còn sớm, cũng tương tự. Độ phức tạp, đặc biệt là độ phức tạp ở UI, phần lớn là do chính chúng ta tạo ra; cách làm cũ hoàn toàn không lỗi thời mà còn đang quay lại. Có cả một thế hệ lập trình viên trẻ bước vào ngành đúng vào giai đoạn ngớ ngẩn nhất, khi ngành này thuyết phục mọi người rằng mọi ứng dụng web đều phải bị biến thành một khối quá phức tạp và khó chịu đựng
    • Từ trải nghiệm đã dùng Stimulus, Stimulus rất tệ và tôi sẽ không bao giờ dùng lại. Hotwire thì ổn

  • Tôi đã trả phí dùng Hey từ lúc ra mắt, và nếu trải nghiệm web app của Hey là case tốt nhất của Hotwire thì xin cho tôi từ chối
    Nó tệ trên kết nối chậm. Có thể là do lập trình viên không thêm trạng thái loading hay trạng thái lỗi, có thể do độ phức tạp lớn, cũng có thể là bug của Hey. Tôi không biết, nhưng không hay chút nào
    Với độ trễ từ trung bình đến cao, hành vi trở nên khó đoán hoặc giống bug. Những hộp không có nội dung mở ra, link không hoạt động như kỳ vọng, và khi thực hiện nhiều thao tác nhanh liên tiếp thì chúng không bị hủy theo cách trực quan. Cảm giác đơn giản là lệch nhịp
    Dù SPA có tệ đến đâu, cái này có vẻ là một bước lùi so với hướng làm UI có cảm giác native và tự nhiên

  • Lý do bài này nổi lại bây giờ là vì tuần trước có người đăng rằng Hey mở modal chậm: https://x.com/noahflk/status/1795758603577545035
    Hey do DHH tạo ra, và DHH cũng tạo ra Hotwire cùng Rails. Sau đó mọi thứ trở thành một cuộc tranh luận nóng, trộn lẫn giữa phản bác của DHH rằng video gốc được quay trên mạng bị giới hạn, phản ứng rằng nếu modal mất thời gian để tải thì Hotwire phụ thuộc quá nhiều vào mạng, các bên bênh vực Rails/Hotwire, và các ý kiến phản đối cách tiếp cận này. Đây là chủ đề lớn trên Twitter tuần trước

    • DHH nói video gốc được quay trên mạng bị giới hạn là đúng
      Tác giả cũng viết rằng “cố tình làm chậm để trình diễn”: https://x.com/noahflk/status/1795855075526471915. Người đó nói không nhằm cho thấy trải nghiệm của người dùng “MacBook tốt ở SF với Internet gigabit”, mà muốn nói về người dùng Internet di động chậm và laptop rẻ. Cũng có người chỉ ra rằng SPA Google Calendar còn chậm hơn nhiều, và lựa chọn không chỉ có “Internet gigabit ở SF” với “3G bị giới hạn mạnh”. Bài đăng gốc rất dễ gây hiểu lầm, thực tế gần như là nói dối
    • Link trả lời trực tiếp của DHH: https://x.com/dhh/status/1796163806650868149
    • Khi xem Hey khoảng 1 năm trước, ngay cả từ bên kia Thái Bình Dương nó trông cũng khá nhanh nhạy
      Đặc biệt cấu trúc trang rất ấn tượng. Ví dụ, overlay menu ngữ cảnh áp dụng tổ hợp details/summary/anchor theo hướng progressive enhancement, và kể cả khi tắt JavaScript hoặc asset không tải được, nó vẫn tải nội dung menu một cách thanh lịch bằng layout đơn giản. Ngoài ra còn nhiều chỗ dùng Web API rất cẩn trọng, và tôi nhớ mã client gần như không bị obfuscate, lại có kèm source map. Tôi không phải fan của DHH và cũng không định theo dõi drama tuần đó, nhưng lần này tôi cảm thấy 37signals đã làm đúng
    • Đã sửa rồi. Có thể xem cập nhật ở đây: https://x.com/dhh/status/1797370923391357143

  • Tôi đã tạo Swap JS, một bản triển khai tối giản hơn của cùng ý tưởng, cách đây 2 năm: https://github.com/josephernest/Swap
    Đã thử dùng trong vài dự án và nó hoạt động tốt