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

Please just try HTMX

pleasejusttryhtmx.com

Post reply on HN
Print view View original

121–130 of 530 posts

Re: Please just try HTMX

#121

Post by Austizzle »

jtbaker wrote: post #95
komali2 wrote: post #59

Earlier quoted context omitted.

Right, it's also bothered me that the Vue docs spend so much time showing how it's a "progressive" framework. "Just use it for one component!" And show examples of how it can be lazy loaded in for your special complex spot that needs vue. Like c'mon, if I'm using Vue, I'm using Vue. Same for React. Strap me into the native state management solution for your framework, your router, your preconfigured bundler. I'm not…

Not having to deal with npm and a build step can remove a huge barrier to adoption for a large number of potential adopters, or people that just want some lightweight interactivity in an app.

That's what got me into Vue and I still use build less Vue all the time for tiny little sites that aren't worth setting up a whole CI process for. It's really lovely that it's an option.

Just like how easy jQuery was to get started with back in the day, but a whole framework

Re: Please just try HTMX

#122

Post by catapart »

shkkmo wrote: post #49
catapart wrote: post #7

Sorry, but it's a no from me. htmx is a great idea, but it's not necessary anymore. We're very close to invokers being baseline (and even that is just an extension of the "composedPath includes -> invoke" pattern), and that will take care of plenty of what htmx was designed to do. Between features like that, and web components, I'm very happy to stick with "plain HTML" (no frameworks; my web components do not draw fr…

The standard invoker commands deal with the display of already loaded page content in the DOM. HTMX deals with loading content into the DOM, not managing display of the DOM. They serve two different roles and together should handle the majority of javascript framework use cases. Web Components does cover some of the same use case as HTMX, but is intended for when a server is returning data rather than HTML. It is bot…

> A prefilled list is never an acceptable solution for a search box.

Yes it is. When the query is more expensive than the entire dataset included in some other query, a static list built from previously queried content is the more performant search, even if you want to classify it as a filter. I, as a user, am still searching through this list of unknown nodes even if you, the program, are just filtering what your nodes are for me. All searches are filters; hard lines for best practices only matter insofar as they engage with their practical application.

Re: Please just try HTMX

#123

Post by ErroneousBosh »

stefan_ wrote: post #109
ErroneousBosh wrote: post #88

Earlier quoted context omitted.

> It's terrible, why would I want my endpoints to return random HTML fragments? What would you return instead? It's easy to generate HTML, because that's what your server is already generating (and that's about all it should generate).

HTML is the last thing I would ever want to generate on my embedded device, it's a terribly verbose string-based mess invariably coupled with stylistic choices. Which is why my servers don't generate any of that, they serve static files - and any interactive information in something that looks a lot more like an interface definition.

Okay, so what do you your servers actually serve stuff to?

I kind of don't get why if you want to display something in a web browser you'd generate anything other than HTML.

Re: Please just try HTMX

#124

Post by avisser »

xnorswap wrote: post #93
naasking wrote: post #62

Earlier quoted context omitted.

> 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.

That's possibly true, but I wonder why react as an abstraction fails to deliver that kind of independence. In theory, react developers ought to be able to code against the react API in typescript, without seeing the "raw" HTML+JS that gets delivered to the browser. So what's failing those developers? Is it the tooling, the abstraction itself, or something else?

Off the top of my head, C# is both the language & the runtime. React only throws things over the fence to browsers.

Probably helps a lot to keep abstractions from leaking.

Re: Please just try HTMX

#125

Post by zihotki »

elevation wrote: post #110
asim wrote: 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…

> it polluted my codebase HTMX is less noisy if you integrate it into your backend framework. A contact of mine build a python/flask app. To simplify coding, he wrote a file to extend the flask framework to support the HTMX patterns he needed with just a single line of boilerplate. Took him about a day, his team is happy with the results.

It's not less noisy, you just move the noise to the backend

Re: Please just try HTMX

#126

Post by embedding-shape »
You know, I see logic/"programming" inside of templates and I'm out, gave up that life many years ago and never have I been eager to go back to it.

No, I'll keep using hiccup and similar things that are just data and nothing more, no syntax, just functions and built-in data structures, then give me HTML as a string which consumers can do whatever with, and we're golden.

Re: Please just try HTMX

#128

Post by alfonsodev »

chrisweekly wrote: post #97
mikepurvis wrote: post #69

Earlier quoted context omitted.

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 m…

This is where I think Astro shines, with its "islands of interactivity" approach. Keep things as simple as reasonably possible, and provide an idiomatic, first-class mechanism for supporting more complexity where appropriate.

I overlooked Astro for a long time, I didn't really get it, and my journey back to it went something like this:

- 1 Getting burned out by Nextjs slowness in a complex production project that shouldn't be that complex or slow on the dev side, (this was 2022 approx)

- 2 Taking a break from React

- 3 Moving back to classic server side rendering with python and Go and dealing now with template engines. Hyped with HTMX and loving it, but my conclusion after so many years of react was that template partials don't feel right to me and templates engines are somewhat not maintained and evolved as used to be. I found my self not feeling naturally inclined to reach for the htmx way and just let the coding agent do it the way they wanted AND stating to notice again the burn out.

- 4 Looking with some envy to co-workers using shadcn how fast they are getting things done and how good they look.

- 5 Wondering would be a way to use JSX with HTMX server side, I miss components, I don't want partial templates.

And then I found Astro, ahhh now I get it, Astro prioritizes generation over run time, and that unlocks a lot of gradual complexity where you can choose how to mix things ( islands ) you get something way more interesting than a template engine, and it uses JSX so you can benefit from React ecosystem.

This where I am now, but yet I have to complete a side project with it to know if I fully get it and love it.

So far seems to me is the answer I was looking for.

Re: Please just try HTMX

#129

Post by mixmastamyk »

perardi wrote: 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…

I found the book (hyper media systems) to be better at explaining full integration than the library site, which gives nuts and bolts and big picture, but not much intermediate info.

Re: Please just try HTMX

#130

Post by bontaq »

I'm a big fan of it for building micro websites with LLMs, since it can keep pretty much the entire thing in context (even including the docs) it seems to perform pretty well.
Post reply on HN