5 ms·

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 attrib

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 analysis and I think his definitions and thinking contribute to the discussion, so I posted it to the htmx website. Even though I still consider htmx a library. :)

ncphillips 3y ago
I’m the CEO of HTMX. This is correct.
dfabulich 3y ago
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 of your code as a library instead of a framework. Instead, I urge you to describe HTMX as a "lightweight HTML framework."
- alexpetros 3y ago
  Broadly speaking, that's basically what this article says!
- recursivedoubts 3y ago
  yep, i understand that view, but i'm going to keep calling it a library because i think it's a library, but I get it
- mhink 3y ago
  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?)
candiddevmike 3y ago
IMO, a library is easily swappable with another library, a framework is not, it's all over your codebase. Htmx meets the definition of the latter.
- gameman144 3y ago
  This is an interesting definition to me. Any library is going up make implementation-specific assumptions, so unless you're using a library that's purely an interface that multiple implementations conform to (e.g. SQL, and even then not fully) then there's necessarily going to be some migration work when switching libraries.
lemoncade 3y ago
lol u are everywhere
- recursivedoubts 3y ago
  i'm in ur walls
alexpetros 3y ago
Some have called this the "Team of Rivals" approach to open source maintenance.
ysavir 3y ago
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?
- recursivedoubts 3y ago
  I'd look mainly at the amount of code you have to provide to them and the infrastructure (e.g. JSX) they require. Not saying there isn't a blurry line here.
  - ysavir 3y ago
    That feels like goal shifting.
jmull 3y ago
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.
drbawb 3y ago
I agree with your definition, and I also believe it's an important distinction and a _better definition_ than the article author's. However I'm not sure I agree with your self-assessment of htmx being a library. HTML is not the host programming language: that'd be JavaScript. Arguably, in this case, it's also whatever is on the other side of the HTTP requests htmx is making; which is almost certainly _not_ HTML. htmx is maintaining its own event-loop (to react to DOM changes, read attributes, auto-wire itself, etc.), it's _calling into_ the user's code, either via the _declaratively configured_ HTTP endpoints when reacting to DOM events, or via callbacks provided by your event subscribers. These reactions were not explicitly programmed by a library-user in JavaScript, the host language. They were configured in markup and your framework altered its internal state and event-processing accordingly based on that configuration. It is very much magic, and very much behaves like a framework. (I say this with the utmost respect, I don't think "framework" is a dirty word or anything. htmx is great conceptually, you've done a fantastic job implementing it, and it's a blast to use. I don't think it being a "framework", per this definition, detracts from what it is. I think it can also compete with other frameworks _just fine_ without needing to twist semantics.) htmx's model is no different to me, conceptually, than Phoenix, Rails, et al. "magically" knowing which controller & action to invoke because I declared a route somewhere in a DSL, which they in-turn invoke to respond to an event. (I definitely don't consider either of those to be libraries.) What sets htmx apart is that it's a small, focused, _easily understood_ framework. I do understand the need to differentiate htmx from the contemporary burdensomely-complex JS frameworks, but I don't think framework v. library is the right way to frame it.
- recursivedoubts 3y ago
  i agree with your analysis and find no flaw in you logic, but i continue to insist htmx is a library
klysm 3y ago
So it delegates the framework part to the browser?
- recursivedoubts 3y ago
  that's actually not a bad way to frame cough it

ncphillips 3y ago

I’m the CEO of HTMX. This is correct.

dfabulich 3y ago

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 of your code as a library instead of a framework. Instead, I urge you to describe HTMX as a "lightweight HTML framework."

alexpetros 3y ago
Broadly speaking, that's basically what this article says!
recursivedoubts 3y ago
yep, i understand that view, but i'm going to keep calling it a library because i think it's a library, but I get it
mhink 3y ago
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?)

candiddevmike 3y ago

IMO, a library is easily swappable with another library, a framework is not, it's all over your codebase. Htmx meets the definition of the latter.

gameman144 3y ago
This is an interesting definition to me. Any library is going up make implementation-specific assumptions, so unless you're using a library that's purely an interface that multiple implementations conform to (e.g. SQL, and even then not fully) then there's necessarily going to be some migration work when switching libraries.

lemoncade 3y ago

lol u are everywhere

recursivedoubts 3y ago
i'm in ur walls

alexpetros 3y ago

Some have called this the "Team of Rivals" approach to open source maintenance.

ysavir 3y ago

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?

recursivedoubts 3y ago
I'd look mainly at the amount of code you have to provide to them and the infrastructure (e.g. JSX) they require. Not saying there isn't a blurry line here.
- ysavir 3y ago
  That feels like goal shifting.

jmull 3y ago

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.

drbawb 3y ago

I agree with your definition, and I also believe it's an important distinction and a _better definition_ than the article author's. However I'm not sure I agree with your self-assessment of htmx being a library. HTML is not the host programming language: that'd be JavaScript. Arguably, in this case, it's also whatever is on the other side of the HTTP requests htmx is making; which is almost certainly _not_ HTML. htmx is maintaining its own event-loop (to react to DOM changes, read attributes, auto-wire itself, etc.), it's _calling into_ the user's code, either via the _declaratively configured_ HTTP endpoints when reacting to DOM events, or via callbacks provided by your event subscribers. These reactions were not explicitly programmed by a library-user in JavaScript, the host language. They were configured in markup and your framework altered its internal state and event-processing accordingly based on that configuration. It is very much magic, and very much behaves like a framework. (I say this with the utmost respect, I don't think "framework" is a dirty word or anything. htmx is great conceptually, you've done a fantastic job implementing it, and it's a blast to use. I don't think it being a "framework", per this definition, detracts from what it is. I think it can also compete with other frameworks _just fine_ without needing to twist semantics.) htmx's model is no different to me, conceptually, than Phoenix, Rails, et al. "magically" knowing which controller & action to invoke because I declared a route somewhere in a DSL, which they in-turn invoke to respond to an event. (I definitely don't consider either of those to be libraries.) What sets htmx apart is that it's a small, focused, _easily understood_ framework. I do understand the need to differentiate htmx from the contemporary burdensomely-complex JS frameworks, but I don't think framework v. library is the right way to frame it.

recursivedoubts 3y ago
i agree with your analysis and find no flaw in you logic, but i continue to insist htmx is a library

klysm 3y ago

So it delegates the framework part to the browser?

recursivedoubts 3y ago
that's actually not a bad way to frame cough it