Giới thiệu trên HN: HTMX Playground được triển khai 100% trên trình duyệt

 (lassebomh.github.io)
6 điểm bởi GN⁺ 2024-01-09 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đây là một code sandbox cho phép thử nghiệm HTMX ngay trong trình duyệt mà không cần cài đặt hay cấu hình local
  • Trong server.js, bạn xử lý endpoint và render template; các request HTMX sẽ được một mock server trong trình duyệt chặn lại
  • Cách xử lý request và template quen thuộc với người dùng Django, và cũng có thể dùng để thử nghiệm các thư viện ngoài HTMX
  • Việc chia sẻ được thực hiện bằng cách xuất qua “Copy as JSON”, rồi nhập Gist raw URL vào “Load Playground”
  • Cần lưu ý các hạn chế như không có điều hướng trang, hỗ trợ mobile còn hạn chế, và việc mất cập nhật trạng thái trong on.get("/") do iframe được tải ban đầu

HTMX sandbox chạy trong trình duyệt

  • HTMX Playground là một code sandbox đơn giản cho phép thử nghiệm HTMX mà không cần cài đặt
  • Cung cấp các ví dụ được chuyển thể từ htmx.org examples gốc
  • Có thể viết code theo luồng tương tự backend ngay trong trình duyệt
    • Định nghĩa endpoint trong server.js
    • Có thể tự render template
    • Một mock server chặn các request gửi ra từ HTMX sẽ hoạt động
  • Cách xử lý request và template engine có dạng quen thuộc với người dùng Django
  • Bản thân dự án không chỉ giới hạn ở HTMX, nên cũng có thể thử các thư viện khác
  • Mã nguồn được công khai trên GitHub

Cách lưu, chia sẻ và các hạn chế đã biết

  • Lưu và chia sẻ

    • Nhấn “Copy as JSON” ở góc trên bên phải để sao chép nội dung
    • Tải nội dung đã sao chép lên Gist
    • Nhập raw URL vào “Load Playground”
    • Khi URL của trang được cập nhật, bạn có thể chia sẻ

  • Hạn chế

    • Không có điều hướng trang
    • Hỗ trợ mobile còn hạn chế
    • server.js có thể giữ trạng thái, như trong ví dụ Click to Edit
    • Nếu cập nhật trạng thái trong view on.get("/"), cập nhật đó có thể bị mất
      • Vì lần tải trang ban đầu được fetch trước trong một iframe riêng, trước khi cập nhật iframe trên màn hình

  • Thư viện sử dụng

    • Svelte
    • Ace
    • PollyJS
    • Nunjucks

Bài viết liên quan

1 bình luận

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

  • Tôi là người tạo ra htmx, thật sự cảm ơn vì đã làm cái này và tôi thấy nó rất tuyệt

    • Tôi thắc mắc liệu có cách nào dùng HTMX với thay đổi phía máy chủ ở mức tối thiểu không
      Trên trang hiện có, khi điền và gửi biểu mẫu thì phản hồi trả về là cả trang; nếu có thể bảo htmx rằng “cả trang sẽ được trả về, nhưng chỉ cập nhật #my-form”, thì có vẻ sẽ không cần thêm nhánh kiểu “nếu là yêu cầu htmx” trên máy chủ
      Điều này sẽ tốt cho những người muốn trang vẫn hoạt động mà không cần JavaScript, và cũng có thể xử lý nhiều chức năng như bình luận, đăng ký email, nút thích bằng một endpoint backend duy nhất
    • Tôi thắc mắc liệu bạn đã nghe về Phoenix LiveView chưa, và nó có phải là khái niệm tương tự htmx không

  • Tôi từng định dùng HTMX một cách nghiêm túc, nhưng lo rằng nguồn lập trình viên quá nhỏ nên sẽ khó tuyển dụng
    Tôi từng quen với một framework độc quyền tương tự Thymeleaf như isml của Intershop, và gần đây định chuyển sang stack frontend Angular vì dễ tuyển lập trình viên frontend chuyên trách hơn
    Cách tiếp cận như htmx có thể trở nên phức tạp, các lập trình viên không muốn chiến đấu với quái vật spaghetti, và nếu frontend chỉ tạo HTML còn backend phải ghép mọi thứ lại thì lập trình viên backend có thể trở thành nút thắt cổ chai
    Tôi thắc mắc HTMX có tính đến những cạm bẫy này không, và đối phó như thế nào

    • htmx rất trực quan để học, nên nếu không phải là người xuất thân từ bootcamp lập trình chỉ học React, thì một lập trình viên biết các chủ đề khoa học máy tính thực tế có lẽ có thể làm việc hiệu quả trong tối đa một tuần
    • Cách đối phó khá đơn giản: HTMX mất chưa đến nửa ngày để học, và có lẽ còn nhanh hơn
      Tuy nhiên HTMX không giải quyết mọi tình huống; cũng có lúc cần ứng dụng một trang dùng framework JavaScript
    • Việc nhắc đến Angular rồi nói htmx có thể trở nên phức tạp khá thú vị, có vẻ góc nhìn về độ phức tạp khác nhau
      Các framework như Angular đem lại cấu trúc, nhưng độ phức tạp vẫn còn đó, và có lẽ còn lớn hơn nhiều
      Cuối cùng, thứ cần thiết là lập trình viên frontend hiểu rõ web stack như JavaScript, CSS, HTML, API trình duyệt; những người như vậy có thể chọn công cụ và framework phù hợp với công việc, và học HTMX khá nhanh
    • Không gì thuyết phục bằng thành công, và htmx đã đứng thứ 2 hạng mục framework trong JS Rising Stars năm 2023
      https://risingstars.js.org/2023/en#section-framework
      Nó ngay sau React và đứng trước Vue, Svelte, Angular, nên xét theo điểm đó thì tương lai có vẻ tốt. Tuy nhiên tôi dự đoán thứ hạng sẽ giảm khi sự hào hứng ban đầu lắng xuống
      htmx khá đơn giản nên hầu hết lập trình viên web có thể học trong khoảng một ngày, nhưng vì cách phát triển này đẩy tổ chức sang mô hình full-stack, trong đó lập trình viên sở hữu trọn vẹn một tính năng, nên không chỉ lập trình viên mà cả PM và kiến trúc sư cũng cần thay đổi tư duy
      Cũng có sách trực tuyến miễn phí: https://hypermedia.systems
      Ngoài tài liệu (https://htmx.org/docs, mất khoảng một giờ để đọc), còn có các bài viết bàn về những vấn đề triết lý và thực tiễn của htmx và hypermedia nói chung: https://htmx.org/essays
      htmx có rất ít ý tưởng cốt lõi, và cố gắng được xây dựng theo hướng “có thể mở rộng”, đến mức các hành vi hữu ích như tải lười cũng có thể triển khai bằng hai thuộc tính: https://htmx.org/examples/lazy-load
      Đồng thời nó cũng có các hook như sự kiện hoặc bộ lọc sự kiện, cùng những tính năng sâu hơn, nên nếu đi sâu hơn bạn có thể triển khai hành vi mong muốn
      Mã spaghetti luôn là rủi ro trong mọi hoạt động phát triển phần mềm, và cá nhân tôi không tin chắc rằng các thư viện ứng dụng một trang sẽ ngăn được spaghetti
      Với htmx, nên tập trung nỗ lực vào backend và phân rã ứng dụng tốt bằng các công cụ mà môi trường phía máy chủ cung cấp
      Vì htmx cho phép chọn bất kỳ công nghệ máy chủ nào, nó đem lại nhiều lựa chọn và mô hình tổ chức logic ứng dụng hơn so với ứng dụng một trang, nơi đã có một ứng dụng JavaScript/TypeScript lớn ở frontend và kéo backend đi theo hướng đó
      Tôi cũng đã cố gắng tổng hợp ở đây xem htmx là lựa chọn tốt cho loại ứng dụng nào: https://htmx.org/essays/when-to-use-hypermedia/
      htmx là công cụ tốt trong nhiều trường hợp, nhưng vẫn chỉ là một công cụ, không phải lời giải vạn năng cho phát triển web
    • Về tuyển dụng, gần với việc xem năng lực backend hơn là kinh nghiệm HTMX
      Tức là tuyển lập trình viên backend có thể làm một chút frontend, nên không cần có HTMX trong CV, chỉ cần những kiến thức cơ bản như JavaScript là được
      Phần lớn lập trình viên web đều đáp ứng điều kiện đó

  • Tôi đã dùng MapLibre cùng Django và htmx, chắc nên đăng ví dụ lên để chia sẻ với mọi người

    • Tôi cũng làm một thứ tương tự là https://ratethispad.com, và quá trình làm khá thú vị
      Dù chẳng ai dùng, nhưng tôi cũng muốn xem dự án đó
    • Tôi không có gì có thể chia sẻ công khai, nhưng đã làm việc với Django, htmx, SQLAlchemy, Plotly và thấy khá vững chắc
    • Nếu muốn chuyển thêm các ví dụ chính thức, hãy tạo issue kèm liên kết, rồi có thể thêm vào kho lưu trữ

  • Theo tôi biết, Monaco về mặt thiết kế không hoạt động trên di động nên trên di động người ta dùng Ace
    Ít nhất lần cuối tôi kiểm tra issue trên GitHub là như vậy
    [0] https://github.com/Microsoft/monaco-editor/issues/246

  • Cái này có hỗ trợ ActiveX không?

    • Buồn là mình đã đủ già để hiểu trò đùa này
    • Làm mình nhớ đến HP Quality Center
      Các phiên bản đầu có toàn bộ UI là ActiveX, và mình còn nhớ thấy đầy thanh tiến trình cài DLL

  • Có thể dùng Service Worker để làm thứ như thế này, rồi cho phép mở nhiều trang ở các tab khác để duyệt
    Có vẻ cũng không khó lắm, và việc tạo trang có thể dùng JavaScript thuần hoặc bất cứ thứ gì người dùng muốn

  • Làm bằng Svelte à, vậy những người theo chủ nghĩa thuần MPA và đinh ba đâu rồi?

    • Là người theo chủ nghĩa thuần MPA, nhưng tôi cũng hoàn toàn thừa nhận có một lớp ứng dụng mà app một trang là lựa chọn tốt nhất

  • Tôi thích ý tưởng của htmx nên hôm nay bắt đầu đọc sách, nhưng mỗi khi nghĩ rằng một ngày nào đó cũng phải hỗ trợ ứng dụng di động native thì lại chùn tay không dám dùng
    Trong trường hợp đó có lẽ không chỉ frontend mà cả một phần lớn backend cũng phải viết lại
    Tôi biết hyperview.org, nhưng với use case tôi quan tâm thì app React Native là chưa đủ

  • Tôi tự hỏi có ai đang tạo app offline bằng một máy chủ ảo định nghĩa trong Service Worker và theo kiểu request-response HTML/HTMX không

    • Câu hỏi hay
      Tôi thích htmx nhưng không dùng được trong những tình huống cần hoạt động offline
      Nếu có thể chạy nguyên server code trong worker thì sẽ là một hack rất hay
    • Tôi đang làm một server/backend cho htmx chạy như một service cục bộ bên cạnh trình duyệt
      Về lý thuyết, bất cứ server stack nào có thể tự host đều dùng được
      Mục tiêu là tạo một single binary không phụ thuộc dịch vụ bên ngoài, và tôi đang dùng Go
      Các thành phần như service cục bộ tự cập nhật, cơ sở dữ liệu sao chép đã chuẩn bị được khá nhiều, và cross-compile cho nhiều hệ điều hành và kiến trúc cũng dễ
      Như một phương án thay thế cho việc nhét mọi thứ vào trình duyệt, cách này có vẻ khá hợp lý với giả định có thể chạy một tiến trình riêng
      Có điều tôi ước Go cũng có quản lý quyền như Deno
    • Có ví dụ thực tế: https://github.com/jon49/htmx-todomvc
      Tôi dùng mẫu này cho tất cả app cá nhân, chỉ là dùng một thư viện nhỏ kiểu htmx do tôi tự viết
      Chuyển sang HTMX có lẽ cũng không khó lắm

  • Tôi tự hỏi liệu đưa HATEOAS sang phía app desktop hoặc mobile có phải là ý hay không, và có thể là một thử nghiệm thú vị

    • Nếu đang nói về mobile native, khoảng năm 2013 tôi từng dùng HATEOAS trong code native
      Nó chạy tốt nhưng không linh hoạt như web, và phải phát triển từng màn hình có thể liên kết theo kiểu hộp đen rất nghiêm ngặt
      Bản thân thử nghiệm thì thú vị, nhưng tôi không chắc nó đáng dùng trong production đến mức nào
    • Tôi chỉ xem HATEOAS như một khái niệm trừu tượng, chứ chưa từng cảm thấy trong UI thực tế rằng “tương tác người dùng thực sự tốt hơn rồi”
      REST được hoan nghênh vì đã đơn giản hóa các quái vật SOAP, nhưng cũng kéo theo khá nhiều tính giáo điều
      Tôi hiểu mục đích căn bản của REST, vì nó khớp kiến trúc khái niệm, dữ liệu và dịch vụ với những gì tự nhiên với người dùng
      Nhưng HATEOAS có vẻ giống kết quả của việc muốn có thêm giáo điều và màu mè trong các cuộc họp kiến trúc, hơn là tập trung vào việc trải nghiệm người dùng có tốt hơn nhờ mô hình hay không
      Tôi tò mò liệu có ví dụ UI nào cho thấy vì sao nên lấy HATEOAS làm nguyên tắc cơ bản không
      Về cơ bản, mỗi trang đều có liên kết đến “việc cần làm tiếp theo”, và HATEOAS với tôi giống một cách hào nhoáng để đưa mô hình trạng thái đó vào các lệnh gọi dịch vụ REST
    • Tôi còn tự hỏi trước hết HATEOAS có phải là ý hay không
    • Đây này: https://hyperview.org/