Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's make the worst Htmx

zserge.com

Post reply on HN
Print view View original

61–70 of 85 posts

Re: Let's make the worst Htmx

#61

Post by igor47 »

cpburns2009 wrote: post #46

I really want to try htmx but it specifically prohibits my most common usecases: 1) I want to take a JSON response, create HTML from it, and replace the target element with the generated HTML. 2) Similar to the above, take a JSON response, perform some action, and do nothing to the source element. Is there a plugin to add this? I want to move away from jQuery, and having a small framework to wire up hooks would be us…

Why are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend, which can then return html to your frontend

(1) the exception is I think in one place concerned a flow for uploading images, where client side requests a signed url, uploads to that url, then registers completion. Getting the signed url back is JSON meant for the uploader

Re: Let's make the worst Htmx

#62

Post by stevoski »

Part of the beauty of htmx is how simple it is to recreate. As this post shows, the fundamental concepts of htmx really are straightforward.

Of course, there are all sorts of edge cases and minor features to add to make it complete.

Re: Let's make the worst Htmx

#63

Post by wasting_time »

igor47 wrote: post #61
cpburns2009 wrote: post #46

I really want to try htmx but it specifically prohibits my most common usecases: 1) I want to take a JSON response, create HTML from it, and replace the target element with the generated HTML. 2) Similar to the above, take a JSON response, perform some action, and do nothing to the source element. Is there a plugin to add this? I want to move away from jQuery, and having a small framework to wire up hooks would be us…

Why are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend,…

I made a UI with htmx, it works great.

But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app.

Neither option is great.

Re: Let's make the worst Htmx

#64

Post by igor47 »

wasting_time wrote: post #63
igor47 wrote: post #61

Earlier quoted context omitted.

Why are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend,…

I made a UI with htmx, it works great. But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app. Neither option is great.

I do get kind of annoyed that htmx submits forms using form url encoding. It's non trivial to validate, see https://igor.moomers.org/posts/zod-schemas-htmx

As a result for POST requests you have to have htmx routes that accept urlencode and API routes that accept JSON, and JSON is far superior. But for outputs I actually think separating your UI and API is helpful. The code reuse is not worth the entanglement of concerns.

Re: Let's make the worst Htmx

#65

Post by Aeolos »

wasting_time wrote: post #63
igor47 wrote: post #61

Earlier quoted context omitted.

Why are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend,…

I made a UI with htmx, it works great. But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app. Neither option is great.

Fat services, thin routes. Try moving your business logic to a library and consume it from both your UI and API routes. That minimizes duplication and decouples your public API resolvers (with backwards compatibility requirements etc) from your private UI resolvers (which you want to evolve rapidly to optimize your UIX).

That's what we did and it works pretty well in practice.

Re: Let's make the worst Htmx

#66

Post by yawaramin »

cyanregiment wrote: post #43

HTMX is amazing on paper, not in real life. It loses things like scroll position and text highlighting on re-render - it’s not high performance like React. This is for server sided or static web pages not building rich UI. There is no robust state management or DOM performance improvements you get with React with larger components. HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high per…

Htmx is not meant for these use cases. We’re building great interactive webapps with htmx using the web platform’s built-in capabilities. If you need exact scroll position and text highlighting you can get that with some other framework. Htmx works well with things that are in its own niche.

Re: Let's make the worst Htmx

#68

Post by yawaramin »

wasting_time wrote: post #63
igor47 wrote: post #61

Earlier quoted context omitted.

Why are you so wedded to JSON responses? HTMX is meant to be used to render html; my big HTMX app basically never(1) renders JSON, so much so that I have a standing instruction to coding agents that if they're rendering JSON they're probably doing something wrong. If you're attached to JSON because you're working with external API s you don't control, a good place to perform those kinds of actions is in your backend,…

I made a UI with htmx, it works great. But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app. Neither option is great.

Ok, for the sake of completeness–why do you want to add a JSON API to the program? Quite a lot depends on the reason.

Re: Let's make the worst Htmx

#69

Post by yawaramin »

cyanregiment wrote: post #51
vb-8448 wrote: post #50

Earlier quoted context omitted.

> HTMX team should build a game with it. Load some 3D in WebGL/WebGPU, showcase high performance UI. Why? Why you'd pick htmx (or even reactjs?!?) to build a game?

Because I would need to see a UI paradigm prove it can handle performance before considering using it for UI. react-three-fiber solves a lot of problems. React state is also perfectly in line with game loop architecture, r3f unifying the Three.js/React render loop is incredibly good for game dev. But even for SaaS or whatever, I need to know that it can handle complex states of the UI - HTMX can't. They are overselli…

> They are overselling it.

They quite literally have a a large essay on their site dedicated to discussing when to and when not to use it: https://htmx.org/essays/when-to-use-hypermedia/

Also, it’s not at all sold as a ‘competitor to React’, it’s sold as a simpler option for many apps where React is overkill. If you want to make a game with React, no one will argue for using htmx instead. The game will probably have a lot of perf issues though.

Re: Let's make the worst Htmx

#70

Post by wasting_time »

yawaramin wrote: post #68
wasting_time wrote: post #63

Earlier quoted context omitted.

I made a UI with htmx, it works great. But now I want to add a JSON API to the program: I could reuse the same routes (/create, etc), but require an application+json header; or add a full /api/ component essentially duplicating the logic from the main app. Neither option is great.

Ok, for the sake of completeness–why do you want to add a JSON API to the program? Quite a lot depends on the reason.

It's a service, and I want to add a CLI for humans and agents. Aeolos' reply makes a lot of sense, I can refactor the backend into a library and add thin UI and API routes on top of it.
Post reply on HN