Live data from Hacker News

Please just try HTMX

pleasejusttryhtmx.com

61–70 of 530 posts

Re: Please just try HTMX

#61
> "I'm not a fucking saint"

You're not a fucking person, this is LLM output.

It starts with the overdone sweary thing then mentions it's overdone and says it's not gonna do it, and it's almost enough to make me think the article is going to offer someone's point of view. But once again the LLM has erased any point of view the author may have had going in (or prevented them from developing it) and replaced it with a mediocre infodump.

I think this is the 5th slop I've seen atop HN in 24 hours.

> This site made by me, with tongue firmly in cheek.

Well, the LLM ruined it, and you didn't even tell us it participated.

Re: Please just try HTMX

#62
post #22

Earlier quoted context omitted.

> why bother learning two paradigms Objection. Your React is ultimately turning into HTML so you DO have to learn HTML + CSS. You just have an abstraction over it.

That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it. Yet I know roughly what it is, but I couldn't begin to actually write the stuff myself. Good abstractions mean you don't have to worry about the layer below. Now of course it's not really the case that React holds up to being a good abstraction, especially when it comes to CSS and st…

> That's like saying my C# is getting turned into CLR bytecode, so I do have to learn CLR bytecode because I have an abstraction over it.

That's not a valid analogy, 99.99% of C# developers never see or touch CLR bytecode, where every React developer is still working with HTML+CSS.

Re: Please just try HTMX

#63
post #6

Man I did try htmx, and I was hopeful, right until I saw how it polluted my codebase. I can't say I have the answers, but writing a pure Go app, I'm currently using one giant css file, custom styling and inline html. And now I'm at the breaking point. So I'm planning to move to tailwind and Go templates, but honestly, i was hopeful for htmx, so I need to properly see the usecase. Which i don't know is this. It remind…

> polluted my codebase I'd love to hear more about that.

Well listen, we have two modes of operation. It's either html/js/css in the classic sense, or Go templating with some tailwind and JQuery (or whatever the kids are calling it these days). In the case of react, something totally different. But essentially when you try to go that middle path with something that defines its own syntax, it starts to bleed into everything. It's not self contained. I'd argue maybe tailwind is like that as well, so you want to put it in templates or something. But if your htmx code lives in your actual code the way it does with Go a lot of the times because they promote building these partial functions, it looks horrible, very hard to reason or manage. I'm not talking one or two snippets, I'm talking when you have a full blown web app.

The reality is it's going to suit some people and some languages really well and others not so well. I think I like html/css/js and using AI to generate that. But I also like Go templates and trying to isolate that in a programmatic way. I find htmx in principle, a good idea, but when I actually tried to use it, fundamentally the wrong tool for me.

Re: Please just try HTMX

#64
> The ecosystem is why your node_modules folder is 2GB. The

And every months a few of those modules try to exfiltrate your credentials…

Re: Please just try HTMX

#65

Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…

I didn't find it too hyperbolic, I think they were very clear on where htmx can help, eg. the section "you're not building Google docs".

Agree updated my comment

Re: Please just try HTMX

#66
post #56
post #50

Earlier quoted context omitted.

Thanks I'll look into it, but on first glance I feel like I just got space blasted by the website! What happened to simple websites eh

Lol, it's ... a feature ... I think

Well I guess part of the problem is I feel like I'm looking at the website with a magnifying glass...

Re: Please just try HTMX

#67

Hey, I created htmx and while I appreciate the publicity, I’m not a huge fan of these types of hyperbolic articles. There are lots of different ways to build web apps with their own strengths and weaknesses. I try to assess htmx’s strengths and weaknesses here: https://htmx.org/essays/when-to-use-hypermedia/ Also, please try unpoly: https://unpoly.com/ It’s another excellent hypermedia oriented library Edit: the arti…

I haven't really tried htmx yet, but I used to love intercooler, and your essays are always a fun read. When I saw the title I thought it was some kind of joke from you, because it's like the opposite of your normal style.

Re: Please just try HTMX

#68
post #16

The thing is React is usually fine, and even if you don't have to build _this_ thing in React due to simplicity, why bother learning two paradigms when you can just use the heavier one for everything and most likely never encounter any real practical showstopping issue?

> you can just use the heavier one for everything

Because people don't like using heavyweight solutions needlessly. That's the logic that begat C++ and Ada and Multics and ASN.1 and CORBA. All of which were good solutions useful for "everything" in their domain. But people hate them, mostly.

Historically big "everything" solutuions end up losing in the market to lighter weight paradigms with more agility and flexibility. Almost every time. React[1] was such a solution once!

[1] Which really is a shorthand for "modern node-based web development with tens of thousands of npm dependencies and thirteen separately-documented API and deployment environemnts to learn".

Re: Please just try HTMX

#69
post #15

I am tired of people using the smallest "Hello World" example to demonstrate how something is better than React -- "See, you don't need all these things to get a website up and running!" Of course it will work. I can vibe code the most terrible web framework you have seen within 20 minutes and claim it is better than React, but what does it prove? > You write zero JavaScript > The whole library is ~14kb gzipped Oh su…

To put a bit more colour on this, I think the fear of most devs with an ultra-simple framework like this is that eventually you hit a wall where you need it to do something it doesn't natively do, and because the only thing you know is these magical declarative hx-whatever attributes, there's no way forward.

I appreciate the basic demos, but I think what would really sell me is showing the extensibility story. Show me what it looks like when I need it to do something a bit beyond what it has in the box. Where do I add the JavaScript for that? Is it raw, inline, or are we back to packages and bundling and a build step? Am I building application JS, or some kind of extension or plugin to htmx itself? How chained am I going to be to its specific paradigms and opinions?

The page says htmx isn't for writing a true SPA like Google Docs, but where's the line? Show me an app that has pushed up against the limits of this system, and what happens in that scenario.

Re: Please just try HTMX

#70
post #60

I did. My startup did. And now we’re going to rip it all out and move to a React front-end. HTMX makes response handling much more complex. Every endpoint returns 3–5 different HTML fragments. Frontend and backend must agree on every scenario — success, validation errors, system errors, partial updates, full reloads. And HTMX is still a fairly obscure library. The documentation and examples are lacking, there isn’t a…

> Frontend and backend must agree on every scenario

When is this not the case?

Post reply on HN