Live data from Hacker News

Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

misago-project.org

91–100 of 224 posts

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#91
I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right.

The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form with some large select lists as well as the response of results became noticeable laggy when there was more than a half dozen results.

I ended up switching to Alpine Ajax (https://alpine-ajax.js.org/) and pulled the form out of the response and just used a local x-data on it to track the state. This greatly reduced the HTML I needed to send back to just the list of results. I did make the form a bit more complicated but the experience felt a lot snappier. Both versions just synced the form state from the URL and kept the initial render as full HTML from the server.

I found that Alpine + Alpine Ajax was SMALLER than HTMX 4 even though (in my opinion) it offers a lot more features in a more approachable and intuitive way if you need to do interactivity and don’t want to trigger a request just to toggle some classes or attributes. Of course you can use both together (I started down that road) but you are mixing worlds and making the bundle size bigger at the same time.

I still like HTMX and will probably use it again. I just found that with an interactive experience like a product listing page, where the HTML response was quite large/expensive to fetch, it wasn’t the best choice for that.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#92

Earlier quoted context omitted.

That’s basically a massive hack. Every real world app will need enough js that htmx will require you to put js on front end and you’ll need to hack it together. Just like we did php+js 15 years ago.

What I've found in practice is that HTMX is extensible enough that I can write a small amount of javascript to "put a funny plug on the end of HTMX" to talk to say Leafletjs if I'm drawing maps, and want things dynamically updated. It works quite well, and saves me an awful lot of tedious mucking about with other stuff.

For what it's worth, Claude Code is really good with HTMX and with adding that glue logic if needed.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#93
post #8
post #5

Great, now you can't offload your FE to a CDN. But on serious note, htmx is basically a solution in the search of a problem. It is the new hype. Or rather, a solution that overlooks 2 decades of learnings. Yes, for a small set of projects htmx is okay, but even then, where htmx is ideal, static is king, and once static is not good enough, htmx sooner or later starts to feel like the XAML and BPEL soap. The fundamenta…

This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach? Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is? The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproj…

The creators of HTMX are combative, dismissive, and short-sighted. Keep them far away from any spec discussions.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#94
post #71

I think HTMX is a great fit for forum software. Forum websites mostly deliver non-interactive content in the form of text and maybe some audio, video, or image content. All of this can be represented as HTML and CSS. With HTMX you can do partial rendering and live updates via server-sent events. This gets you most of the way to the "client side" feel where things load dynamically based on user actions. The only prope…

> Forum websites mostly deliver non-interactive content I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things. Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other peop…

Well I also do not really know the legitimate use case for infinite scroll (other than trying to push gambling/slot-machine tricks onto your userbase).

I get lazy-loading for pages that contain a ton of media of which the user will likely only see a fraction. But some people seem to think infinite scroll is a good idea with text based content as well..

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#95

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…

have a look at https://segor.de/ - it just downloads 2MB of product listing data (pre-dating JSON!) and then does all filtering client-side

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#96

I actually tried to use HTMX on a site recently. I used the 4.0 beta. The site needed an interactive filterable product-listing-page-type experience to list out all their vendors. Form filters on the left and the list of results "cards" on the right. The problem I had was that the entire experience became really slow when I had it all working together as one "response". Sending back all that HTML for an entire form w…

You swapped out HTMX because you couldn’t figure out how to load a list of items gradually instead of all at once??

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#97
post #67
post #58

Earlier quoted context omitted.

I’m not sure I follow. SPA’s tend to require more network round trips, sometimes significantly more based on the architecture.

It’s in the name: an MPA requires a page roundtrip for every navigation, while SPA requires a single page roundtrip. Any subsequent requests are part of the application itself and can be handled without disrupting UX.

An SPA still requires roundtrips, just not to load the DOM root. Most of them do more than one roundtrip per navigation, making them worse than MPA. They also break loading screens.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#98
post #71

Earlier quoted context omitted.

> Forum websites mostly deliver non-interactive content I'd say that "Endless Scroll" is a good example of something that is... well maybe not interactive but still breaks the "just an HTML document" page metaphor that plays nice with such things. Now, personally I find the UI compromises it takes to make endless scrolling happen are abhorrent (like not being able to ctrl-F or export the page content). But other peop…

Infinite scroll with htmx: https://htmx.org/examples/infinite-scroll/

It’s funny how hilariously simple that is and the parent commenter making it sound like you need a full JS framework for that instead.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#99

I basically use HTMX for all my Web Apps, including PWA(s) that run as ~near native apps on iOS/Android. It's great! I aso pair this with DaisyUI+TailwindCSS. YOu really can't go wrong, there is something quite pleasant about writing your web apps in ordinary HTML with partials and the extensions that HTMX adds to the browser for SPA-like interactivity.

How does the PWA work offline with HTMX? The “hit the server for fresh markup fragments” approach seems like it has to be abandoned here, however simplifying it is for online apps.

It seems like the wrong tool for the job to me, but I was curious and thought about it a little:

After initial page load, a service worker could intercept all the HTMX app's AJAX requests, but it could only work with what's already cached. Using a lot of tooling like workbox the developer could pre-cache the entire app. (Would that mean no dynamic responses?)

Alternatively, implement the entire HTMX app in JS, build the app once for the NodeJS/Deno backend and once for the front-end. After page load, the frontend could take over.

Or something like that. It's a bit convoluted as PWA solutions often are.

Re: Removing React.js from the codebase and adapting Htmx for UI interactivity (2023)

#100
post #98

Earlier quoted context omitted.

Infinite scroll with htmx: https://htmx.org/examples/infinite-scroll/

It’s funny how hilariously simple that is and the parent commenter making it sound like you need a full JS framework for that instead.

I mean I'm not a front-end guy I was genuinely curious how well HTMX handles this kind of case.
Post reply on HN