- htmx đã được chọn vào khóa đầu tiên của GitHub Open Source Accelerator, qua đó có cơ hội hợp tác và học hỏi cùng các dự án mã nguồn mở đã trưởng thành
- Lần tham gia này sẽ là dịp để giới thiệu hypermedia và cách tiếp cận của htmx tới cộng đồng nhà phát triển rộng lớn hơn
- htmx dự định tận dụng thời gian trong Accelerator để bắt đầu công việc cho htmx 2.0
- Để tiếp tục duy trì và phát triển dự án, một nhiệm vụ quan trọng khác là học cách biến công việc với htmx thành một nghề nghiệp toàn thời gian
- Các dự án được chọn cùng đợt trải rộng trên nhiều lĩnh vực mã nguồn mở như bảo mật, tài liệu, xác thực, thông báo, CMS..., cho thấy phạm vi của GitHub Accelerator
Cơ hội mà htmx có được
- htmx đã được chọn vào khóa đầu tiên của GitHub Open Source Accelerator
- Nhờ lần được chọn này, htmx có thể học hỏi và hợp tác với các nhà phát triển mã nguồn mở và dự án thành công
- htmx cho rằng thông qua chương trình này, họ có thể quảng bá hypermedia và htmx rộng rãi hơn
- Có hai mục tiêu chính trong thời gian tham gia Accelerator
- Bắt đầu công việc cho htmx 2.0
- Học cách biến công việc với htmx thành một nghề nghiệp toàn thời gian
Các dự án mã nguồn mở được chọn cùng đợt
- BoxyHQ: Bộ sản phẩm API cho bảo mật và quyền riêng tư, giúp các nhóm kỹ thuật xây dựng và triển khai ứng dụng đám mây tuân thủ quy định nhanh hơn
- Cal.com: Công cụ lên lịch giúp sắp xếp cuộc họp mà không cần trao đổi email qua lại nhiều lần
- Crowd.dev: Tập trung dữ liệu cộng đồng, sản phẩm và khách hàng để giúp xác định công ty nào đang tham gia vào các dự án mã nguồn mở
- Documenso: Giải pháp thay thế DocuSign mã nguồn mở, hướng tới xây dựng niềm tin thông qua self-hosting và khả năng kiểm tra cách hệ thống hoạt động
- Erxes: Giải pháp thay thế HubSpot mã nguồn mở, cho phép tạo trải nghiệm phù hợp với nhiều loại hình doanh nghiệp thông qua một XOS duy nhất
- Formbricks: Có thể gửi khảo sát đến các nhóm người dùng được phân khúc chi tiết ở bất kỳ điểm nào trong hành trình người dùng, đồng thời thu thập nhiều insight hơn tới 6 lần bằng các micro-survey nhắm mục tiêu
- Forward Email: Dịch vụ chuyển tiếp email miễn phí cho tên miền tùy chỉnh, đã được các nhà sáng tạo, nhà phát triển và doanh nghiệp sử dụng hơn 6 năm
- GitWonk: Công cụ tài liệu kỹ thuật mã nguồn mở được thiết kế và xây dựng với trọng tâm là trải nghiệm nhà phát triển
- Hanko: Công cụ xác thực và quản lý người dùng mã nguồn mở cho kỷ nguyên passkey, có thể tích hợp vào ứng dụng web và di động chỉ trong vài phút
- Infisical: Nền tảng mã nguồn mở mã hóa đầu cuối để quản lý an toàn secret và cấu hình trên toàn bộ nhóm, thiết bị và hạ tầng
- Novu: Hạ tầng thông báo mã nguồn mở cho nhà phát triển, cung cấp các component và API để quản lý mọi kênh liên lạc tại một nơi
- OpenBB: Dân chủ hóa nghiên cứu đầu tư thông qua hệ sinh thái tài chính mã nguồn mở, đồng thời cho phép thực hiện nghiên cứu đầu tư ở bất cứ đâu với OpenBB Terminal
- Sniffnet: Công cụ giám sát mạng giúp theo dõi lưu lượng Internet một cách dễ dàng
- Typebot: Cung cấp các khối để tạo trải nghiệm trò chuyện độc đáo, có thể nhúng ở bất kỳ đâu trong ứng dụng để thu thập kết quả
- Webiny: CMS serverless cấp doanh nghiệp mã nguồn mở, nhấn mạnh quyền sở hữu dữ liệu, khả năng mở rộng và tùy biến
- Webstudio: Được chọn là giải pháp thay thế Webflow mã nguồn mở
1 bình luận
Ý kiến trên Hacker News
Xin chào, như nhiều người đã biết, tôi là người tạo ra htmx và có thể trả lời các câu hỏi liên quan
htmx đã tăng mạnh độ phổ biến nhờ video của fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) và loạt video của ThePrimeagen, một streamer Twitch nổi tiếng
Nếu là độc giả HN, có thể bạn sẽ thấy bộ sưu tập bài viết tôi viết về htmx và hypermedia nói chung tại https://htmx.org/essays cũng thú vị, và cuốn sách gần đây tôi cùng vài tác giả khác xuất bản về hypermedia, htmx và Hyperview — hypermedia cho di động — tại https://hypermedia.systems cũng đáng xem
Dĩ nhiên tôi là fan của htmx, nhưng tôi cho rằng cốt lõi sâu xa hơn là hypermedia. Đây là một khái niệm đáng khám phá ngay cả khi bạn không có kế hoạch dùng htmx trong công việc phát triển hằng ngày
Cũng có nhiều thư viện tuyệt vời theo hướng hypermedia, như Hotwire của 37signals hay https://unpoly.com, thư viện tôi thích nhất sau htmx
Nó giúp ích rất nhiều cho nhiều lập trình viên Django
Vài tháng trước khi làm tính năng thích bài viết, trước htmx tôi phải gọi máy chủ JSON API bằng jQuery rồi cập nhật số lượt thích, nhưng với HTMX thì cảm giác như chỉ dùng HTML bình thường cùng với logic Django
Đây là một trong những thứ tốt nhất tôi từng tìm thấy cho đến nay, và xử lý form cũng rất dễ. HTMX cải thiện đáng kể cả trải nghiệm người dùng lẫn trải nghiệm lập trình viên
Xét rằng ngay cả ở các dự án rất phổ biến, thường những người đóng góp hiện có vẫn đảm nhiệm phần lớn mã nguồn, đây là một tín hiệu tăng trưởng mạnh
https://devboard.gitsense.com/bigskysoftware/htmx
Nhân tiện, đây là công cụ do tôi tạo ra
Tôi xem qua trang web và các ví dụ thì thấy có vẻ trọng tâm là cách phản hồi HTTP từ máy chủ chứa đầy đủ markup, rồi dựa vào đó cập nhật trạng thái phía client, tức thiên về viết lại DOM
Tôi tò mò liệu htmx có nhượng bộ nào cho các trigger chỉ ở phía client hoặc nội dung được tạo phía client hay không
Ưu điểm của các framework client lấy JavaScript làm trung tâm hiện nay là có thể đẩy càng nhiều việc càng tốt sang trình duyệt, qua đó giảm mức dùng dữ liệu và CPU của máy chủ. Với ứng dụng ở quy mô web, điều này tạo ra khác biệt lớn
Tôi muốn biết HTMX có thể đáp ứng mục tiêu kỹ thuật này hay không, hay đây là một dự án có mục đích hoàn toàn khác. Tôi hiểu rằng các client như Facebook không theo hướng hypermedia, nhưng dù sao việc so sánh có lẽ khó tránh khỏi
Nó tự nhiên, có cảm giác tự ghi tài liệu, và được thiết kế tốt. Thực sự giống như một phần mở rộng tự nhiên của HTML
Với tôi, mảnh ghép duy nhất còn thiếu ở htmx là mô hình component, và với những ai đang tìm thứ như vậy thì có lẽ nó rất hợp với Astro[1]. Astro cho phép định nghĩa và dùng các component HTML mà không có gánh nặng runtime như Vue hay React
[1] http://astro.build
Htmx làm tôi nhớ đến Tailwind. Bởi vì nó tạo ra các tên và giá trị thuộc tính để một thư viện đọc vào lúc runtime
Không cần build frontend là một lợi thế rất lớn đối với phần lớn lập trình viên không muốn đụng đến npm và webpack, và cũng không cần phải làm vậy
Giới hạn về kích thước trang có vẻ tương đương một ứng dụng single-page nhỏ; nếu lớn quá thì có thể tách thành một ứng dụng single-page khác
Điều mà các lập trình viên React/Vue có lẽ sẽ đặc biệt tiếc là góc nhìn trong đó có một đối tượng duy nhất biểu diễn trạng thái toàn cục, rồi một hàm duy nhất được định nghĩa theo cấp bậc trong codebase component render nó thành UI
Tuy nhiên bản thân góc nhìn này cũng khá nặng nề, tạo ra nhiều khác biệt quan điểm và hao tổn cảm xúc, đồng thời kéo theo cả bước build frontend cùng những biến thể rối rắm của nó
Tôi vẫn chưa dùng, nhưng đã là một fan lớn
Tin tốt đấy
Trong 1 năm qua tôi đã dùng htmx và đạt được kết quả tốt cùng những trải nghiệm đáng giá; nó đặc biệt tuyệt vời khi render phía server bằng hiccup trong Clojure
Một khi đã hiểu htmx, bạn sẽ gần như ngạc nhiên vì nó đơn giản và linh hoạt đến mức nào. Khó tin là HTML đã không tiến hóa theo hướng hypermedia như thế này
Việc phát triển web lẽ ra nên tiến hóa theo cách này trở nên rất rõ ràng. Hy vọng một ngày nào đó những gì htmx đang làm bằng JavaScript sẽ được tích hợp nguyên bản vào HTML và client trình duyệt
Nếu bạn hiểu sai htmx chỉ như một nhánh phái sinh của Angular, hoặc chưa hiểu ý nghĩa của việc phát triển kiến trúc hypermedia, tôi rất khuyên bạn nên đọc các bài viết xuất sắc trên trang này. Khi đó bạn sẽ hiểu REST là gì và vì sao HATEOAS thực sự quan trọng: https://htmx.org/essays/
Cũng có một cuốn sách miễn phí: https://hypermedia.systems/
10~15 năm trước, thay vì mở rộng và làm phong phú hypermedia—ý tưởng mới mẻ và mạnh mẽ của web thời kỳ đầu—chúng ta đã đi vào một con đường sai lầm tốn kém khi cố xây dựng lại các client dày trên nền web bằng kiến trúc JSON API
Tôi vui vì htmx tồn tại và phù hợp với nhiều người, nhưng trong công việc của tôi, nó thường không phải lựa chọn tốt nhất. Và điều đó cũng không sao
Việc web có thể phát triển theo nhiều cách khác nhau là điều tuyệt vời, và không cần phải xem web như thể nó nhất thiết phải tiến hóa theo một hướng nào đó
Sai lầm lớn nhất của phát triển web trong khoảng 10 năm qua là ý nghĩ rằng phải có một đáp án đúng duy nhất
Dù bạn đang làm Gmail tiếp theo hay một blog tĩnh, cargo cult của ngành đều nói rằng phải làm theo cùng một cách, nhưng xét theo lẽ thường thì không phải vậy
Nó sẽ đủ cho hơn 98% web. Với 1,9% còn lại, có thể dùng một thư viện JavaScript nhỏ
Chỉ 0,1% còn lại mới là web app JavaScript thuần
Trông có vẻ cùng một ý tưởng: rải thêm một ít thuộc tính vào HTML để làm cho các trường hợp đơn giản trở nên động
Angular 1, Vue và nhiều framework khác cũng bắt đầu như vậy, rồi sau khi đạt được một mức độ phổ biến nhất định, chúng lớn lên thành các framework ứng dụng một trang hoàn chỉnh do nhu cầu thực tế với những trường hợp khó hơn
Nếu phải chọn một framework “kiểu Angular 1”, tôi sẽ chọn cái nào tài liệu hóa rõ ràng các ranh giới và cung cấp một con đường rõ ràng để dùng một framework ứng dụng một trang trưởng thành khi cần vượt qua các ranh giới đó. Nếu ai biết framework như vậy thì xin chia sẻ
Tôi là fan của HTMX “từ trước khi nó trở nên ngầu”
Tôi rất vui trước sự chú ý và thành công gần đây, và cũng khá thích những lời chế giễu pha trò cùng phản ứng ngược từ phía frontend, những người tin rằng web được phát minh vào năm 2013 và chính họ đã xây nên thành phố đó
Tôi đã có thiên kiến từ thời Backbone.js; khi đó tôi cũng hiểu một phần nỗi đau, nhưng vẫn hoài nghi ở mức nào đó
Sau đó React xuất hiện, và khi những người trẻ đầy năng lượng bắt đầu biến các website cực kỳ đơn giản chỉ 5 trang thành cỗ máy Rube Goldberg của frontend framework, tôi rút chip công nghệ của mình ra đổi lấy tiền mặt và không đụng vào những thứ đó nữa
Chi tiết triển khai khá khác, nhưng ý tưởng về ứng dụng dựa trên hypermedia là cốt lõi của mọi thứ chúng tôi làm
Đáng tiếc là về lâu dài nó không chinh phục được lòng người, và phát triển theo blog dẫn dắt, tức cargo cult, đã thay thế nỗ lực của chúng tôi
Giờ thấy HTMX có vẻ đang ngày càng phổ biến, tôi cảm thấy như được đền đáp phần nào. Thật tốt khi thấy không chỉ có chúng tôi nghĩ theo những khái niệm này
Tất nhiên, nếu khái niệm đó mạnh thì cũng có thể nghĩa là phần thực thi của tôi còn thiếu sót, nên có lẽ tôi không nên vui quá
Tôi cũng đã nghe chuyện một ban nhạc bán guitar và mua turntable
Tôi đã nghe chuyện người ta viết lại HTTP endpoint để trả về JSON, và đó là REST
Tôi cũng đã nghe chuyện ban nhạc bán turntable và mua guitar
Tôi đã nghe chuyện người ta viết lại HTTP endpoint để trả về các mảnh HTML theo template, và đó là HATEOAS
Tôi đang mất cảm giác, rồi lấy lại, rồi mất, rồi lấy lại
Chỉ là Backbone hơi lỏng lẻo, và trước khi Angular xuất hiện thì nó chưa thật sự mang dáng dấp doanh nghiệp
Dù sao, lý do dòng ứng dụng web kiểu này trở nên phổ biến quanh tôi là vì nó tách backend và frontend, và một backend duy nhất, thường là REST/JSON, có thể phục vụ riêng cho client mobile và web
Đó là lý do chúng tôi làm single-page app, nhưng giờ dường như điều đó lại bị quên mất
Trong thế giới của tôi, với các app nằm sau đăng nhập thì điều đó hợp lý. Nhưng “họ” lại muốn biến cả các site công khai trên internet như web shop thành single-page app
Điều đó cũng có thể hiểu được. Tôi từng làm vài website bằng Gatsby, điều hướng nhanh điên cuồng mà vẫn được công cụ tìm kiếm lập chỉ mục
Chỉ là trong một số trường hợp, mọi thứ ngày càng phức tạp hơn và còn có cả những thứ như React phía server. May là tôi không phải đụng tới nó
Mặt khác, tôi hy vọng htmx, và rộng hơn là hypermedia, được chấp nhận như một công cụ. Nó hữu ích, nhưng rốt cuộc cũng chỉ là công cụ
Tôi cũng mong những người frontend đã lâu không suy nghĩ sâu về hypermedia sẽ đón nhận nó theo cách đó
Tôi không xem hai cách tiếp cận là loại trừ lẫn nhau, và đồng ý với khái niệm Transitional web application của Rich Harris, tức cách pha trộn hai cách tiếp cận
Chỉ là tôi vạch ranh giới từ bỏ hypermedia để chuyển sang cách tiếp cận tinh vi hơn ở phía client ở một vị trí khác với anh ấy
Tôi thì chắc chắn nghĩ vậy
Tôi bắt đầu với Perl vào năm 1996, rồi đã trải qua gần như mọi làn sóng từ PHP, jQuery, Drupal, Backbone, Node, Angular, ClojureScript, React, GraphQL cho tới NextJS
Htmx có cảm giác như một nhánh rẽ ra khỏi dòng chảy đó, và đáng để suy nghĩ
Htmx đặt ra một câu hỏi hay: “Độ phức tạp trong công việc của bạn về bản chất nằm ở server hay ở client?”
Với phần lớn website, độ phức tạp về bản chất nằm ở server. Đa số chúng ta không đang làm Figma hay Google Sheets. Nhiều website, dù có nhiều tương tác, cũng chỉ là ứng dụng CRUD với giao diện đẹp mắt
Các framework như NextJS cố sửa vấn đề client quá phức tạp bằng cách đưa React lên server, nhưng nhiều khi lại làm tăng độ phức tạp thay vì giảm nó
Vậy chẳng phải nên bỏ React ra khỏi stack sao? Nếu là client phức tạp thì có thể bỏ qua DOM và JavaScript, dùng canvas cùng WebAssembly đã biên dịch. Nếu là server phức tạp thì dùng các cập nhật DOM chi tiết do server điều phối
Vấn đề tôi thấy ở cách tiếp cận này là dù độ phức tạp của hầu hết website nằm ở server, gần như luôn có một vài tác vụ có độ phức tạp cao bắt buộc phải nằm ở client. Chẳng hạn chỉnh sửa ảnh, sắp xếp/lọc/tính toán theo thời gian thực, các thao tác kéo/thả và cử chỉ chạm
Cần một cách tiếp cận hybrid. Chỉ tương thích thôi là chưa đủ. Có thể dùng htmx và React trên cùng một trang web, nhưng phải cô lập chúng với nhau. Thứ tôi muốn không phải là cô lập mà là tích hợp nền tảng
Framework lý tưởng phải hỗ trợ các cập nhật chi tiết mang tính reactive cho DOM, đồng thời tích hợp chặt chẽ với WebAssembly đã biên dịch phụ trách các tác vụ client phức tạp
Tôi muốn viết toàn bộ code bằng một ngôn ngữ mạnh, không phải JavaScript. Debugger phải xử lý được cả server lẫn client, và ranh giới giữa hai bên phải biến mất. Đó phải là phát triển full-stack thực sự, tức một ứng dụng single-stack
Clojure + ClojureScript có vẻ gần với ứng dụng single-stack, nhưng chỉ ở bề mặt
Nếu Common Lisp có một killer framework, có lẽ ứng dụng single-stack sẽ rất hợp
Cách tiếp cận hybrid chính là cách tiếp cận islands mà Astro chủ trương: https://docs.astro.build/en/concepts/islands/
Cách này rất hợp với htmx và những công cụ cùng hệ, và trong các dự án htmx chúng tôi đang dùng kèm JavaScript vanilla đơn giản cho những phần cần tương tác
Với dự án nhỏ/vừa và nhóm nhỏ, như vậy có thể là đủ. Việc mở developer tools, trỏ vào một phần của trang, rồi chỉ cần nhìn HTML và một mẩu JS nhỏ là hiểu được toàn bộ phần đó thực sự rất mới mẻ
Dù ở server hay client, bạn đều code theo cùng một cách bằng C#. Khi tải trang đầu tiên, mọi thứ được render phía server; sau đó WebAssembly dần tiếp quản và bắt đầu tải code C# xuống client để các tương tác UI không cần dữ liệu server diễn ra nhanh hơn
Hoạt động tốt, nhưng thách thức hiện tại là giảm kích thước file WebAssembly. Hiện chúng ở mức vài MB
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
Chúc mừng. Làm một dự án nhỏ bằng Htmx khá thú vị, nhưng cuối cùng tôi dùng openlayers rất nhiều nên đã chọn thứ khác
Thư viện bản đồ nổi tiếng là nặng về JavaScript phía client, và với công việc đó Svelte là công cụ phù hợp hơn
Tôi dự định sẽ dùng lại trong các dự án Golang sắp tới và sẽ tiếp tục theo dõi sự phát triển của nó
Nếu ứng dụng cần frontend đơn giản hoặc có độ phức tạp trung bình, đặc biệt là nếu bạn đã dùng template fragments[0], tôi rất khuyên nên thử HTMX. Ngay cả với người đến từ thế giới JavaScript, làm việc với nó cũng khá vui
Và người vận hành tài khoản Twitter[1] thực sự rất hài hước
[0] https://htmx.org/essays/template-fragments/
[1] https://twitter.com/htmx_org
Rất khó để xem htmx như một công cụ nghiêm túc để xây dựng web app hay website hiện đại. Tôi cảm thấy nó khiến việc tạo ra những tính năng mà người dùng đã bắt đầu kỳ vọng trở nên bất khả thi
Ví dụ như tìm kiếm theo facet: lọc ngày theo trước·trong khoảng·sau, nhưng chỉ hiển thị bộ lọc khi người dùng muốn; hay chức năng đổi màn hình kết quả sang một view vẽ trên canvas như cột khác, bản đồ, biểu đồ, v.v.
Có lẽ có thể làm một phần bằng htmx, nhưng đến một lúc nào đó rốt cuộc bạn sẽ cần JSON
Angular cũng làm được những việc này, và nếu dùng thứ như SolidJS thì thực tế còn có thể làm khá vui
JSON API có thể tái sử dụng ở các app khác, còn htmx thì giống như ai đó phát minh lại Thymeleaf
Tôi cũng từng nghĩ như vậy, nhưng video trình bày cụ thể cách họ triển khai tìm kiếm theo facet bằng htmx
Phần thứ hai thì có lẽ bạn sẽ viết JavaScript trực tiếp hoặc xử lý bằng hyperscript
Phải thực sự xây dựng và dùng nghiêm túc mới biết đó có phải là cách tốt hay không, nhưng chắc chắn tôi cũng nghĩ ra vài kịch bản rất phù hợp
Nhận xét về JSON API là xác đáng. Nếu cần API công khai thì nên đưa vào quyết định. Nhưng không phải dự án nào cũng có ràng buộc như vậy
Smartphone cũng chẳng gặp vấn đề gì khi tìm kiếm trong bảng một nghìn dòng
Trong những trường hợp như vậy, tôi sẽ dùng htmx để đưa cho người dùng một phạm vi dữ liệu rộng, rồi cho phép JS lọc chi tiết hơn theo thời gian thực sau đó
Nếu muốn tìm kiếm cả dữ liệu ban đầu không hiển thị, có thể gửi kèm chúng với một CSS class ẩn, rồi khi được tìm thấy thì gỡ class đó ra
htmx, cũng như các công nghệ khác, rất hợp với một tập hợp vấn đề nhất định. Miễn là đừng ép nó làm những trò mà nó không giỏi thì ổn
Những thứ này phức tạp đến mức cần một mức độ scripting toàn diện nào đó, và bản thân tôi không phản đối điều đó
https://htmx.org/essays/hypermedia-friendly-scripting/
Nhờ những ngã rẽ trong sự nghiệp mà tôi gần như đã bỏ qua các cuộc chiến framework JavaScript frontend, nên tôi rất vui khi thấy HTML cũ kỹ bình thường quay trở lại với sức mạnh được tăng cường
Xét về suy giảm tiệm tiến thì đây là một bước lùi
Tôi nghĩ cần có những trường hợp ấn tượng được làm bằng htmx. Sẽ rất hay nếu có các ví dụ “made with htmx” mở ra một kiểu trải nghiệm web mới
Mọi người đã định kiến htmx là dành cho các use case đơn giản, chưa tới mức phải rút “vũ khí nghiêm túc” ra dùng
Điều đó có phần đúng, nhưng cũng hạn chế. Cách tiếp cận quay lại server liên quan đến htmx là một phạm trù riêng mà vì nhiều lý do đã không được khám phá sớm hơn
HTMX là hồi sinh những phạm trù app cũ theo cách không phụ thuộc backend
Nó không làm điều gì mới, hay đủ để biện minh cho một “phạm trù app mới”
Đó là cách xây dựng hypermedia, tức các site lấy nội dung làm trung tâm, như catalog mua sắm, diễn đàn, frontend quản trị, blog
Nó tương tự jquery/liveview/turbolinks, nhưng không phụ thuộc backend và không cần duy trì nhiều, hoặc thậm chí bất kỳ, logic JS frontend nào
Khi cần tương tác nặng như Google Docs hay Figma, lợi ích mà htmx mang lại giảm đi đáng kể
https://htmx.org/essays/a-real-world-react-to-htmx-port/
Một frontend thương mại điện tử viết bằng HTMX và Hyperscript
https://www.makaron.cz/
Có thể làm frontend TodoMVC bằng HTMX, nhưng backend thì dùng gì? Go, C#, Rust và một vài lựa chọn khác có vẻ tự nhiên, nhưng lúc nào cũng tùy tình huống
Tôi nhắc đến C# vì ASP.Net MVC + Razor có vẻ khớp rất gọn với paradigm HTMX
Tôi không liên quan gì đến họ, nhưng nó được làm bằng htmx cùng một ít JS cho các chức năng phức tạp hơn
Xét việc htmx có mục tiêu rõ ràng là mở rộng cách tiếp cận tốt đẹp ngày xưa, tôi không chắc nó có thể mang lại “một kiểu trải nghiệm web mới” hay không
Ban đầu htmx trông có vẻ hay, nhưng nếu bạn muốn làm một thứ đáng để dùng JavaScript thông thường, dù là vanilla hay framework, chẳng hạn như nút dropdown, thì cuối cùng bạn sẽ phải xem xét hyperscript
Rồi khi xem các ví dụ, bạn lại không thích việc trong code có những thứ trông như câu văn, nên chuyển sang thứ khác
Có thể cần thử dùng htmx không có hyperscript, hoặc có thể cần cho hyperscript thêm thời gian
Nhưng nếu dự kiến phải bảo trì trong vài năm thì nó quá xa lạ, và tôi không muốn bị trói vào đó nếu sau này không bao giờ dùng lại nữa
Phía htmx hoàn toàn không quan tâm bạn dùng công cụ tương tác phía client nào, nên đây là vấn đề tách biệt với việc htmx có hữu ích hay không
Cá nhân tôi, nếu muốn loại bỏ các công cụ build JS, v.v. thì tôi sẽ chọn htmx + Alpine.js
Khi quy mô lớn hơn và phức tạp hơn thì làm sao kham nổi?
Tôi từng hỗ trợ một ứng dụng dùng htmx và có hai vấn đề. Tôi tò mò liệu có ai có trải nghiệm tương tự không, liệu đó là vấn đề do dùng sai công nghệ, hay hiện có công việc nào đang được tiến hành để giải quyết không
Thứ nhất, cần rất nhiều middleware tùy chỉnh trong controller để quyết định endpoint nên trả về HTML của toàn bộ trang hay chỉ trả về mảnh mà htmx cần
Nhìn từ phía htmx thì có vẻ đơn giản, nhưng có lẽ đây là phần mà mọi dự án dùng htmx đều phải tự làm lại
Thứ hai, cần quản lý sổ sách quanh
hx-trigger. Khi UI trở nên phức tạp, nhiều phần tử phải phản ứng với các thay đổi bên ngoàiThay vì đọc một trạng thái nào đó rồi kỳ vọng framework lên lịch cập nhật, chúng tôi phải tự quản lý danh sách các event cần phản ứng
Có ai cũng cảm thấy tương tự không?