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

241–250 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#241

Post by jb_hs »

chatmasta wrote: post #117
exabrial wrote: post #94

HTMX is signaling they're around for the long haul, we'll see if they break backwards compatibility or rewrite their API 15 times in the next year. I had one of my dev's do several node/js framework POCs in _September_ last 2023 (current year is Jan 2024 at the time of this writing). Nearly all of the POCs won't even run or build any more because the developers have rewritten something and broke all backwards compati…

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

lockfiles and version pinning is great unless you care about security fixes and maintaining projects over many years. This turns into a slog of maintenance.

Re: Is htmx Just Another JavaScript Framework?

#242

Post by lioeters »

troupo wrote: post #140
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 project…

> Phoenix Liveview or Laravel LiveWire, or even Hotwire

I want a banana and you suggest these jungles. Thanks but no thanks, I'd rather try HTMX which is a library not a framework.

Re: Is htmx Just Another JavaScript Framework?

#243

Post by alexpetros »

davexunit wrote: post #221
alexpetros wrote: post #182

Earlier quoted context omitted.

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 low er 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 s…

I think this is a bit of reductionist interpretation of what I'm saying. Yes, it's technically correct that the attributes on a form change the type request made. That's not really what I'm talking about, though. In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:…

I somewhat agree with you but I think it's important to clarify whether you're talking about htmx or the hx-trigger syntax specifically. In the parent comment you say:

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

And then here you say:

> In the same way that I wouldn't want to manually type a lot of CSS into a style attribute, I wouldn't want to write a small program in an hx-trigger attribute. Something like hx-trigger="input changed delay:500ms, search" is getting rather complicated

I wouldn't write a small program in the hx-trigger syntax either (although, we not only have users who do that, but have contributed to hx-trigger optimizations because they use it so heavily).

Many htmx use cases don't need this at all, some need complexity up to this point, some need far more complexity. It's really up to you to decide at what point you bring in the bigger guns—whether that's hx-trigger, alpineJS, hyperscript, or a React Island.

I agree that hx-trigger is a DSL, and represents the outer limits of htmx's expressivity. My objection is to the argument that htmx's attribute design is an expressivity problem, rather than a well-chosen level of abstraction for the types of problems htmx is best suited to solve (see the sibling comment about Rule of Least Power too).

Re: Is htmx Just Another JavaScript Framework?

#244

Post by zo1 »

satvikpendem wrote: post #201
zo1 wrote: post #199

Earlier quoted context omitted.

No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order of magnitude smaller. One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semanti…

Not really. Python's is worse for example.

Sorry, I have to call BS on this. I'm hugely familiar with Python and used it for over 10 years, pretty much always on "latest version" instead of pinning. And had issues with incompatible versions less than 5 times. JS? Pretty much every single project, if any apreciable chunk of code gets ignored for a few months its almost guaranteed that it has breaking changes somewhere.

Re: Is htmx Just Another JavaScript Framework?

#245

Post by gkbrk »

satvikpendem wrote: post #201
zo1 wrote: post #199

Earlier quoted context omitted.

No, this is highly unique to JS/TS. I've worked in plenty other languages and it's bo where near as bad. Yes they all have some form of this, but it's an order of magnitude smaller. One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semanti…

Not really. Python's is worse for example.

In Python it's really common to install or depend on packages without specifying or locking versions.

When you want to use a new feature that's missing in the version you have, you can upgrade, but in general people expect things to stay in future versions.

Re: Is htmx Just Another JavaScript Framework?

#246

Post by troupo »

recursivedoubts wrote: post #161
troupo wrote: post #140

Earlier quoted context omitted.

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

all of those projects are much more magical, particularly the live* flavor of hypermedia driven applications htmx generalizes the standard hypermedia controls found in HTML: anchors & forms this makes it more work to implement some things, but sticks closer to the basic ideas of HTML and, as always, if nothing magically works, nothing magically breaks

> all of those projects are much more magical,

Oh, they are not. They are more powerful, but they use rather simple concepts. Speaking as the user of Phoenix LiveView who even created his own templating library to work with it.

> htmx generalizes the standard hypermedia controls found in HTML: anchors & forms

Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit.

> the basic ideas of HTML

The "basic idea of HTML" is "render a text page with a few images in one rendering pass with links to other such documents". That is it.

You are perhaps referring to the hypertext vision of Sir Tim Berners-Lee, but that is as far removed from HTMX as HTMX is removed from any other concepts it keeps trying to appropriate.

HTMX is a utility lib with a few diffing utilities that does what nearly every other library does, but chose the high ground of "we're doing it with HTML chunks, so we're better and this is what the founders envisioned".

You're not better. This is not what founders envisioned.

Re: Is htmx Just Another JavaScript Framework?

#247

Post by troupo »

wild_egg wrote: post #165
troupo wrote: 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

Yeah, I went overboard with the example. The issue is that HTMX tries to take over the concept of hypermedia as if it means only HTMX and whatever HTMX is doing :)

Re: Is htmx Just Another JavaScript Framework?

#248

Post by lakomen »

Htmx = pointless hype. It solves no problems and makes everything more complicated.

You have to learn not 1 but 2 new "languages" hypermedia queries and htmx special html attributes.

And what do you receive in return? Nothing that can't be done with other JS frameworks or libraries. Yes, htmx is JS.

That HN people fall for this trick is no surprise as it's frequented mostly by booksmart idiots.

Re: Is htmx Just Another JavaScript Framework?

#249

Post by arcanemachiner »

jslakro wrote: post #110
internet101010 wrote: post #81

Earlier quoted context omitted.

Alpine + htmx + tailwind is pretty much what I use for every quick little front-end thing now. I do still use Django but plan to transition to Rust as a way to get more comfortable with Rust.

What do you use alpine for? htmx is not enough?

Alpine is for client-powered reactivity and HTMX is for server-powered reactivity.

Think about pressing a button that opens a modal with content already delivered by the server (like a settings modal). You don't need to make a HTTP request for that, so you could use Alpine.

Let's say instead that you click a user icon and you want to render a modal that contains user info which hasn't been fetched from the server (because why waste resources loading all this data the user might not see or need?). When clicking that icon, you could use HTMX to fetch the user data from the server then display the resulting content in a modal.

Two different actions with similar visual results (from the user's perspective), but one is all client-side and one requires extra info from the server.

Alpine and HTMX are frequently confused this way, as they solve seemingly similar problems from different ends of the network.

Re: Is htmx Just Another JavaScript Framework?

#250

Post by troupo »

AmpsterMan wrote: post #181
troupo wrote: 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.…

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…

> The author posits that these features should be in the spec

Does he? The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. And that's about it. Nothing about "this should be in the spec"

Post reply on HN