Vì sao Gumroad không chọn htmx

 (htmx.org)
6 điểm bởi GN⁺ 2024-10-04 | 1 bình luận | Chia sẻ qua WhatsApp
  • Gumroad đã cân nhắc htmx cho dự án mới Helper với kỳ vọng có một frontend nhẹ, nhưng khi các yêu cầu UX phức tạp tăng lên, họ đã chuyển sang React/Next.js
  • htmx tỏ ra hứa hẹn cho các tương tác đơn giản, nhưng với các form có kiểm tra động và trường có điều kiện, logic phía server trở nên dài dòng, khiến luồng phát triển thiếu tự nhiên
  • Kéo-thả, cộng tác thời gian thực, quản lý trạng thái phức tạp và tạo form động trong workflow builder được triển khai trực tiếp hơn với hệ sinh thái React và mô hình component
  • Tài liệu xử lý sự cố và hỗ trợ từ công cụ AI phong phú hơn ở phía Next.js và React; htmx bất lợi về tốc độ phát triển do thiếu dữ liệu học từ mã nguồn mở
  • htmx có thể phù hợp với các ứng dụng server-rendering hiện có hoặc mô hình tương tác đơn giản, nhưng với giao diện nhiều trạng thái như Helper, React và Next.js phù hợp hơn

Bối cảnh Gumroad cân nhắc htmx cho Helper

  • Khi bắt đầu dự án mới Helper, Gumroad đã cân nhắc htmx như một ứng viên frontend
  • Kỳ vọng ban đầu xuất phát từ kinh nghiệm trước đây rằng React nặng hơn mức cần thiết, và họ cho rằng htmx có thể là cách thêm các tương tác đơn giản một cách nhẹ nhàng
  • Trong nội bộ nhóm, cũng có đánh giá rằng htmx giống một meme châm biếm hệ sinh thái JavaScript đã trở nên phức tạp
    • Tương tự như Tailwind trông giống một cú pháp khác của CSS inline, cũng có góc nhìn cho rằng htmx gần với một cú pháp khác của JavaScript inline
  • Tailwind đã có chỗ đứng trong hệ công cụ của Gumroad, nhưng htmx không mở rộng được theo mục tiêu của Helper và không dẫn đến trải nghiệm người dùng tốt nhất cho khách hàng

Những điểm React/Next.js tự nhiên hơn

  • Trải nghiệm phát triển và xử lý form

    • Dù vẫn có thể triển khai đúng bằng htmx, Gumroad cảm thấy quá trình làm cho tính năng hoạt động trong Next.js trực quan hơn
    • Với các form phức tạp có kiểm tra động và trường có điều kiện, xử lý phía client của React đơn giản hơn, còn với htmx thì logic phía server dài ra

  • UX và giới hạn tương tác

    • htmx có xu hướng đẩy ứng dụng theo cách Rails/CRUD, khiến trải nghiệm mặc định dễ trở nên bình thường hoặc phổ thông
    • Giao diện kéo-thả của workflow builder cần triển khai vòng trong htmx, và có cảm giác thô hơn so với trải nghiệm mượt mà có được từ các thư viện React

  • Công cụ AI và tốc độ xử lý sự cố

    • Các công cụ AI quen thuộc với Next.js hơn nhưng kém quen thuộc với htmx hơn; nguyên nhân được cho là do thiếu dữ liệu học từ mã nguồn mở
    • Tài liệu phía React/Next.js phong phú, nên khi gặp vấn đề, việc tìm giải pháp nhanh hơn

  • Độ phức tạp và khả năng mở rộng

    • Càng phức tạp, sự đơn giản của htmx càng giống một ràng buộc hơn là lợi thế
    • Khi bổ sung cộng tác thời gian thực và trực quan hóa dữ liệu phức tạp, cách tiếp cận xoay quanh server của htmx khiến việc quản lý trạng thái giữa nhiều component ngày càng khó

Khác biệt thể hiện theo từng tính năng của Helper

  • Kéo-thả: react-beautiful-dnd trong hệ sinh thái React cung cấp kéo-thả mượt mà và có tính tiếp cận với rất ít cấu hình
  • Quản lý trạng thái phức tạp: Các phương thức quản lý trạng thái của React như useState hoặc Redux trực tiếp hơn trong việc phản ánh thiết lập và logic điều kiện của từng bước workflow lên UI theo thời gian thực
  • Tạo form động: Việc tạo các form thiết lập khác nhau cho từng loại bước và thay đổi chúng theo dữ liệu người dùng nhập được xử lý trực quan hơn trong mô hình component của React
  • Cộng tác thời gian thực: Tính năng nhiều người dùng đồng thời chỉnh sửa workflow được triển khai tương đối trực tiếp bằng WebSockets và React; với htmx cần logic phía server phức tạp hơn và JavaScript tùy chỉnh
  • Tối ưu hiệu năng: Khi workflow trở nên lớn và phức tạp hơn, virtual DOM của React cùng các hook như useMemo, useCallback cho phép tối ưu việc render một cách tinh chỉnh

Hệ sinh thái và đánh giá cuối cùng

  • Hệ sinh thái React/Next.js lớn và trưởng thành, cung cấp giải pháp cho gần như mọi vấn đề Gumroad gặp phải
  • Với htmx, nhiều tình huống buộc phải thỏa hiệp về tính năng hoặc tự xây dựng lại; trong tích hợp dịch vụ và thư viện bên thứ ba, có khi có binding cho React nhưng không có phần tương ứng cho htmx
  • Sau khi chuyển sang React/Next.js, Gumroad đánh giá đây là lựa chọn phù hợp hơn để xây dựng UX phức tạp
    • Họ có thể tiến nhanh hơn, tạo trải nghiệm người dùng nhập vai hơn và tận dụng các công cụ, thư viện hiện có
    • Trải nghiệm người dùng ứng dụng cho nhóm khách hàng cốt lõi của Helper cũng được cải thiện đáng kể
  • Giới hạn của htmx không phải là không thể vượt qua, nhưng quá trình giải quyết đã đưa họ rời khỏi điểm mạnh của htmx và chuyển sang các giải pháp tự nhiên hơn trong môi trường xoay quanh JavaScript
  • htmx có thể là lựa chọn tốt cho các mô hình tương tác đơn giản hoặc dự án xây trên các ứng dụng server-rendering hiện có
  • Với giao diện phức tạp và nhiều trạng thái như Helper, React và Next.js phù hợp hơn; Gumroad cho rằng họ có thể tiếp tục đánh giá lại stack công nghệ theo nhu cầu thay đổi và công nghệ mới

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-10-04
Ý kiến trên Hacker News

  • Đây là điều tôi đã viết ở một thread khác: CEO của Gumroad nói trên Twitter rằng ông đã thử dùng htmx cho một dự án nhưng cuối cùng chọn NextJS
    Tôi đang tìm một bài chia sẻ tiêu cực có suy nghĩ chín chắn, đủ để đăng lên website của htmx, nên đã hỏi liệu ông có thể viết lại trải nghiệm đó thành bài hay không, và tôi rất cảm kích vì ông đã vui vẻ đồng ý

    • Tôi càng tôn trọng dự án hơn vì họ sẵn sàng tự chỉ ra những trường hợp htmx không phải lúc nào cũng là lựa chọn tốt nhất
      So với những dự án khác luôn khẳng định mình là lời giải tối ưu cho mọi thứ, điều đó thật mới mẻ
      Tôi đặc biệt tò mò về nhận xét liên quan đến drag and drop: liệu trong htmx việc này thực sự rất khó không, và nếu đúng thì có kế hoạch giải quyết hay không
    • CEO của Gumroad cũng nói bản thân Rails là nợ kỹ thuật, và khi được hỏi lý do thì chỉ trả lời rằng React tốt hơn nhiều
      Như thể Rails và React không thể dùng cùng nhau vậy
      Bản thân bài viết, thay vì là một trải nghiệm tiêu cực với htmx, lại giống như lập luận rằng ngay từ đầu việc thử nghiệm htmx đã có thể là một lựa chọn sai lầm khi drag and drop và cộng tác thời gian thực xuất hiện
      Tôi cũng không rõ ảnh chụp màn hình định cho thấy điều gì, nhưng dù vậy tôi vẫn nghĩ đây là bài phù hợp để đưa lên website htmx
    • Việc cho thấy những điểm mà htmx có thể kém phù hợp hơn các công cụ khác là điều đáng trân trọng
      Với tôi, htmx gần với một lựa chọn thay thế cho jQuery hơn là thay thế React
      htmx và jQuery thêm tính tương tác vào tài liệu, còn React thì muốn trở thành toàn bộ tài liệu
      Công cụ nên thay đổi tùy theo công việc
    • Sau khi đọc bài được liên kết và https://htmx.org/essays/htmx-sucks/, tôi quyết định sẽ không dùng htmx hay khuyên người khác dùng nó nữa
    • Thread còn lại là https://news.ycombinator.com/item?id=41727315

  • Đoạn “AI và hỗ trợ công cụ: cũng đáng lưu ý là các công cụ AI rất quen với Next.js nhưng không quen lắm với htmx” được viết khá điềm nhiên như một nhược điểm, nhưng đó là một dấu hiệu khá rùng mình cho tương lai của công cụ phát triển, thư viện, framework và ngôn ngữ
    Nếu dự đoán thì mô hình ngôn ngữ lớn sẽ còn khuếch đại thêm hiệu ứng người thắng lấy hết và lợi thế người đi trước vốn đã tồn tại, đồng thời càng khuyến khích dùng các công cụ mã nguồn mở nhờ có nhiều dữ liệu huấn luyện hơn và tốt hơn

    • Vấn đề AI và hỗ trợ công cụ thực ra chỉ là phần nối dài của vấn đề cộng đồng và hệ sinh thái
      Ngay cả trước thời mô hình ngôn ngữ lớn, React đã có lợi thế vì hầu hết câu hỏi đều đã có trên StackOverflow, và có thư viện trưởng thành cho gần như mọi mục đích
      Giờ chỉ là có thêm những người hỏi mô hình ngôn ngữ lớn những điều trước đây họ sẽ hỏi trên StackOverflow, và kết quả vẫn vậy
      Dùng thứ mà nhiều người khác đang dùng sẽ mang lại lợi thế
    • Việc mô hình ngôn ngữ lớn làm tăng hiệu ứng người thắng lấy hết và lợi thế người đi trước trong công cụ phát triển có lẽ đúng với những ai phụ thuộc vào mô hình ngôn ngữ lớn để viết code
      Nhưng tôi rất tin rằng đó không phải là một nước đi tốt cho chiến lược dài hạn của sự nghiệp kỹ sư phần mềm
    • Công cụ AI bị mắc kẹt ở một thời điểm nhất định, và ngay cả khi huấn luyện bằng tài liệu mới thì lượng thông tin chúng có thể học cũng có giới hạn
      Nghĩ kỹ thì có khi đây lại là điều tốt
      Ngành phần mềm dành quá nhiều thời gian để chạy theo công cụ mới nhất, tính năng ngôn ngữ mới nhất và framework mới nhất
      Có lẽ chậm lại một chút để hoàn thành công việc bằng những công cụ mình đã có sẽ tích cực hơn, thay vì cứ 6 tháng lại tạo ra một cái búa mới
    • Nếu một lập trình viên không thể làm việc nếu không có thứ gì đó viết code thay mình, thì tôi không hiểu tại sao lại tuyển họ ngay từ đầu
    • Tôi không quá lo về điểm này, và có thể nỗi lo của Gumroad đã bị phóng đại
      Chỉ từ bình luận thì không rõ đây có phải là trải nghiệm thực sự AI xử lý HTMX không tốt, hay chỉ là câu chuyện thiếu tài liệu hỗ trợ khác
      Mô hình ngôn ngữ lớn thường hoạt động rất tốt như một bộ dịch đa năng
      Chúng học các mẫu và khái niệm chung của framework phổ biến, rồi nếu biết phần nào cú pháp của framework nhỏ hơn, theo kinh nghiệm của tôi chúng vẫn có thể sinh ra code khá tốt cho các framework ngách
      Cũng giống như việc chúng có thể nói giọng cướp biển về những chủ đề mà cướp biển chưa từng nhắc tới trong dữ liệu huấn luyện

  • Đọc đoạn “khi xây dựng các form phức tạp với kiểm tra động và trường điều kiện, chúng tôi phải viết logic phía server phức tạp để xử lý những việc vốn chỉ là tác vụ đơn giản phía client trong React”, tôi lại nghĩ ngay đến meme Anakin Padme
    “Nhưng dù sao thì kiểm tra phía server vẫn được triển khai đúng không… đúng không?”

    • Nếu một form web còn phức tạp hơn cả biểu mẫu giấy, thì có lẽ chính form web đó nên được xem xét lại
      Những form mà trong React thì dễ nhưng trong htmx thì khó thực ra tôi không nghĩ ra được nhiều, trừ khi bạn đang cố nhồi trạng thái ứng dụng toàn cục kiểu React vào đó và muốn thư viện làm xong sẵn 90%
    • Việc kiểm tra ở server vẫn có
      Chỉ là không làm ở từng trang mà làm một lần khi submit

  • Trái với câu “chúng tôi nghĩ htmx có thể là một lời giải tốt để giữ frontend thật nhẹ”, có vẻ ngay khi từ bỏ frontend nhẹ thì htmx đã không còn phù hợp nữa
    Họ bắt đầu dùng thư viện bên thứ ba để render UI/UX phức tạp và quản lý trạng thái
    Ngoài ra, nói rằng “React làm X dễ hơn” cũng không phải là so sánh công bằng nếu X đó được thực hiện nhờ thư viện bên thứ ba
    Chỉ đơn giản là bạn không phải tự làm vì đã có người khác làm thay
    Tôi đồng cảm với phần lớn bài viết, nhưng nếu ngay từ đầu đã biết cần trạng thái và render phức tạp, thì tôi nghĩ htmx vốn dĩ không phải giải pháp tốt từ đầu

    • Tôi cũng nghĩ chính xác là như vậy
      Tôi thích htmx, nhưng bài này cho thấy tác giả khá thiếu hiểu biết kỹ thuật
      Đây không phải là những ưu nhược điểm mà chỉ cần biết sơ về nền tảng web và tài liệu trên htmx.org là sẽ nhận ra, mà giống kiểu thấy không khí hợp gu nên muốn thử HTMX hơn
    • Nó tạo thành một đối xứng khá hay với những người lẽ ra ngay từ đầu không nên dùng React nhưng rồi lại viết bài kiểu “đổi ứng dụng React sang htmx và mọi thứ tốt hơn hẳn”
    • Thế đối lập htmx với JavaScript khiến tôi nhớ đến việc so sánh bài test hành vi hướng phát triển của behave với test pytest
      Ngôn ngữ Gherkin trông rất ổn cho trường hợp đơn giản và về nguyên tắc cũng có thể mở rộng cho trường hợp phức tạp, nhưng càng phải quản lý nhiều tầng trừu tượng thì pytest thuần Python lại càng tiện hơn
    • Tôi cũng đã nghĩ y hệt vậy
      Phạm vi dự án hoàn toàn không hề “đơn giản”, và nếu là tôi thì đã chuyển sang React ngay lập tức
    • Chỉ cần nhìn mô tả tính năng mong muốn thôi cũng thấy JavaScript nặng là điều không thể tránh khỏi

  • Về ý “việc triển khai giao diện kéo-thả cho trình dựng workflow là một thách thức lớn với htmx, và cần những cách lách khá thô so với trải nghiệm mượt mà có thể có từ thư viện React”, thì HTMX phù hợp hơn khi chỉ làm đúng phần cần thiết của frontend bundle và không làm quá mức đó
    Chỉ cần gắn vào sự kiện htmx.onLoad, rồi trong phần nội dung đã tải tìm các đoạn markup có gắn thuộc tính, chẳng hạn columns, cards, tasks, v.v. để gắn vào là được
    Ví dụ, có thể bind sortable.js vào markup đã render và nối các sự kiện sortable với cập nhật trạng thái thông qua HTMX
    Khá đơn giản, và tài liệu cũng có đúng ví dụ này: https://htmx.org/docs/#3rd-party

    • Đang dùng HTMX cùng với các component UIKit
      Một website hiện đại, có trạng thái và động không hề là thứ không thể tương thích với HTMX

  • Đọc bài thì có cảm giác nhóm này quen với phát triển frontend hơn là phát triển backend
    Từ góc nhìn của một lập trình viên kiểu cũ, tôi thấy thấp thoáng một chút e ngại và hiểu lầm trong cách các lập trình viên frontend suy nghĩ
    Thành thật mà nói, để hiểu cách này vận hành chỉ cần điều chỉnh tư duy một chút, nhưng tôi cũng hiểu rằng nhiều người chưa từng thấy cách tiếp cận client/server thông thường trong suốt sự nghiệp của họ
    Dù vậy, cũng không thể xem nhẹ giá trị của các component React có sẵn và lợi thế là rất dễ tìm tài liệu hay trợ giúp

    • Tôi còn cho rằng việc UX designer cũng suy nghĩ theo kiểu React là rào cản lớn nhất với việc áp dụng htmx
      Cả một thế hệ designer đã thiết kế mobile và web gần như giống nhau, rồi đẩy độ phức tạp triển khai sang cho lập trình viên
      Nhưng web nên khác mobile nếu có thể, và cũng hoàn toàn có thể khác
      Bài viết nói thiết kế quá “generic”, kiểu như một ứng dụng CRUD, nhưng điều đó thực sự có tệ không?
      Chúng ta có một thành tựu tuyệt vời là mô hình tài liệu được chấp nhận rộng rãi, cho phép tạo ra trải nghiệm người dùng dễ đoán trên mọi website, vậy mà ta chỉ nhìn nó như thứ “nhàm chán”
      Như thể bản thân sự nhàm chán là một vấn đề mang tính bản chất
      Tôi hiểu áp lực thị trường đòi hỏi những trải nghiệm khác biệt, đậm chất thương hiệu, mang cảm giác như ứng dụng mobile, nhưng cũng khiến tôi tự hỏi sẽ thế nào nếu các designer có thể suy nghĩ theo WWW nhiều như theo React

  • Tôi thích việc HTMX đăng những bài như thế này và các bài tương tự ngay trên website của mình
    Có vẻ như có khá nhiều lý do chính đáng khiến chỉ dùng HTMX là không phù hợp
    Tôi không phải chuyên gia frontend, nhưng có vài suy nghĩ
    Thứ nhất, chẳng phải dù sao cũng phải làm kiểm tra form ở backend sao?
    Tôi thắc mắc vì sao việc để hệ thống backend chuyển kết quả đó cho frontend lại khó đến vậy
    Trong nhiều trường hợp có lý do rất chính đáng để kiểm tra form ở cả frontend lẫn backend, nên lúc đó chỉ HTMX thôi có thể là chưa đủ, nhưng cách diễn đạt vấn đề này hơi gây bối rối
    Thứ hai, nếu chỉ dùng HTMX thì ứng dụng có thể bị đẩy theo hướng này ở một mức độ nào đó; trong vài trường hợp đó là điều tốt, nhưng có vẻ họ kết luận rằng khách hàng của họ cần một cách khác
    Thứ ba, tôi muốn biết thêm họ đã dùng công cụ AI như thế nào mà sự phụ thuộc vào công cụ AI lại trở thành vấn đề lớn đến vậy
    Khi các công cụ phát triển bằng AI ngày càng quan trọng, cũng là một câu hỏi thú vị liệu ngưỡng để một framework hay ngôn ngữ lập trình mới được chấp nhận có trở nên quá cao chỉ vì cần đủ công cụ và tích hợp hay không
    Thứ tư, đúng như lời phàn nàn quen thuộc về HTMX, có những dự án đòi hỏi nhiều hơn những gì HTMX cung cấp
    Thứ năm, một trong những lý do tôi thích Django và Python cũng là vì cộng đồng sâu rộng, khả năng tích hợp và hệ sinh thái addon
    Một thứ như https://unpoly.com/ có ý tưởng tương tự nhưng nhiều tính năng hơn HTMX có lẽ đã phù hợp với họ hơn

  • Về câu “quy trình phát triển với Next.js tạo cảm giác tự nhiên”, tôi không hiểu phần nào trong cú pháp ReactJS này là tự nhiên
    Có thể là quen thuộc, nhưng không tự nhiên
    useEffect(() => { const timer = setInterval(() => { setCount((prevCount) => prevCount + 1); }, 1000); return () => clearInterval(timer); }, []);

    • Theo tôi biết thì HTMX không có một lời giải thanh lịch cho timer và interval
      Cuối cùng vẫn sẽ phải nối bằng JavaScript một cách khá gượng gạo
    • Ví dụ code này còn là dạng khá dễ dãi
      Nếu muốn một custom hook có timeout biến thiên thì mọi thứ có thể phức tạp hơn nhiều
      Dan thậm chí còn phải viết một bài dài về chủ đề này: https://overreacted.io/making-setinterval-declarative-with-r...
    • Tôi tò mò không biết đoạn code nào sẽ trông tự nhiên trong trường hợp sử dụng này
      Có thể viết thử không?

  • Việc htmx.org host bài này rất đáng khen

    • Tôi thật sự thấy có giá trị khi một dịch vụ hay công cụ không chỉ giải thích vì sao nên dùng, mà còn cả vì sao không nên dùng
    • Việc đăng một bài như vậy là một thái độ rất khiêm tốn và trung thực
      Cuối cùng, nếu ai đó cầm htmx lên dùng rồi tức giận vì nó không đáp ứng được nhu cầu của mình, thì giờ đã có sẵn tài liệu để chỉ vào
    • Nó được link dưới mục “On The Other Hand…” tại https://htmx.org/essays/
    • Ban đầu tôi hơi nghĩ đây sẽ là một bài rant hoặc mỉa mai, nhưng hóa ra lại là một bài hay với nhiều điểm tốt
      Tôi đã dùng htmx trong vài dự án của mình và thấy nó khá ổn
      Những bài như thế này lại càng khiến tôi tin tưởng hơn khi dùng htmx, vì chúng hiếm hoi cho thấy rõ nơi htmx làm tốt và nơi nó còn thiếu

  • Điểm thứ ba nghe đáng sợ
    Nó khiến tôi hình dung ra một thế giới nơi các công ty trả tiền để framework của họ bị lấy mẫu quá mức trong tập huấn luyện mô hình, rồi bán hợp đồng dựa trên điều đó
    Tương tự như việc tối ưu hóa công cụ tìm kiếm được baked in ngay trong các công cụ phát triển vậy