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…
Is htmx Just Another JavaScript Framework?
211–220 of 318 posts
Re: Is htmx Just Another JavaScript Framework?
#212Earlier 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 ;)
thankfully the fates conspired to force my hand
Re: Is htmx Just Another JavaScript Framework?
#213There'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
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?
#214So 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…
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?
#215Earlier 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.
Re: Is htmx Just Another JavaScript Framework?
#216I 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 :)
HTMX is basically a backend agnostic Hotwire, which is the direction RoR has gone
Re: Is htmx Just Another JavaScript Framework?
#217I 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…
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?
#218Earlier 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.
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?
#219Re: Is htmx Just Another JavaScript Framework?
#220I 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…