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

161–170 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#161

Post by recursivedoubts »

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…

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

Re: Is htmx Just Another JavaScript Framework?

#162

Post by ndyg »

> As they should! Building with htmx works a lot better if you play to its strengths. You can send JSON-formatted form bodies, if you really insist. But you shouldn’t!

This excellent essay overlooked a '*':

* unless you are using bash + jq for your backend, in which case, JSON-formatted form bodies are quite reasonable.

Re: Is htmx Just Another JavaScript Framework?

#163

Post by karmarepellent »

unsupp0rted wrote: post #42
endisneigh wrote: post #24

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

People use it for the sake of not using JavaScript. To a React client-side developer everything should be done in React on the client-side, with maybe a sprinkle of backend for unavoidable things, like where API keys live. They’ll foot-gun as much backend stuff into the front end as possible. To a certain kind of backend developer, everything should be done typesafe in non-JavaScript on the backend, with a sprinkle o…

Maybe some people are using it to avoid JS at all costs. I am using it to have everything (validation, authentication) in one place, the backend. It also saves me currently four serialization and deserialization steps, which drastically improved performance. meanwhile there will also be a few 10s or 100s lines of JS to enable some specific behaviour that I do not want to (or would be awkward to) implement in HTMX.

I am not saying that it is a silver bullet and people may use it for a variety of reasons, even avoid JS. I try to be less biased and make the best of both worlds. Until now, it has been pure joy.

Re: Is htmx Just Another JavaScript Framework?

#164

Post by alexpetros »

dfabulich wrote: post #155
recursivedoubts wrote: post #128

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…

The React team argued that it was "merely a view library" for years, and as far as I can tell, this was a wrong-headed approach based entirely on vibes. Libraries are cute and charming; frameworks are humongous and domineering. If you think of React and HTMX as cute and charming, and especially if you think of them as much cuter and more charming than their other "frameworky" competitors, then you'll prefer to think…

Broadly speaking, that's basically what this article says!

Re: Is htmx Just Another JavaScript Framework?

#165

Post by wild_egg »

troupo wrote: post #146
dvogel wrote: 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.…

> 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

Re: Is htmx Just Another JavaScript Framework?

#166

Post by alexpetros »

ndyg wrote: post #162

> As they should! Building with htmx works a lot better if you play to its strengths. You can send JSON-formatted form bodies, if you really insist. But you shouldn’t! This excellent essay overlooked a '*': * unless you are using bash + jq for your backend, in which case, JSON-formatted form bodies are quite reasonable.

Author here. Happy to admit that bash + jq backends are an excellent reason to use JSON formatted bodies. Godspeed you crazy animal.

Re: Is htmx Just Another JavaScript Framework?

#167

Post by pupppet »

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…

That's the JS framework lifecycle. Get yourself noticed with minimal boilerplate. Then add more boilerplate.

Re: Is htmx Just Another JavaScript Framework?

#168

Post by tangue »

Cthulhu_ wrote: post #77
dartos wrote: post #29

Earlier quoted context omitted.

I hope it works! HTML is in dire need of some tlc

I was ultimately disappointed in HTML5 even though it was supposed to bring HTML into this era, with things like audio/video tags and new input methods for phone numbers and the like for mobile users. But ultimately it fell flat, was incomplete, and it feels like it's been stagnant again since HTML5 came out.

Yep in 2024 we still haven’t found a generic datepicker and hundreds of people on the internet are coding their own version. HTML5 snafu

Re: Is htmx Just Another JavaScript Framework?

#169

Post by donatj »

marius-sw wrote: post #111
donatj wrote: post #67

Earlier quoted context omitted.

This is exactly what we’re dealing with right now trying to upgrade TypeScript. We’re stuck on an early version of 4.X because of some dependency triangle I haven’t had time to work out.

Hello, I have nearly 10 years of experience dealing with this. Do you need help? I am sure I could fix it in a few hours - either I fix it within 5 hours or you don't pay anything. My hourly rate is 150 EUR and my email is in my profile.

No disrespect but frankly I don't think you could, I don't think anyone could. It's a giant tangle of grunt and require and special custom build systems.

Re: Is htmx Just Another JavaScript Framework?

#170

Post by davexunit »

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 language for expressing side-effects with few means of combination or abstraction. For anything slightly complicated, hyperscript seems to be the favored solution which is yet another new language. All of this caused by trying to shove logic into attribute strings.
Post reply on HN