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

Is htmx Just Another JavaScript Framework?

htmx.org

Post reply on HN
Print view View original

131–140 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#131

Post by karmarepellent »

As every discussion about HTMX usually evolves to people arguing why it is not widely adopted by big corporations and the like, let me be the first to share a thought on that topic.

Could it just be an organizational problem? When you start using HTMX in your company your neat distinction between frontend and backend devs collapses and everyone suddenly must be a full-stack developer. When you can avoid that additional cost by simply continuing to use React (or others), why wouldn't you?

Edit: As a side note, I have never used any large JS framework, only HTMX. Just trying to put myself in the shoes of happy React users and such.

Re: Is htmx Just Another JavaScript Framework?

#132

Post by recursivedoubts »

game_the0ry wrote: post #53

I never used or looked into htmx, but... I feel like htmx fell into the same hype-cycle as every JS framework - initial interest was enthusiastic, but will likely fade as folks use it in the real world and any holes in the things it tries to solve are exposed. On to the next, I guess... Or go back to Ruby on Rails :)

gotta start somewhere

Re: Is htmx Just Another JavaScript Framework?

#133

Post by germandiago »

chrisco255 wrote: post #22
germandiago wrote: post #10

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

AJAX means Asynchronous Javascript and XML. It's quite literally JS. AJAX was not part of the original web model. It came out around the year 2000.

The only part that htmx adds is avoiding reloading the hypermedia and allow swaps via AJAX as you say. But the programming model stays hypermedia-based.

For example, your server returns markup, not Json to a React frontend or similar.

This simplifies things a lot though it also has some disadvantages.

Advantages: if your backend changes the return to extend functionality, the hypermedia will be returned with no required changes on the frontend.

On the other hand, if you want to do a data-based json API htmx is not what you want, because it conflates returning functionality (embedded in the hypermedia) with presentation, instead of returning only data.

Re: Is htmx Just Another JavaScript Framework?

#134

Post by hellcow »

pphysch wrote: post #127
falsandtru wrote: post #125

Earlier quoted context omitted.

An example on the top page shows that this is an operation that should be written as a program. Therefore, this is not markup. Syntax that is not markup will not be the HTML specification. >

How is that different than a standard or element that submits an HTTP request, receives some HTML in response, and uses that HTML to render a new GUI?

The point of HTMX is that any element can submit HTTP requests, and you can drop the response anywhere in the document. It no longer has to be just and with full page reloads.

Re: Is htmx Just Another JavaScript Framework?

#135

Post by diggan »

hobofan wrote: post #115
diggan wrote: post #100

Earlier quoted context omitted.

Obviously, you need to start the application somehow. But when you initially setup a rails project, do you write the code that bootstraps the application? Or do you just run `rails server` and the application figures out what to load, and starts the application for you?

But when you initially setup a React project, do you write the code that bootstraps the application? Or do you just run (`pnpm create vite` +) `pnpm run dev` and the application figures out what to load, and starts the application for you? We can do this all day...

When you initially setup a React project, you run `npm install --save react react-dom` or similar, create a HTML file that loads a JS file that you also need to write, that includes a call to `ReactDOM.render` somewhere. That's it, no more, no less.

Contrast that with rails where you run `rails new $app`, then `rails server` and everything is made for you.

Not sure why you're mentioning vite here, we're explicitly talking about React and Rails, not wrappers or tooling around them.

Re: Is htmx Just Another JavaScript Framework?

#136

Post by gkbrk »

satvikpendem wrote: post #121
chatmasta wrote: post #117

Earlier quoted context omitted.

It sounds like your devs are not following best practices with regards to lockfiles and version pinning.

Indeed. If half won't even build anymore, that's insane. It seems like they want to be on the latest version all the time which obviously will have breaking changes.

> they want to be on the latest version all the time which obviously will have breaking changes

Not very common in sane ecosystems.

Re: Is htmx Just Another JavaScript Framework?

#137

Post by omnimus »

pphysch wrote: post #127
falsandtru wrote: post #125

Earlier quoted context omitted.

An example on the top page shows that this is an operation that should be written as a program. Therefore, this is not markup. Syntax that is not markup will not be the HTML specification. >

How is that different than a standard or element that submits an HTTP request, receives some HTML in response, and uses that HTML to render a new GUI?

It's not different. The question is if we would have current JS capabilities in the past would we choose adding handling of to HTML or would we say use JS for that. I am not sure what is the right answer but adding features to both sides is probably not a great idea because you just bloat everything.

Re: Is htmx Just Another JavaScript Framework?

#138

Post by satvikpendem »

gkbrk wrote: post #136
satvikpendem wrote: post #121

Earlier quoted context omitted.

Indeed. If half won't even build anymore, that's insane. It seems like they want to be on the latest version all the time which obviously will have breaking changes.

> they want to be on the latest version all the time which obviously will have breaking changes Not very common in sane ecosystems.

It's common everywhere that at least one dependency will have some breaking change, even in "same ecosystems."

Re: Is htmx Just Another JavaScript Framework?

#139

Post by pphysch »

How do HTMX users manage the complexity of endpoint dependency graphs?

Once you go from simple route->page mapping to heavy HTMX usage, you now have routes that are implicitly dependent on other routes to work properly. "/users/42/" relies on hx-post="/users/42/send-email", and so on. Are there ways to model that dependency graph outside of your brain, say an IDE plugin.

Re: Is htmx Just Another JavaScript Framework?

#140

Post by troupo »

karmarepellent wrote: post #131

As every discussion about HTMX usually evolves to people arguing why it is not widely adopted by big corporations and the like, let me be the first to share a thought on that topic. Could it just be an organizational problem? When you start using HTMX in your company your neat distinction between frontend and backend devs collapses and everyone suddenly must be a full-stack developer. When you can avoid that addition…

I'm a fullstack developer in the widest sense of the world: I worked exclusively on the backend side, and exclusively on the frontend side, and on both at the same time.

I wouldn't touch HTMX with a ten-foot pole :)

It's a somewhat haphazardly defined DSL around magical attributes, their values, and awkward workarounds with somewhat badly specified behaviours (what's `hx-select-oob` exactly?).

There are other projects that do these things better, with less pretentiousness: Phoenix Liveview or Laravel LiveWire, or even Hotwire

Post reply on HN