HTMX aims to render itself obsolete by serving as a proof of concept to advance the HTML specification. In various interviews and blog posts, Carson has mentioned that jQuery was essential only until browsers implemented features like `querySelectorAll`.
The discussion about Library vs. Framework misses the core objective of the HTMX project.
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, such as redirects in the hx- readers on a 200 response. Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away.
Yes htmx is an augmentation of the browser, specifically through enhancing HTML by way of JS. The idea is that JS frameworks became popular due to the lack of additional hypermedia controls which are the basis for how agents (users) interact with websites through hypermedia clients (browsers).
Are you sure HTMX aims to be eventually incorporated in some form or another into the HTML spec? I think I read most of the blog articles on the website but I cannot remember such a statement.
Another question in the same vein: In your view, why is it so important for the project to advance the HTML spec?
By the way I am actually curious about this, I am an avid user of HTMX, but have never contemplated this.
Edit: Ok I think I get it now. HTMX provides hypermedia controls that should have been in the standard from the beginning. It also more-or-less maintains the current semantics of the web as defined in the HTML spec. Therefore it is logical to eventually include it into the standard. That it?
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.
I'd love to see something like HTMX get standardized, but I'm extremely pessimistic for HTMX's prospects for standardization in HTML.
In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get <form> to target a section of the page that isn't an <iframe> has been argued about and hashed out for years.
The goal of these questions is to focus primarily on the problem, and only secondarily on the solution.
For comparison, generally standards folks think we don't want to add programming-language features to HTML, e.g. adding <if> <while> and <set-variable> elements. If you want that sort of thing, you want a full programming language; you want JavaScript, actually.
So, when people propose features that don't perfectly address their problem, we want to ask: what do you want that for? How could we solve those problems better?
HTMX doesn't have really great answers to the "what problem?" question. Look at the home page:
* Why should only <a> and <form> be able to make HTTP requests?
* Why should only click & submit events trigger them?
* Why should only GET & POST methods be available?
* Why should you only be able to replace the entire screen?
Those questions are all solution-oriented, not problem-oriented.
Each of those examples are important problems that HTMX can solve. But it doesn't solve them very well from the perspective of screen-reader accessibility.
For example, there's a bunch of stuff there around managing editable data tables (click to edit, bulk update, click to load rows, delete row, edit row). But none of them work well with screen readers. How would a screen reader describe updates to these data tables? (Go on and try those examples in a screen reader, e.g. iOS VoiceOver. It's not great.)
Of course, editable data tables are a very widely requested HTML feature; it seems quite likely that a feature like that will be added to HTML. When it is, a screen reader will announce the feature as a data table, describing it to the user clearly, including live updates.
Some of the HTMX examples already have recent new HTML features that support them directly, like <dialog>, declarative form validation, using <details> as an accordion (which you can use to support tabs).
In the future, I expect to see HTML features landing like these:
* Editable data tables
* Infinite scroll / lazy loading
* Combobox
* Skeleton UI / Loading
If/when those features get done, it's not totally clear which problems remain that would be a good fit for HTMX's approach to declarative AJAX. Like adding <if> <while> or <set-variable> elements, the problems it solves seem to all have better solutions at a different level.
And yet, we'll probably be waiting 5-10 years for those features to be standardized, at a minimum. So it's a bummer that HTMX probably won't be standardized any time soon, and that the standards committee has consistently let the "best" solution become the enemy of a "good enough" solution.
But, that's what happened, and I expect it to continue to happen, so I wouldn't hold your breath for HTMX standardization. (If you'd been holding your breath ten years ago, you'd be long dead now.)
HTMX breaks the "separation of concerns" paradigm. It's not going to help anyone doing anything complex, and it's going to be a crutch for anyone getting started. It breaks down quickly when the problem is anything more complex than clicking a button to load some content, and then what - rewrite everything in a more capable framework?
> Those questions are all solution-oriented, not problem-oriented.
I think the problem is at it's core, "how do I add rich interactivity and dynamism to an HTML document without scripting?"
A general event-driven document model where document events can automatically issue server requests whose replies then trigger more document events and/or updates makes sense. htmx is one way to do this, but probably not the only or best way, but it has the core idea right: generalize hypermedia and extend the event model.
An example on the top page shows that this is an operation that should be written as a program. Therefore, this is not markup. Syntax that is not markup will not be the HTML specification.
How is that different than a standard <a> or <form> element that submits an HTTP request, receives some HTML in response, and uses that HTML to render a new GUI?
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.
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."
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?)
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.
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.
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.
As a devops engineer who has recently been tasked with building UIs for our team and our developers, HTMX is a godsend. I create apps that often get steadily worked on for weeks and then only maintenance once and a while after that. I used to write django apps, but recently switched to a go backend with go html templates and htmx. This allows me to push everything in one docker image and avoid the black box nature of big frameworks that I don't have the time to fully understand.
I know this doesn't add to the conversation very well but I just want to throw it out there that htmx is a good replacement for a larger framework that you don't fully understand.
Also shoutout aplineJs for making small JS changes easy.
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.
As someone with a similar task (building internal tooling) I must agree. HTMX really is a godsend, especially when you are already feeling comfortable writing backend code. In my case I simply familiarized myself with HTMX and augmented the backend code to return HTML. Yeah, it is obviously a little more than that, but the transition was really smooth.
Hypermedia based web applications are a great fit for developing internal and operational tools. I have been building https://github.com/claceio/clace for making development and deployment easier for such web apps.
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 compatibility.
The Javascript/Node ecosystem is terrible for businesses and you're incinerating cash if your company running in the Node/Javascript rat race.
I'm hoping HTMX injects some sanity into frontend development.
This feels extreme? Any chance you could share numbers or more details on these prototypes? I agree that the ecosystem seems crazy fast on moving. I wouldn't have thought it was that bad. React, in particular, I thought had been fairly stable? (Yes, there are new ways of doing things, but most of the old still work there, to their credit.)
I don't think it's been the case for the last few months in particular, but Next has been historically terrible for this case. It sucks because it's also the best way of developing a React app without worrying much about tons of boilerplate crap.
I have different next projects started at different times and whenever I need to change a single line of text, I have a 50% chance something won't work and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host. I got hit by OpenSSL issues for a static website. Then a potential solution is to upgrade the framework (next or react) but then you start running into a bunch of other issues and you find yourself 8 hours deep for a copy change.
Performance is also a pain to get right as the abstractions keep piling up and especially the rendering cycle of React is a massive pain. The move from class to functional (for the majority a net positive as the functional version is way more readable and clear) made accessing some hooks harder, so know you need to remember some special rules or functions to call in order to get the behaviour you want.
For all new projects I just use solid.js which is a bit nicer compared to React while keeping most of React syntax. The abstraction layer is much smaller compared to React (no vdom, no custom rendering cycle, your function gets executed once, not once per re-render). You just have to remember you are dealing with Proxy instances and you're good to go.
Somehow I didn't have problems with updates but there is way less activity compared to React. I have some projects from 3 years ago just using solid.js, and a bunch of projects with solid-start. I didn't bother updating them, they keep on running, can't complain.
Lockfiles and version pinning are bandaid solutions to be applied in the absence of resources for supporting new versions of libraries, especially given that, unless you maintain your own internal package repositories, you're then dependent on those ancient versions remaining available through your usual channels for the unforeseeable future. On my team, we stick to pulling the latest versions of dependencies, but we run our CI/CD pipeline on every commit and hold onto the logs from the last few successful builds. When it's clear that a dependency upgrade has caused a failure, we check to see if we can afford the work we'd need to do to accommodate the new version, and only if it's nontrivial do we resort to pinning the dependency (but it's usually trivial). Even then, the intention is that this is a temporary workaround until we have the time and people required to make the change.
Using lockfiles and version pinning by default opens you up to all sorts of issues. Breaking changes accumulate, and you'll fall further and further behind, increasing the development effort required to get up to date. If you ever want to use some hot, new library that just dropped with a must-have feature for your project, you're highly likely to run into a conflict that will force you to make all those changes you've been procrastinating. Of course, you'll also find yourself stuck with whatever security vulnerabilities exist in your pinned version of the dependency, to be discovered and exploited at some future date. This is a complete nonstarter in my field of work.
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.
Indeed. If half won't even build anymore, that's insane. It seems like they want to be on the latest version all the time which obviously will have breaking changes.
Any POCs your devs wrote would have been targeted at a specific version of their framework dependencies via their NPM package.json / package-lock.json. So why would any later changes made by framework authors, even backwards incompatible ones, made you unable to run or build them?
I assume they mean they updated their dependencies to the latest. That's somewhat valid.
The trap is this: you have a strong need to update a dependency for a bug fix (particularly security fixes), but the update isn't compatible. So you've got no good option: either live with unfixed bugs or pay the price to update your app to the latest version.
There is some wiggle room though. (1) libraries will often maintain a compatible branch for important fixes. (2) you can often find and apply just the fix/fixes you want to your own version of the library. Obviously, you start to lose the benefit of someone else maintaining the library for you, but when you aren't paying for it, you should always understand that is a nice but temporary state of affairs, so enjoy it while it lasts. (Actually, even when you are paying -- maybe even a lot -- you can still get left behind.)
While I generally would also consider React more a library than a framework, I think there are arguments to be made that it's a framework.
If we go by the common "your code calls a library; a framework calls your code" distinction, then you definitely have to structure your components in a very specific manner so that the React internals can "call your code" to e.g. render one component from it's parent component.
One vital distinction is that even if you define 100 components, nothing will happen unless you call .render from react-dom. Nothing is automatically setup for you.
Compare that to Laravel or anything else that is obviously a framework. You write code and put it in a file in the right place, and it gets picked up automatically, most of the time.
This makes me still consider React a library, rather than a framework. But then there are tons of frameworks that uses React, nextjs is probably one of the more common ones.
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.
This has always been my take too, it reeks of a DSL. It's sort of like a no-code/low-code solution for people overwhelmed by the complexity of the FE ecosystem and/or those who don't want to learn anymore web technology but are proficient backend engineers. This is a completely understandable feeling and I have this feeling almost every day. I think DSLs that abstract markup work great for personal projects (just as a CMS works great for personal websites and marketing blogs), but for anything that starts picking up utility you will inevitably have to do something that breaks out of the DSL's abstraction.
Here's my fear of using DSLs like htmx. At first the escape hatch is your friend but eventually the project stops being an htmx project and becomes a "hyperscript" (or equivalent) project. For anything that reaches maturity, you're then left with the painful task of figuring out how to port hyperscript and htmx to react/vue/svelte (the very thing you were trying to avoid in the first place). This is way harder and more painful than using one of these frameworks as a foundation for your project.
What I don't get is why people that harbor this resentment to FE tech, don't just limit their feature usage. Think server components are dumb -- don't use them! Think react hooks are stupid -- write class components! In the event you actually have to do something that requires you to do something outside of your comfort-zone, you just have to push a little bit of your react/vue/svelte knowledge instead of appending more escape hatches to an increasingly bastardized DSL abstraction.
This is correct, but... logic belongs in attribute strings! Even in basic HTML, it can change what kind of HTTP request your <form> makes, or what kind of value your <input> sends, or where your <a> link goes.
Without question, there's a lower 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 speak. [0]
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:500ms, search" is getting rather complicated, imo, and it's a new DSL with new semantics to understand. And then the recommended escape hatch is... yet another new language? I dunno I just feel like there's something missing here.
Often you want to limit the expressive power, in order to obtain other important guarantees. E.g. much of the time you don't want a Turing-complete language, because it must be able to express a never-terminating program.
HTMX is expressive enough for many smaller cases. If your case requires more richness, you can always pick React, Vue, Elm, etc, and be able to do basically anything on the client side.
Give a programmer a non-Turing complete language and they will use a Turing complete language to compile down to it. When a program is only configurable in YAML, someone will use jinja2 to generate it so they can have loops. SASS exists because CSS isn't expressive enough. Etc. etc. etc. I just really don't subscribe to purposely limiting expressive power via non-Turing completeness. I've never wanted to do this in my own software and it's only ever been a roadblock for me to route around as a user. Spent a lot of time in DevOps where this sort of thing is rampant.
I don't really understand why people would bother arguing whether htmx is a library or a framework. It's a way of making a web site where you write less JS.
The article explains why that's important in the way the author defined the difference between framework and library.
In a nutshell, as defined by the author, a library is a cog which is included by your application and can easily be replaced if it's not being maintained anymore, whereas a framework is the system within which you create your application and switching to a new framework would require essentially rewriting the system (and throwing away what you learnt about how you developed your current app and having to learn the way to develop with the new framework).
Whether you agree with the author's definitions or not is irrelevant to the piece. What is relevant, however, is that one can be far less judicious when including a library, because you can simply replace it in the future, whereas you need to be far more careful when switching to a new framework because it's not as easy to replace.
> It's a way of making a web site where you write less JS.
It bothers me that this point always comes up when a discussion about HTMX arises. For me writing less JS is just a very pleasant side-effect of using HTMX. But the main benefit is just having (nearly) everything in one place (the backend). It is just so much easier to reason about the code.
It is not the same at all. Of course it needs javascript on the back to work.
But the concept is totally different. It uses a hypermedia declarative model, an extended POST/GET etc. model. It keeps things very simple compared to a framework like React where you need a package manager, a transpiler and a json backend for data (not returning hypermedia).
So I would not consider it another Javascript frontend framework at all. I would consider it more like original html with extensions that support Ajax respecting the original web model.
The only part that htmx adds is avoiding reloading the hypermedia and allow swaps via AJAX as you say. But the programming model stays hypermedia-based.
For example, your server returns markup, not Json to a React frontend or similar.
This simplifies things a lot though it also has some disadvantages.
Advantages: if your backend changes the return to extend functionality, the hypermedia will be returned with no required changes on the frontend.
On the other hand, if you want to do a data-based json API htmx is not what you want, because it conflates returning functionality (embedded in the hypermedia) with presentation, instead of returning only data.
that's true, it also need more support from the backend, for react a restful background is all you need, for htmx or html+ajax the backend has to do routing, state management,etc, it's really the traditional MVC approach, but easier for the frontend(no json, just html)
Readit News
The discussion about Library vs. Framework misses the core objective of the HTMX project.
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.
You can create a client that only accepts base32-encoded cat gifs, and that will be a hypermedia client (in its infancy).
Another question in the same vein: In your view, why is it so important for the project to advance the HTML spec?
By the way I am actually curious about this, I am an avid user of HTMX, but have never contemplated this.
Edit: Ok I think I get it now. HTMX provides hypermedia controls that should have been in the standard from the beginning. It also more-or-less maintains the current semantics of the web as defined in the HTML spec. Therefore it is logical to eventually include it into the standard. That it?
In talking to a few standards folks about it, they've all said, "oh, yeah, you want declarative AJAX; people have tried and failed to get that standardized for years." Even just trying to get <form> to target a section of the page that isn't an <iframe> has been argued about and hashed out for years.
Why is that? Well, for example, here's the form you have to fill out to start standardizing a front-end feature. https://github.com/whatwg/html/issues/new?assignees=&labels=...
It asks three main questions:
* What problem are you trying to solve?
* What solutions exist today?
* How would you solve it?
The goal of these questions is to focus primarily on the problem, and only secondarily on the solution.
For comparison, generally standards folks think we don't want to add programming-language features to HTML, e.g. adding <if> <while> and <set-variable> elements. If you want that sort of thing, you want a full programming language; you want JavaScript, actually.
So, when people propose features that don't perfectly address their problem, we want to ask: what do you want that for? How could we solve those problems better?
HTMX doesn't have really great answers to the "what problem?" question. Look at the home page:
* Why should only <a> and <form> be able to make HTTP requests?
* Why should only click & submit events trigger them?
* Why should only GET & POST methods be available?
* Why should you only be able to replace the entire screen?
Those questions are all solution-oriented, not problem-oriented.
Instead, let's look at the examples. https://htmx.org/examples/
Each of those examples are important problems that HTMX can solve. But it doesn't solve them very well from the perspective of screen-reader accessibility.
For example, there's a bunch of stuff there around managing editable data tables (click to edit, bulk update, click to load rows, delete row, edit row). But none of them work well with screen readers. How would a screen reader describe updates to these data tables? (Go on and try those examples in a screen reader, e.g. iOS VoiceOver. It's not great.)
Of course, editable data tables are a very widely requested HTML feature; it seems quite likely that a feature like that will be added to HTML. When it is, a screen reader will announce the feature as a data table, describing it to the user clearly, including live updates.
Some of the HTMX examples already have recent new HTML features that support them directly, like <dialog>, declarative form validation, using <details> as an accordion (which you can use to support tabs).
In the future, I expect to see HTML features landing like these:
* Editable data tables
* Infinite scroll / lazy loading
* Combobox
* Skeleton UI / Loading
If/when those features get done, it's not totally clear which problems remain that would be a good fit for HTMX's approach to declarative AJAX. Like adding <if> <while> or <set-variable> elements, the problems it solves seem to all have better solutions at a different level.
And yet, we'll probably be waiting 5-10 years for those features to be standardized, at a minimum. So it's a bummer that HTMX probably won't be standardized any time soon, and that the standards committee has consistently let the "best" solution become the enemy of a "good enough" solution.
But, that's what happened, and I expect it to continue to happen, so I wouldn't hold your breath for HTMX standardization. (If you'd been holding your breath ten years ago, you'd be long dead now.)
I don't think the point is for HTMX to get standardised, but rather for HTMX to drive conversation and evolutions in the spec.
After all jQuery did not get standardised. Rather the issues solved by subsets of jquery were looked at, and considered for solving in the standard.
I think the problem is at it's core, "how do I add rich interactivity and dynamism to an HTML document without scripting?"
A general event-driven document model where document events can automatically issue server requests whose replies then trigger more document events and/or updates makes sense. htmx is one way to do this, but probably not the only or best way, but it has the core idea right: generalize hypermedia and extend the event model.
> <button hx-post="/clicked" hx-swap="outerHTML">
how do you feel about the href, method and action attributes in HTML?
And add HTMX as an "extension"
- 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. :)
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."
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?)
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.
If so, is the differentiation then just setting apart HTMX, Vue, etc from JSX and other JS-in-HTML approaches?
Not saying there isn't a blurry line here.
I know this doesn't add to the conversation very well but I just want to throw it out there that htmx is a good replacement for a larger framework that you don't fully understand.
Also shoutout aplineJs for making small JS changes easy.
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 compatibility.
The Javascript/Node ecosystem is terrible for businesses and you're incinerating cash if your company running in the Node/Javascript rat race.
I'm hoping HTMX injects some sanity into frontend development.
https://github.com/bigskysoftware/htmx/blob/v2.0v2.0/www/con...
we will also continue to support htmx 1.0 for the forseeable future for people who need IE support or don't want to upgrade
I have different next projects started at different times and whenever I need to change a single line of text, I have a 50% chance something won't work and I'll have to debug some error coming from the intersection of different versions of node being used in the JAM host. I got hit by OpenSSL issues for a static website. Then a potential solution is to upgrade the framework (next or react) but then you start running into a bunch of other issues and you find yourself 8 hours deep for a copy change.
Performance is also a pain to get right as the abstractions keep piling up and especially the rendering cycle of React is a massive pain. The move from class to functional (for the majority a net positive as the functional version is way more readable and clear) made accessing some hooks harder, so know you need to remember some special rules or functions to call in order to get the behaviour you want.
For all new projects I just use solid.js which is a bit nicer compared to React while keeping most of React syntax. The abstraction layer is much smaller compared to React (no vdom, no custom rendering cycle, your function gets executed once, not once per re-render). You just have to remember you are dealing with Proxy instances and you're good to go.
Somehow I didn't have problems with updates but there is way less activity compared to React. I have some projects from 3 years ago just using solid.js, and a bunch of projects with solid-start. I didn't bother updating them, they keep on running, can't complain.
Using lockfiles and version pinning by default opens you up to all sorts of issues. Breaking changes accumulate, and you'll fall further and further behind, increasing the development effort required to get up to date. If you ever want to use some hot, new library that just dropped with a must-have feature for your project, you're highly likely to run into a conflict that will force you to make all those changes you've been procrastinating. Of course, you'll also find yourself stuck with whatever security vulnerabilities exist in your pinned version of the dependency, to be discovered and exploited at some future date. This is a complete nonstarter in my field of work.
The trap is this: you have a strong need to update a dependency for a bug fix (particularly security fixes), but the update isn't compatible. So you've got no good option: either live with unfixed bugs or pay the price to update your app to the latest version.
There is some wiggle room though. (1) libraries will often maintain a compatible branch for important fixes. (2) you can often find and apply just the fix/fixes you want to your own version of the library. Obviously, you start to lose the benefit of someone else maintaining the library for you, but when you aren't paying for it, you should always understand that is a nice but temporary state of affairs, so enjoy it while it lasts. (Actually, even when you are paying -- maybe even a lot -- you can still get left behind.)
>React - The library for web and native user interfaces
https://react.dev/
https://www.reddit.com/r/reactjs/comments/126uzfo/why_is_rea...
https://medium.com/@Angie.O/why-react-is-a-library-and-not-a...
https://www.oreilly.com/library/view/what-react-is/978149199...
While I generally would also consider React more a library than a framework, I think there are arguments to be made that it's a framework. If we go by the common "your code calls a library; a framework calls your code" distinction, then you definitely have to structure your components in a very specific manner so that the React internals can "call your code" to e.g. render one component from it's parent component.
Compare that to Laravel or anything else that is obviously a framework. You write code and put it in a file in the right place, and it gets picked up automatically, most of the time.
This makes me still consider React a library, rather than a framework. But then there are tons of frameworks that uses React, nextjs is probably one of the more common ones.
Here's my fear of using DSLs like htmx. At first the escape hatch is your friend but eventually the project stops being an htmx project and becomes a "hyperscript" (or equivalent) project. For anything that reaches maturity, you're then left with the painful task of figuring out how to port hyperscript and htmx to react/vue/svelte (the very thing you were trying to avoid in the first place). This is way harder and more painful than using one of these frameworks as a foundation for your project.
What I don't get is why people that harbor this resentment to FE tech, don't just limit their feature usage. Think server components are dumb -- don't use them! Think react hooks are stupid -- write class components! In the event you actually have to do something that requires you to do something outside of your comfort-zone, you just have to push a little bit of your react/vue/svelte knowledge instead of appending more escape hatches to an increasingly bastardized DSL abstraction.
Without question, there's a lower 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 speak. [0]
[0] https://unplannedobsolescence.com/blog/custom-html-has-level...
HTMX is expressive enough for many smaller cases. If your case requires more richness, you can always pick React, Vue, Elm, etc, and be able to do basically anything on the client side.
https://en.wikipedia.org/wiki/Rule_of_least_power
https://blog.jim-nielsen.com/2023/html-web-components/
I don't really understand why people would bother arguing whether htmx is a library or a framework. It's a way of making a web site where you write less JS.
In a nutshell, as defined by the author, a library is a cog which is included by your application and can easily be replaced if it's not being maintained anymore, whereas a framework is the system within which you create your application and switching to a new framework would require essentially rewriting the system (and throwing away what you learnt about how you developed your current app and having to learn the way to develop with the new framework).
Whether you agree with the author's definitions or not is irrelevant to the piece. What is relevant, however, is that one can be far less judicious when including a library, because you can simply replace it in the future, whereas you need to be far more careful when switching to a new framework because it's not as easy to replace.
It bothers me that this point always comes up when a discussion about HTMX arises. For me writing less JS is just a very pleasant side-effect of using HTMX. But the main benefit is just having (nearly) everything in one place (the backend). It is just so much easier to reason about the code.
But the concept is totally different. It uses a hypermedia declarative model, an extended POST/GET etc. model. It keeps things very simple compared to a framework like React where you need a package manager, a transpiler and a json backend for data (not returning hypermedia).
So I would not consider it another Javascript frontend framework at all. I would consider it more like original html with extensions that support Ajax respecting the original web model.
For example, your server returns markup, not Json to a React frontend or similar.
This simplifies things a lot though it also has some disadvantages.
Advantages: if your backend changes the return to extend functionality, the hypermedia will be returned with no required changes on the frontend.
On the other hand, if you want to do a data-based json API htmx is not what you want, because it conflates returning functionality (embedded in the hypermedia) with presentation, instead of returning only data.
I just had this weird flashback to Frontpage...