Live data from Hacker News

Is htmx Just Another JavaScript Framework?

htmx.org

211–220 of 318 posts

Re: Is htmx Just Another JavaScript Framework?

#211

There's just little benefit in HTMX unless you have a live financial dashboard or something like that. I find the opposite approach of local-first (database in the client). It fits more solutions and solves many more things (free offline, syncing, undo support) and getting rid of caching, retries, and latency. Of course the industry wants you to want more on the server though. Same view applies to RSC (react server c…

oh, i dunno, seems like the internet has been somewhat successful as a distributed system, but ymmv

Re: Is htmx Just Another JavaScript Framework?

#212

Earlier quoted context omitted.

ironically I originally rejected it in favor of "kutty": https://htmx.org/posts/2020-5-17-kutty-er-htmx-0-0-3-is-rele... better to be lucky than good, I guess

I, for one, am glad that you didn't release a self-harm framework ;)

yeah, looking back it's ridiculous, how could I not use htmx when I had managed to snag htmx.org? but I'm an idiot.

thankfully the fates conspired to force my hand

Re: Is htmx Just Another JavaScript Framework?

#213

There's just little benefit in HTMX unless you have a live financial dashboard or something like that. I find the opposite approach of local-first (database in the client). It fits more solutions and solves many more things (free offline, syncing, undo support) and getting rid of caching, retries, and latency. Of course the industry wants you to want more on the server though. Same view applies to RSC (react server c…

oh, i dunno, seems like the internet has been somewhat successful as a distributed system, but ymmv

centralizing would be using HTMX and authoritative servers.

local-first is more decentralized as your clients can sync directly with each other (or through a dumb proxy for NAT punching)

I see no need for servers to be anything but dumb proxies for clients. Not the opposite of making clients dumb terminals.

Re: Is htmx Just Another JavaScript Framework?

#214
post #26
post #12

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

This is such a common issue with npm and bundler it was an inside joke/meme at every company I worked at.

Person A: "Hey, so I ran bundle update and it's not working."

Person B: "You updated the dependencies? WHY WOULD YOU DO THAT!"

Re: Is htmx Just Another JavaScript Framework?

#215
post #169

Earlier quoted context omitted.

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.

Ouch, if you're using gulp/grunt/browserify or anything that wasn't invented six months ago then you're doomed anyway :)

Re: Is htmx Just Another JavaScript Framework?

#216

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 :)

>Or go back to Ruby on Rails :)

HTMX is basically a backend agnostic Hotwire, which is the direction RoR has gone

Re: Is htmx Just Another JavaScript Framework?

#217

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…

For what it's worth, the landscape of Web development was much, much different in 2014 or so. Ruby on Rails was still a huge player, and most major OSS projects meant to enable Web development took a lot of cues from it.

Projects like Angular, Ember.JS, and Backbone (and for that matter, Rails' own Turbolinks system) very much expected you to build your entire application in them from the get-go.

The gist of React saying "this is a view library" at that point was largely about what you should expect React not to do for you. For example, two-way data binding, where the framework managed a fetch lifecycle as well as plugging the result into a view. "React is a view library" was letting devs know that they shouldn't expect React to do this- they should expect to make calls themselves and re-render the view accordingly.

I actually think it's still fair to say that React *itself* is still "just a view library", but that's sorta like saying Linux is "just a kernel". Sure, it's technically true, but at this point when we're talking about React we're talking about the whole ecosystem surrounding it as well. That wasn't the case 10 years ago (damn, has it really been that long?)

Re: Is htmx Just Another JavaScript Framework?

#218

Earlier quoted context omitted.

oh, i dunno, seems like the internet has been somewhat successful as a distributed system, but ymmv

centralizing would be using HTMX and authoritative servers. local-first is more decentralized as your clients can sync directly with each other (or through a dumb proxy for NAT punching) I see no need for servers to be anything but dumb proxies for clients. Not the opposite of making clients dumb terminals.

welp, when you are coordinating things it's often a tremendous simplification to have a centralized source of truth and then present representations of that truth in the form of hypermedia to hypermedia clients, using hypermedia as the engine of application state

of course, it's not right for everything and there are alternative approaches that work better or worse, depending on context, but i'd say it's hard to not call it a pretty successful approach to distributed systems

Re: Is htmx Just Another JavaScript Framework?

#219
XML is a pain, and I'm including JSX in this. Writing open/close tags, and then using wakas () everywhere seems unnecessary and creates ugly files. I feel the DOM should also expose other languages to interface with and browsers should detect that. Imagine web apps written with python and YAML for templates (on the client side, without transpiling).

Re: Is htmx Just Another JavaScript Framework?

#220

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…

I think htmx is using the Rule of least power which "suggests choosing the least powerful [computer] language suitable for a given purpose"

https://en.wikipedia.org/wiki/Rule_of_least_power

Post reply on HN