- Trong phát triển web hiện đại, sự lựa chọn giả tạo giữa HTML và các framework JavaScript cỡ lớn đang đẩy lập trình viên vào mức độ phức tạp không cần thiết
- HTMX xử lý yêu cầu AJAX, cập nhật từng phần và chuyển cảnh động chỉ bằng các thuộc tính HTML, cung cấp cách đưa trực tiếp HTML do máy chủ trả về lên giao diện
- Có thể áp dụng dần dần mà không cần thay đổi lớn codebase hiện có, từ đó giảm độ phức tạp ở frontend và tăng năng suất lẫn khả năng bảo trì
- So với SPA dựa trên React, trong môi trường production thực tế đã ghi nhận những cải thiện lớn về lượng mã, phụ thuộc, thời gian build và tốc độ tải
- Thay vì chọn framework quá mức, cách tiếp cận dựa trên hypermedia đơn giản có lợi hơn cho năng suất và khả năng bảo trì về dài hạn
Nêu vấn đề: lựa chọn giả tạo trong phát triển web
- Trong các cuộc thảo luận về phát triển web, người ta cứ lặp đi lặp lại những lựa chọn cực đoan: либо chỉ dùng HTML, hoặc dùng framework lớn như React
- HTML thuần có các tính năng cơ bản rất mạnh như link, form,
dialog, nhưng vẫn có giới hạn ở cập nhật từng phần hay khả năng phản hồi tức thời
- Khi chọn React·Vue·Angular, sẽ kéo theo hàng trăm phụ thuộc, build chậm và tranh luận phức tạp về quản lý state
- Ngay cả với các ứng dụng CRUD đơn giản, dashboard hay app thiên về form, thực tế vẫn đang áp dụng hệ công cụ quá mức cần thiết
Khái niệm cốt lõi của HTMX
- HTMX là công cụ thực hiện giao tiếp bất đồng bộ với máy chủ bằng cách thêm các thuộc tính đặc biệt vào phần tử HTML
- Ví dụ, có thể gửi yêu cầu bằng thuộc tính
hx-get, hx-post và chèn phản hồi vào một vùng DOM cụ thể
- Mở rộng để mọi phần tử HTML đều có thể trở thành chủ thể gửi yêu cầu HTTP
- Máy chủ không trả về JSON mà trả thẳng các mảnh HTML, và HTML nhận về sẽ được tự động thay thế hoặc chèn vào vị trí chỉ định
- Định nghĩa hành vi chỉ bằng khai báo thuộc tính HTML mà không cần tự viết JavaScript
- Thư viện rất nhẹ, kích thước khoảng 14kb(gzip)
- Có thể áp dụng ngay vào tài liệu HTML hiện có mà không cần công cụ build hay cấu hình framework riêng
- Cấu trúc rất phù hợp với cách phát triển web truyền thống lấy server-side rendering làm trung tâm
Các tính năng chính
- Xử lý yêu cầu AJAX: thực hiện yêu cầu GET, POST chỉ bằng thuộc tính HTML
- Cập nhật DOM: tự động phản ánh HTML do máy chủ trả về vào phần tử được chỉ định
- Xử lý sự kiện: liên kết lời gọi máy chủ theo các sự kiện người dùng như click, nhập liệu
- Quản lý history: tích hợp với thao tác quay lại và tiến tới của trình duyệt
Trường hợp áp dụng thực tế và số liệu
- Contexte đã chuyển SaaS dựa trên React sang Django + HTMX
- Tổng số dòng mã giảm 67% (21,500 → 7,200)
- Phụ thuộc JavaScript giảm 96% (255 → 9)
- Thời gian build rút ngắn 88% (40 giây → 5 giây)
- Tốc độ tải trang cải thiện 50~60%
- Đã xóa đi hai phần ba codebase mà ứng dụng lại còn tốt hơn
- Không cần tách riêng frontend và backend, mọi lập trình viên đều có thể làm full-stack
Tổng hợp các phản biện thường gặp
- "Chẳng phải cần quản lý state phía client phức tạp sao?"
- Trên thực tế, phần lớn chỉ ở mức form, danh sách, các phần tử xuất hiện theo thao tác click, và HTMX là đủ để xử lý
- Công cụ cộng tác thời gian thực như Google Docs là ngoại lệ, nhưng đa số đang đánh giá quá mức ứng dụng CRUD
- "Còn lợi ích từ hệ sinh thái React thì sao?"
- Hệ sinh thái đồ sộ đó cũng đồng nghĩa với node_modules nặng hàng GB, vô số lựa chọn và tranh cãi về quản lý state
- Hệ sinh thái của HTMX kết thúc gọn ở một ngôn ngữ server-side mà bạn chọn
- "SPA chẳng phải nhanh hơn về cảm nhận sao?"
- Ban đầu vẫn phải đi qua toàn bộ quá trình tải JavaScript dung lượng lớn, parse, thực thi và hydration
- HTMX tải nhanh ngay từ đầu, và về sau cũng giữ tốc độ phản hồi bằng cách chỉ thay phần đã thay đổi
- "Nếu thực sự cần một số tính năng riêng của React thì sao?"
- Trong một số trường hợp, React có thể là lựa chọn phù hợp
- Nhưng trên thực tế, nhiều người lại chọn theo thói quen một công cụ chỉ cần cho một phần nhỏ của toàn bộ vấn đề
- Vì sao nên chọn HTMX?
- Lý do team thất bại không phải vì framework sai, mà là vì chọn framework quá mức cần thiết
- HTMX là đặt cược vào sự đơn giản, và về dài hạn sự đơn giản có lợi thế về khả năng bảo trì và năng suất
Khi HTMX không phù hợp
- Công cụ biên tập cộng tác thời gian thực (Google Docs, Figma)
- Ứng dụng cần tính toán lớn ở phía client (trình biên tập video, công cụ CAD)
- Kiến trúc ưu tiên offline trước (dù tất nhiên vẫn có thể kết hợp nhiều cách tiếp cận)
- Trường hợp thực sự đòi hỏi state UI phức tạp
- Nhưng liệu bạn có thực sự đang làm những thứ đó không?
- Hay bạn chỉ đang làm thêm một dashboard, bảng quản trị, trang thương mại điện tử, blog, hay ứng dụng SaaS khác với form, bảng và danh sách là chính?
- Với những thứ như vậy, HTMX thật sự hiệu quả đến kinh ngạc, đến mức bạn sẽ muốn tự hỏi: "Sao mình lại làm phức tạp đến vậy?" "Trời ơi, mình đã lãng phí quá nhiều thời gian rồi"
Vậy nên hãy thử một lần
- Bạn đã dùng React, đã dùng Vue, và cũng từng dùng thử Angular rồi thấy hối hận, đúng không?
- Có khi cả meta framework đang hot tuần này trên Hacker News bạn cũng đã sờ qua một lần rồi
- Hãy cứ thử HTMX đúng một lần thôi
- Dành ra khoảng một ngày cuối tuần
- Chọn một side project
- Hoặc chọn một công cụ nội bộ mà chẳng mấy ai quá bận tâm
- Hoặc lôi ra thứ bạn đã hoãn làm lại từ lâu
- Chỉ cần thêm một thẻ
<script> và viết một thuộc tính hx-get, rồi tự mình xem nó hoạt động
- Trong trường hợp tệ nhất, bạn chỉ mất một ngày cuối tuần, thiệt hại cũng không lớn
- Nhưng có lẽ bạn sẽ không ghét nó đâu
- Thực ra, rất có thể bạn sẽ tự hỏi vì sao phát triển web lại từng trở nên phức tạp đến thế
5 bình luận
Thật đáng tiếc khi mọi thứ dường như đã trở nên cố định sau khi đã quá quen thuộc với tình trạng hiện tại và xây dựng nên một hệ sinh thái lớn đến như vậy, đến mức không còn thấy được động lực nào cho đổi mới nữa.
Tôi nhớ là từng nghe một bài nói chuyện liên quan tại PyCon, và diễn giả khi đó cũng nói rằng họ vẫn chưa có dịp dùng nó trong công việc thực tế.
Rust, làm ơn hãy thử dùng một lần được không?
Tôi đã từng thử Alpine.js, nhưng hầu hết vẫn cần quản lý trạng thái...
Trừ khi ngay từ đầu được thiết kế để backend quản lý trạng thái, tôi nhớ rằng việc xử lý trạng thái theo từng bước, trạng thái có điều kiện, v.v. khá đau đầu.
Ý kiến trên Hacker News
Tôi là người tạo ra htmx. Tôi cảm ơn vì được chú ý nhờ những bài viết hơi cường điệu, nhưng tôi không thích kiểu thổi phồng như vậy lắm
Có nhiều cách để xây dựng ứng dụng web, và mỗi cách đều có ưu và nhược điểm. Tôi đã tổng hợp điểm mạnh và điểm yếu của htmx trong bài viết này
Tôi cũng khuyên mọi người nên thử Unpoly, một thư viện định hướng hypermedia rất tuyệt vời khác
(Bổ sung) Xem lại nội dung bài viết thì thấy nó ổn hơn tôi nghĩ. Dù vậy, tôi vẫn mong htmx được nhắc đến với bầu không khí điềm tĩnh hơn
Cập nhật trường bằng dropdown, tạo modal, ô tìm kiếm tự động hoàn thành, tất cả đều đơn giản
Tuy nhiên, độ phức tạp của frontend RIA nằm ở chỗ cập nhật frontend thế nào khi dữ liệu thay đổi.
Sẽ tốt hơn nếu có chút điều chỉnh ở backend và một cấu trúc có thể xử lý nhiều partial update cùng lúc
Hiện tôi đang làm side project với Rails + Stimulus, và thấy Stimulus lại hơi quá tay. Tôi muốn biết khi nào nên chọn Inertia hay Stimulus
Đây là plugin Alpine.js thêm chức năng AJAX cơ bản cho link và form
Tôi đã chán ngán những bài viết khẳng định nó tốt hơn React chỉ bằng ví dụ “Hello World”
Với ví dụ đơn giản thì cái gì cũng chạy tốt. Nhưng thực tế phần lớn là backend có nhiều dependency và UI phức tạp
Demo cơ bản thì ổn, nhưng cần cho thấy có thể mở rộng thế nào khi thêm các tính năng phức tạp hơn
Tôi muốn biết sẽ thêm JS ở đâu, có cần build step không, và sẽ bị ràng buộc với mô hình của htmx đến mức nào
Không hẳn là tốt hơn React, mà chỉ là một cách tiếp cận khác
Mô hình thay thế một phần DOM rất đơn giản và trực quan
Ví dụ: effect-ts rất mạnh, nhưng chỉ để in ra đơn giản cũng đã phức tạp
Startup của chúng tôi từng áp dụng HTMX nhưng cuối cùng đang chuyển sang React
HTMX có độ phức tạp xử lý phản hồi cao, và mỗi endpoint phải trả về nhiều mảnh HTML khác nhau
Thiếu tài liệu và ví dụ thực tế, cũng không có best practice ở quy mô lớn.
React đã trưởng thành hơn, và cũng hợp với AI coding hơn. HTMX phù hợp cho dự án đơn giản, nhưng vượt quá mức đó thì khó
Mỗi endpoint chỉ làm một việc, và dùng Optimistic UI để phản hồi ngay lập tức
Xử lý lỗi theo cách đơn giản, dùng
hx-swap-oobở mức tối thiểuĐiều cốt lõi khi chọn công nghệ là giảm thiểu trade-off
Vì vậy tôi đặt trọng tâm vào kiểm tra hợp lệ ở backend, còn frontend chỉ đơn giản là hiển thị
Tôi không muốn SSR. Backend chỉ cung cấp JSON API, còn frontend thì tiêu thụ nó
Tôi nghĩ SSR là một khái niệm bị thổi phồng quá mức. Giống như chiêu dẫn dắt để bán dịch vụ cloud
Ví dụ Demo 3 Live Search có vấn đề giật khi cuộn (jank) khá nặng.
Có vẻ kết quả được chèn trực tiếp vào tài liệu nên bố cục cứ bị tính toán lại liên tục
React hoàn toàn đủ tốt. Kể cả với dự án đơn giản cũng không có lý do gì phải học thêm một mô hình khác
Trong khi đó HTMX chỉ cần 15 phút để nắm khái niệm, và có thể dùng được 10 năm
Trong lịch sử, các mô hình nhẹ hơn thường thắng trên thị trường. React cũng từng là một ví dụ như vậy
Tôi không mê HTMX mà là Alpine.js
Khái niệm tăng cường (enhance) HTML do server render thực sự khiến tôi thông suốt
Dropdown, show/hide, mọi thứ đều trực quan và không cần build step
Nó trực quan và dễ quản lý cả trong dự án lớn
Nếu cứ nhúng JS inline vào HTML thì việc bảo trì sẽ khó khăn, và quản lý state cũng trở nên ngầm định
Tôi thấy Hotwire hay Stimulus tốt hơn nhiều ở quy mô tổ chức
Nếu dùng HTMX cho ứng dụng quy mô lớn thì tôi tò mò về tải và chi phí phía server
Vì render HTML ở server nên có vẻ sẽ tốn tài nguyên hơn JSON
Nhiều khi còn hiệu quả hơn cả serialize JSON, và phía client cũng có chi phí deserialize
Nếu dùng HTMX cùng các công cụ như Alpine.js thì cả state phức tạp cũng có thể xử lý dễ dàng
Nó không hợp cho mọi tình huống, nhưng trong nhiều trường hợp hoạt động rất tốt
Việc truyền đạo framework là văn hóa tệ nhất của hệ sinh thái web
Nếu là giải pháp tốt thì sớm muộn cũng sẽ được chấp nhận. Không cần phải cư xử như nhà truyền giáo
Chuyện tấn công npm cũng bị phóng đại. htmx rốt cuộc vẫn có thể phải dùng npm
Trên đời có rất nhiều giải pháp tệ vẫn được dùng nhờ marketing và độ nhận diện
Nếu muốn giữ gìn tay nghề thực sự thì phải chống lại những thiên kiến này
HTMX có vẻ như chỉ gom nhược điểm của cả hai thế giới
SSR thì gắn kết, CSR thì tách bạch, còn HTMX trộn cả hai nên sinh ra sự liên kết ngầm
Nếu muốn hiển thị cùng một dữ liệu theo định dạng khác thì có phải tạo hai endpoint ở backend không
Phần lớn ứng dụng chỉ cần state ở backend là đủ, và ngoài việc cải thiện UX thì không đem lại lợi ích lớn nào
Nếu toàn bộ trang được ghép ở server thì dữ liệu đã nằm sẵn trong đó