HTMX quá hay nên tôi đã tự làm một bản (2024)

• HTMX là một cách tiếp cận phát triển từ kiểu làm web trước khi giao diện JavaScript hiện đại kiểu React trở nên phình to, tập trung vào HTML được render từ máy chủ và nâng cấp dần frontend
• Khi thay SvelteKit bằng DinoSsr trong quá trình refactor máy chủ cho podcast web app tự host, đã xuất hiện vấn đề chuyển trang làm ngắt phát âm thanh, và với HTMX có thể chỉ cập nhật vùng `` để giữ nguyên component âm thanh
• HTMX được phân phối như một thư viện frontend, nhưng phần lớn triển khai lại nằm ở template backend và cấu hình máy chủ; các request HTTP trả về HTML thực chất đóng vai trò như API của HTMX
• Các thuộc tính hx-*, ví dụ `` có thể bấm được, và một số ví dụ nâng cao có nhiều JavaScript inline cho thấy giới hạn của template thuộc tính khai báo và là điểm gây khó chịu trong tài liệu
• Bản triển khai mini tự làm dùng cache 304, History API, thay thế `` và preload dựa trên pointer event làm các thành phần chính, giúp giảm JavaScript trên trình duyệt và khiến codebase nhỏ hơn, đơn giản hơn

---

Vị trí của HTMX

• HTMX bác bỏ giao diện JavaScript hiện đại và ưu tiên HTML render từ máy chủ, là một cách tiếp cận phát triển từ kiểu làm web trước khi frontend bị React làm phình to
• Cuộn vô hạn và kết quả tìm kiếm thời gian thực là những ví dụ HTMX phổ biến; HTMX không giải quyết mọi vấn đề mà React và các công cụ tương tự nhắm tới, nên có vẻ bị giới hạn, nhưng trong chính các giới hạn đó nó là một công cụ rất có giá trị
• HTMX không phải là “magic bullet”, và quan điểm cốt lõi ở đây là một số ý tưởng phía sau HTMX còn quan trọng hơn chính HTMX

Thử nghiệm

• Chỉ đọc tài liệu là chưa đủ nên tác giả đã thử dùng thực tế, và đối tượng áp dụng HTMX là đợt refactor máy chủ cho podcast web app tự host
• Bản triển khai trước dùng SvelteKit; đây là công cụ ưa thích nhưng có thể hơi nặng với các website nhỏ
• Thứ được dùng để thay thế là DinoSsr do tác giả tự làm; cùng dự án này cũng được dùng để build site tĩnh và cung cấp blog dạng bookmark
• DinoSsr chủ yếu dựa vào phía máy chủ; nó có thể cung cấp component dưới dạng frontend “islands”, nhưng không được thiết kế để cung cấp tương tác toàn trang
• Component trình phát âm thanh cần được giữ nguyên khi chuyển trang; nếu điều hướng làm tải lại toàn bộ trang thì trải nghiệm phát sẽ nhanh chóng bị chấm dứt
• SvelteKit xử lý cập nhật UI và routing phía frontend, nhưng trong bản build mới chỉ component trình phát âm thanh dùng JavaScript frontend, còn DinoSsr thì chủ ý không thử làm routing phía client
• Một vài trang chỉ khác nhau ở phần `` nên nếu dùng HTMX để nâng cấp dần các liên kết và chỉ cập nhật vùng này thì có thể giữ nguyên component âm thanh mà không phải tải lại toàn bộ trang
• Việc áp dụng HTMX hoạt động tốt, nhưng ngay sau đó tác giả đã gỡ HTMX và chuyển sang một phiên bản mini tự làm dựa trên cùng ý tưởng

Một vài suy nghĩ về HTMX

• Trong thử nghiệm này, HTMX là vật thay thế cho Svelte ở frontend, nhưng không phải kiểu thay thế có thể cắm vào ngay như React, mà là một sự thay đổi lớn về tư duy
• HTMX được phát hành như một thư viện JavaScript để nâng cấp dần frontend, nhưng phần lớn việc triển khai lại diễn ra ở backend; bạn phải tự chuẩn bị template máy chủ và cấu hình tương ứng
• Các request HTTP cung cấp HTML thực chất đóng vai trò như API của HTMX, và các chi tiết như thiết lập HTTP header cho cache đúng cách là rất quan trọng
• Dù đã có thuộc tính chuẩn data-* và dataset, việc dùng các thuộc tính tiền tố hx-* không chuẩn là một điểm khó chịu nhỏ
• Tài liệu HTMX có nhiều ví dụ ``; ví dụ dưới đây là cấu trúc trong đó khi người dùng bấm vào div, một request PUT sẽ được gửi tới /messages và phản hồi sẽ được nạp vào chính div đó

    Put To Messages

• Việc có những ví dụ yêu cầu người dùng bấm vào phần tử `` bị phê bình là không mong muốn
• Một số ví dụ HTMX nâng cao dùng JavaScript inline trở nên khá lộn xộn, cho thấy giới hạn của template thuộc tính khai báo
• Dù có những phê bình như vậy, HTMX vẫn cung cấp một tập tính năng hữu ích dù có giới hạn, và là công cụ có thể cải thiện nhiều mẫu thiết kế web phổ biến

Tự làm

• Ngay sau khi thêm HTMX thành công, tác giả đã gỡ nó ra và tự triển khai một phiên bản mini bằng chính các ý tưởng đó
• Để cho phép các request fetch được cache, tác giả dùng các HTTP header last-modified, if-modified-since và phản hồi 304
• Để tích hợp lịch sử cơ bản, tác giả dùng pushState và popstate
• Tác giả thêm mã để trích xuất và thay thế phần tử ``, đồng thời tích hợp sẵn preload dựa trên pointer event, lấy cảm hứng từ HTMX preload extension
• Preload dựa trên pointer event sẽ bắt đầu request fetch trước khi sự kiện click xảy ra, mang lại một cải thiện hiệu năng nhỏ
• Mã nguồn thử nghiệm rất cơ bản, nhưng cho thấy lượng JavaScript thực sự cần trong trình duyệt là khá ít
• Dù là dùng HTMX hay kiểu “we have HTMX at home”, kết quả là codebase trở nên nhỏ hơn nhiều và đơn giản hơn

JavaScript frontend

• Template và component gần như là cần thiết cho tổ chức mã và tái sử dụng, trừ khi đó là một website rất nhỏ; chúng cũng có thể được triển khai phía máy chủ bằng PHP, Ruby, Go, JavaScript, v.v.
• Không nhất thiết phải sao chép cấu trúc đó vào trình duyệt hoặc chỉ triển khai nó trong trình duyệt, nhưng với sự phổ biến của React và các công cụ tương tự, nhiều lập trình viên đã ngừng đặt câu hỏi này
• Sự mệt mỏi với JavaScript frontend là có thật, và gắn liền với kinh nghiệm vừa thích các template máy chủ kiểu cũ vừa từng thiết kế quá tay các JS UI
• Ngay cả khi bản thân HTMX không hẳn là quá xuất sắc, triết lý của nó vẫn là một cách tiếp cận có giá trị mạnh đến mức đủ khiến các lập trình viên JavaScript hiện đại phải thấy ngượng

[GN⁺]

Ý kiến trên Lobste.rs

• Bắt bẻ chút thôi, nhưng tôi không thích việc dùng các thuộc tính HTML tiền tố hx-* ở những chỗ lẽ ra nên dùng data-* Htmx từ lâu đã hỗ trợ tiền tố data- Về điểm không nên khiến người dùng bấm vào các phần tử `` thì tốt nhất là dùng hx-boost của htmx trên thẻ anchor và form. Nó sẽ tự động tăng cường các thẻ này theo cách đúng đắn, nên có thể tránh được các div có thể nhấp Đây là một dự án cho thấy trình duyệt thực sự cần rất ít JavaScript đến mức nào, và về sau việc bảo trì có lẽ sẽ ở mức tối thiểu, các bản vá bảo mật cũng gần như không cần. Đáng chúc mừng

• HTMX render mọi thứ như vậy có làm máy chủ quá tải không? Cảm giác khá giống vấn đề CGI ngày xưa

  • Gần như chắc chắn là không. Vấn đề của CGI chủ yếu là chi phí khởi tạo nhiều tiến trình sống ngắn, và điều đó đã được giải quyết bằng những thứ như FastCGI Việc tạo HTML không hẳn là tác vụ đắt đỏ, và cũng khó nói là tốn hơn việc tạo ra lượng JSON tương đương theo cách thay thế
  • “Chúng tôi” là sao thì tôi không rõ. Blog của tôi dùng CGI, máy chủ render HTML và hoàn toàn không có JavaScript Từ năm 1999 đến giờ chưa có vấn đề gì, và như mọi khi, chỗ nào thực sự là nút thắt cổ chai thì phải kiểm tra bằng profiling
  • Thường người ta gọi là server-side rendering, nhưng thực ra nó gần hơn với việc tạo HTML thô trên máy chủ. Việc render thực tế và tạo DOM vẫn do trình duyệt làm, và xưa nay vẫn thế Kể cả nếu tính cả PHP vào nhóm CGI, thì như vậy là đang bỏ qua khoảng mười lăm năm phát triển web khi cách này từng là tiêu chuẩn Đúng là nó khiến máy chủ phải làm nhiều việc hơn, nhưng tôi cho rằng lý do chính khiến nhiều xử lý bị đẩy sang phía client trong thời gian qua gần hơn với một rủi ro đã được tính toán để giảm chi phí. Nhiều người dùng cuối không nhận ra việc trình duyệt phải làm nhiều hơn, nhưng trên các thiết bị cũ hoặc hiệu năng thấp thì trải nghiệm vẫn tệ đi, đặc biệt là lúc ban đầu Tuy vậy HTMX không giống hoàn toàn với server-side rendering đầy đủ. Thay vì API gửi dữ liệu bằng JSON để client render thành HTML, máy chủ gửi cùng dữ liệu đó dưới dạng các mảnh HTML. Dù vậy, nếu máy chủ bị đập quá mạnh thì có lẽ là do yếu tố khác chứ không phải vì nó vốn dĩ tiêu tốn tài nguyên hơn REST API
  • Khó khẳng định nếu không có benchmark, nhưng có vẻ là tương đương. Cả hai trường hợp cuối cùng đều chỉ là xuất ra một đống ký tự, khác biệt nằm ở chỗ render text đắt hơn hay tạo JSON đắt hơn Theo kinh nghiệm của tôi thì khi dùng JSON người ta thường có xu hướng serialize nhiều thứ hơn, nhưng tôi cũng không rõ cách nào để so sánh cho chuẩn
  • Trong các ứng dụng phía máy chủ, hiếm khi bước render HTML thực sự là nút thắt cổ chai; nút thắt thường nằm ở các bước trước đó

• Vì những lý do tương tự, tôi đang dùng alpine-ajax, vốn rất giống htmx

  • Tôi cũng rất thích alpine-ajax. Nếu bắt đầu lại với mục tiêu “lấy ưu điểm của SPA trong SSR” thì có lẽ tôi sẽ chọn hướng đó Dù sao thì tôi cũng đang dùng alpine cho các tính năng phản hồi phía client. Chỉ là hiện tại trong kho mã đã có khá nhiều htmx, và tôi cũng không có gì bất mãn với htmx
  • Tôi đang dùng datastar, và trải nghiệm làm việc với nó khá dễ chịu