Live data from Hacker News

Is htmx Just Another JavaScript Framework?

htmx.org

181–190 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#181
post #146
post #41

Earlier quoted context omitted.

When I initially read the htmx documentation I was confused because it kept talking about a hypermedia client. The context clues suggested they were referring to htmx but my brain kept saying "isn't the browser the hypermedia client?" Eventually it sank in that htmx is an extension of the hypermedia client. When I first tried to use htmx I experienced a lot of discomfort regarding areas where htmx feels non-standard,…

> Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away. What do you mean by "moving the boundary of hypermedia client"? HTMX tries to claim that hypermedia to only applies to HTMX because something something browsers and html. Simply put, anything that talks HTTP and understands responses from a server is a hypermedia client to an extent.…

Htmx posits that current browsers aren't "truly" hypermedia since only anchor tags and forms can initiate GET/POST requests. It is more of a tech demo showing what client with ANY tag being able to do requests would look like.

That's why whether it is library/framework is besides the point. The author posits that these features should be in the spec, and tries as closely as possible to show what something might look like if we had it in the spec

Re: Is htmx Just Another JavaScript Framework?

#182

I like the basic idea of htmx: respond to user input by making server requests that return new html for a subset of the page. However, I think there's a pretty significant language design problem and htmx's solution is language proliferation. There is a very low "expressivity ceiling" for what can be encoded into html attributes. The hx-trigger attribute defines a new, very limited domain specific programming languag…

This is correct, but... logic belongs in attribute strings! Even in basic HTML, it can change what kind of HTTP request your makes, or what kind of value your sends, or where your link goes.

Without question, there's a lower expressivity ceiling to attribute-based specifications, but there is a lot that you can do within that ceiling, and you benefit in other ways by keeping your application at that "level," so to speak. [0]

[0] https://unplannedobsolescence.com/blog/custom-html-has-level...

Re: Is htmx Just Another JavaScript Framework?

#183
post #21

HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.

I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML. In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get to target a section of the page that isn't an has been argued about and hashed out for years.…

> Those questions are all solution-oriented, not problem-oriented.

I think the problem is at it's core, "how do I add rich interactivity and dynamism to an HTML document without scripting?"

A general event-driven document model where document events can automatically issue server requests whose replies then trigger more document events and/or updates makes sense. htmx is one way to do this, but probably not the only or best way, but it has the core idea right: generalize hypermedia and extend the event model.

Re: Is htmx Just Another JavaScript Framework?

#184
post #21

HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`. The discussion about Library vs. Framework misses the core objective of the HTMX project.

Agreed

Re: Is htmx Just Another JavaScript Framework?

#185

I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analy…

Would you say templaters like Vue and Angular, with the HTML additions of `v-for`, `@click`, etc., are a library in a similar way to HTMX?

If so, is the differentiation then just setting apart HTMX, Vue, etc from JSX and other JS-in-HTML approaches?

Re: Is htmx Just Another JavaScript Framework?

#186
My biggest beef with htmx has more to do with the fact that it gets hyped as a React/Vue/Svelte alternative, when it's more accurate to describe htmx+ as an alternative.

Also the constant use of pretentious memes on the official blog. But otherwise, I'm looking forward to trying it out for my next pet project.

Re: Is htmx Just Another JavaScript Framework?

#187

I am the author of htmx. I think htmx is a library using the following definition: - a library you call - a framework calls your code in htmx you add attributes to HTML to "call" htmx, so, from the perspective, you can call it a library. On the other hand, those "calls" are called back into via event handlers in JavaScript, so an argument can be made that, even at this level, htmx is a framework. I liked alex's analy…

I'm thinking that, at this point, the argument about whether htmx is a library or framework is distracting from, rather than clarifying, the real question, which is whether htmx is a good/useful abstraction for web app development.

Re: Is htmx Just Another JavaScript Framework?

#188
post #146

Earlier quoted context omitted.

> Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away. What do you mean by "moving the boundary of hypermedia client"? HTMX tries to claim that hypermedia to only applies to HTMX because something something browsers and html. Simply put, anything that talks HTTP and understands responses from a server is a hypermedia client to an extent.…

> Simply put, anything that talks HTTP and understands responses from a server is a hypermedia client to an extent. No, anything that understands hypermedia responses is a hypermedia client. Cat GIFs are not hypermedia so a cat GIF viewer is not a hypermedia client Maybe I'm overly grumpy this morning but words do actually have meanings that we can look up and refer to

> words do actually have meanings that we can look up and refer to

It's odd to insist on strict word choice when transferring GIF images using the hypertext transfer protocol.

Re: Is htmx Just Another JavaScript Framework?

#189

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…

You’re missing a huge point: there’s a ton of devs that went into react bootcamp or whatever. Building a 50 person team on a technology that isn’t widely used or heavily supported by Google/Adobe/Microsoft is a huge hurdle. Even Typescript isn’t really used correctly, people basically use ts-lint on a lot of projects I see. For large companies they will also turn projects into BAU (business as usual) where the pressure is to push down costs and move it overseas. Finding a large overseas team on htmx at React prices will be difficult.

Typescript is popular because people don’t use it a lot, and it doesn’t break things.

If you’re introducing something new the bar is incredibly high to be obvious as to why to switch.

Post reply on HN