Recently I had Carson on my podcast: https://youtu.be/9H5VK9vJ-aw?si=cv4ScxFTnJMRbsSH
He talked about this idea quite a bit, I love the idea of giving backend developers more control over the UI without resorting to huge JS frameworks
Is htmx Just Another JavaScript Framework?
31–40 of 318 posts
Re: Is htmx Just Another JavaScript Framework?
#32It is not the same at all. Of course it needs javascript on the back to work. But the concept is totally different. It uses a hypermedia declarative model, an extended POST/GET etc. model. It keeps things very simple compared to a framework like React where you need a package manager, a transpiler and a json backend for data (not returning hypermedia). So I would not consider it another Javascript frontend framework…
"original html with extensions"
I just had this weird flashback to Frontpage...
Re: Is htmx Just Another JavaScript Framework?
#33> But you can write React in this library-like manner too and nobody argues that React isn’t a framework. I think people do still make this argument
There's people in this thread that are (implictly) making that argument
Re: Is htmx Just Another JavaScript Framework?
#34I prefer to refer to htmx as a "future polyfill". Eventually, htmx semantics will become part of the web standard, and older browsers (or those that choose not to implement the feature) will need this polyfill.
> Eventually, htmx semantics will become part of the web standard
Why do you think that will be the case?
I'm not aware of any effort being made to evolve htmx into a web standard (either by introduction into existing specifications or direct adoption by browser), so this is about as baseless of a claim as someone saying "I see JQuery as a future polyfill" in ~2006.
Re: Is htmx Just Another JavaScript Framework?
#35Liked this phrase.. Explains the big picture beautifully
"a system by which elements enter and exit the DOM via network request."
Re: Is htmx Just Another JavaScript Framework?
#36I prefer to refer to htmx as a "future polyfill". Eventually, htmx semantics will become part of the web standard, and older browsers (or those that choose not to implement the feature) will need this polyfill.
CoffeeScript inspired ES2015, jQuery inspired querySelector and some other DOM APIs, but none of them would be a usable polyfill, and the standard APIs/syntax is not the same.
Apart from that, I'm not sure if I even agree with the point as a metaphor.
Some parts of htmx would make it easier to implement a form submit confirmation message or similar stuff.
everything else is either better served fully server-side or needs heavier client JS.
E.g. ajax pagination is useless without routing... well maybe I need to try htmx more thorougly to understand this stance. right now I don't.
it's not hard to do a fetch request and set innerHTML on an element, right?
Re: Is htmx Just Another JavaScript Framework?
#37I would refer it as a library.
Like any library, it has a bunch of functions available to use. The difference, however, is that you don't use them directly. You are just writing html with htmx tags, etc.. and letting htmx, the library, do the rest.
This is it for the most part - but I understand some complications could break that rule. I doubt it would be that often if at all.
Re: Is htmx Just Another JavaScript Framework?
#38So what's the problem with a bundler/transpiler etc? You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error. Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.
> You set it up once. It takes a few hours, maybe a day. Until you need to update a dependency on a large codebase, which takes weeks because dependency A doesn't work with dependency B version X, and updating dependency B means that it no longer works with dependency C version Y, and so on. And nobody uses dependency C anymore -- it's unmaintained, so you need to rewrite everything to use dependency D. Then you need…
Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.
Re: Is htmx Just Another JavaScript Framework?
#39htmx is one of those things, like SQLite on the server, that you will incessantly see on HN, but rarely see used at large profitable companies. Say you use python and Django. Why use htmx instead of Django templates? Same with ruby and rails, elixir and phoenix, etc. the trend is clearly towards live view/hotwire OR things like server side react. Htmx is in a weird position that makes no sense unless you want to use…
This is not necessarily refuting what you said but perhaps a different point of view. I wrote a simple backend servive with go and wanted to have some on off switches and status icons for it. I don't know js and am not interested in learning it. Htmx gave me enough interactivity to put together that one status thing with buttons in a few hours. To me that's valuable.
Re: Is htmx Just Another JavaScript Framework?
#40Haven't heard of htmx before, but I might use it on a future project if I remember. As somebody who is not a frontend engineer, but still likes to make a website every now and then. I haven't found a full framework (vue, react, etc.) that I've been able to go full into and still use jquery and writing plain css/html. Htmx looks like a slight feature upgrade to jquery that I enjoy.
That’s basically where it lives, though it expects your backend to return html chunks iirc
You don't need to return partial html, you can use hx-boost and return full pages and it will only update the body.