Is htmx Just Another JavaScript Framework?
htmx.org
htmx.org
The discussion about Library vs. Framework misses the core objective of the HTMX project.
A good date input would cover at least like 80-90% of use cases in my opinion. From experience it's currently more something like ~40% or so.
the beauty of HTML markup is that it's declarative. at least from the tutorials I've seen, WebComponents drag you firmly back into imperative land with document.addChild everywhere.
When you merely import it. you can use it as declaratively as any other HTML tag. Basically Web COmponents allow you to add your own tags that are rendered as components, and freely mix "built-in" and "custom" DOM nodes in your document.
But there is a widespread desire for better native HTML elements.
E.g., a date range input.
Instead I expect the industry to stabilize around a few widespread sets of web components, much like a lot of CSS for controls stabilized around Bootstrap's styles.
No, industry should not and will not stabilize around "few widespread sets". For the simple reason: it's extremely difficult to create a proper userland UI control in the browser. How many custom drop downs fail even the most basic keyboard behaviours? How many custom UI elements fail even the most basic screenreader interactions? etc. etc.
What you really truly need is a rich browser-native set if controls, and https://open-ui.org/ is slowly working towards that.
Related: You can't capture the nuance of my form fields https://web.archive.org/web/20230208235009/https://drewdevau...
On the other hand, now we have auto-playing videos on every other page.
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).
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
It's odd to insist on strict word choice when transferring GIF images using the hypertext transfer protocol.
As such, they're ancillary sub-resources to hypermedia but not themselves hypermedia.
Hypermedia starts with the client, not with the file format.
How you transfer the data is irrelevant BTW. I don't get why you include that in your argument.
https://htmx.org/essays/hypermedia-clients/
https://hypermedia.systems/hypermedia-components/
On the other hand, there is a real difference between plain text and HTML (or HXML, don't shoot!) which is a subset of text with additional concepts layered on top of it. This is akin to how JSON (or XML) is not hypermedia, but can be used to create hypermedia such as Siren or HXML.
So I still think it makes sense to discuss if a media is or is not hypermedia without reference to the client, whereas it doesn't make sense to claim it is being used as hypermedia unless it is being consumed by a properly written hypermedia client. To make my thinking concrete, I believe Siren would continue to be hypermedia, even if it wasn't be consumed properly by a client, but then also you could not describe that pairing as a hypermedia system. (This is one reason I focus on the systemic nature of hypermedia, rather than solely on hypermedia formats)
Semantic nitpicking perhaps, but then hypermedia discussions appear to tend to invite this sort of thing.
So, HTML is different from plain text because it "has concepts layered on top of text" where as JSON is not hypermedia despite "having concepts layered on top of text". And the only reason is because you said so.
> So I still think it makes sense to discuss if a media is or is not hypermedia without reference to the client
Then JSON is just as much hypermedia as HTML. Both are structured text unusable without a specific client to display them or work with them.
> Semantic nitpicking perhaps, but then hypermedia discussions appear to tend to invite this sort of thing.
They only invite them because of your insistence on calling only HTML the "natural hypermedia" etc.
No, the reason is because HTML qua HTML has hypermedia controls and JSON qua JSON does not. Recall that, before I pointed out the widely used and accepted definition of hypermedia controls, and in particular that links and forms are hypermedia controls, you did not understand that concept, so you might spend some time quietly reflecting on that idea. It may help clarify things for you.
> Then JSON is just as much hypermedia as HTML. Both are structured text unusable without a specific client to display them or work with them.
As I have said and written previously (https://htmx.org/essays/hypermedia-clients/, https://hypermedia.systems/hypermedia-components/) I agree that a hypermedia client is necessary for a properly functioning hypermedia system that adheres to the uniform interface. However, I think that there is a good argument that Siren, for example, is hypermedia, even if it isn't being consumed correctly, just as I think HTML is hypermedia, even if someone is screen scraping it (i.e. not using a hypermedia client to consume it).
I don't think you can call those uses a hypermedia system, but I also don't think that changes the fact that the underlying formats, Siren & HTML, are hypermedia, due to the fact that they have hypermedia controls. That might be a subtle distinction, but I think it is a valid one. Again, perhaps as you reflect more on this concept, new to you, of hypermedia controls, the distinction will become easier to understand.
> They only invite them because of your insistence on calling only HTML the "natural hypermedia" etc.
I'm very sorry you that feel that way.
I would call HTML, "a natural hypermedia", rather than "the natural hypermedia". I would also call HXML & Siren natural hypermedia, due to the presence of hypermedia controls (a concept new to you) in their specifications.
But I wouldn't be surprised if there's a crazy project somewhere using GIFs as a way to render HTML pages with clickable links :D
That's why whether it is library/framework is besides the point. The author posits that these features should be in the spec, and tries as closely as possible to show what something might look like if we had it in the spec
Does he? The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. And that's about it. Nothing about "this should be in the spec"
Does he? Evidence or it didn't happen.
If that doesn’t convince you, then I’ve got nothing and suggest we both just go and enjoy some lazer horse/buffalo/pickle memes in the htmx twitter account
Of course you're not. And I already pointed it out to you elsewhere. Your entire writing and marketing revolves around one idea, and one idea only: HTML is "natural hypermedia", and everything else is not.
There are many other hypermedias, such as Siren, which uses JSON as a base, and I have never claimed otherwise. Mark Amundsen, perhaps the worlds expert on hypermedia, wrote the forward to my book, Hypermedia Systems, and found nothing objectionable and much worthwhile in it.
I hate to be rude but you didn't understand, or refused to acknowledge, the basic meaning and usage of the term 'hypermedia control' until I cited a W3C document using it. While I certainly understand people can dislike the conceptual basis of htmx, its admittedly idiosyncratic implementation or the way we talk about it, at this point I have tried to engage you multiple times in good faith here and have been rewarded with baseless accusations of things I haven't said and don't believe.
At this point, to be an honest person, you need to apologize for misrepresenting what I am saying multiple times to other people. It is dishonest and it makes you a liar, over something as dumb as a technical disagreement.
Just because you were correct in one small detail (citing a 2019 standard retrofitting definitions for the use in RDF etc.) doesn't make you correct in the grand scheme of things.
> with baseless accusations of things I haven't said and don't believe.
I literally quoted your own words at you.
> you need to apologize for misrepresenting what I am saying multiple times to other people.
I will not apologize for things that I even quoted from your own writing and words.
the presence of hypermedia controls is a defining characteristic of a hypermedia format
> I literally quoted your own words at you.
You took an essay I wrote in which I defined the term HDA specifically to contrast with the term SPA in the context of web development and spun that into an imagined philosophy where HTML is the only hypermedia in the world. You persisted in this after I pointed out that I included HXML in my book on hypermedia, and gave a clear definition of what I consider the defining characteristics of hypermedia & clarified specific examples of other formats that are hypermedia.
You have confused "X is A" with "Only X is A" and then, when large gaps in your understanding of hypermedia have been brought to your attention, you have dismissed them as small details.
> I will not apologize
I did not expect you to.
At this point I think I have taken goodwill as far as it can go. I encourage any other readers who have made it to this point in this hellthread to simply read my essays & perhaps my book, and judge them on their own merits:
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?
> <button hx-post="/clicked" hx-swap="outerHTML">
There is concrete value in stating unambiguously "this is a <form>" versus "this is a blob of imperative code that I swear acts like a <form>".
how do you feel about the href, method and action attributes 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.
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 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.
Simple answer: yes.
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.
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?)
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.
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 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.
Think about pressing a button that opens a modal with content already delivered by the server (like a settings modal). You don't need to make a HTTP request for that, so you could use Alpine.
Let's say instead that you click a user icon and you want to render a modal that contains user info which hasn't been fetched from the server (because why waste resources loading all this data the user might not see or need?). When clicking that icon, you could use HTMX to fetch the user data from the server then display the resulting content in a modal.
Two different actions with similar visual results (from the user's perspective), but one is all client-side and one requires extra info from the server.
Alpine and HTMX are frequently confused this way, as they solve seemingly similar problems from different ends of the network.
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.
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.
Oh, you're not using Vercel? There's your first mistake \s
Not very common in sane ecosystems.
One big contributor is JS's proclivity to have lots of smaller libraries. This increases the chances of one of the included libraries having a breaking change. Pile ontop of that this insane notion of constant version pinning and "semantic versioning" and you have devs that willy nilly change public facing interfaces.
When you want to use a new feature that's missing in the version you have, you can upgrade, but in general people expect things to stay in future versions.
If you pin to an exact version, and use a lockfile, then you won't ever pull in any updates on `yarn install`, and installing your package in three years will result in downloading the exact same code as it does today. Just make sure you use nvm to pin Node, and corepack to pin your package manager, and you have a fully reproducible build chain as long as the dependencies are not unpublished from npm (which they can't be, after 72 hours of publishing).
The only time it makes sense to use a semver range is in the `peerDependencies` of a published library. Even the `dependencies` of a library should use an exact range. Why? Because firstly, if I'm following best practices, I should be bundling my library before publishing it as a package. And secondly, if that bundle depends on another package, that's okay because npm dependency model allows having multiple copies/versions of the same package. But if it's something like Emotion depending on React, where I only want one copy of the library at runtime, then I should use a peer dependency, and here it does make sense to refer to it with a semver range.
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.
Agreed this is a tradeoff. That's why you need a rigorous auto-update process. Your approach works too, it's just a question of when you want to detect failures caused by an upgrade
Regarding security, you're still vulnerable until you update. In your approach, you couple those updates with ongoing development. But what if nobody's pushed code for a month? You'd probably want automated upgrades, right? So in that case why not pin your dependencies too?
> you're then dependent on those ancient versions remaining available through your usual channels for the unforeseeable future
It's a safe-ish bet that versions will remain available on npm since it's not possible to unpublish a package from there after 72 hours of publishing it.
But you don't need to rely on the registry if you cache your dependencies, and you can take more advanced measures to hold onto that cache. In our codebase we build Docker images from every commit, and for the JS images we store the Yarn cache in a shared Docker layer. This was a bit finicky to get working, but isn't strictly necessary anyway since the final build includes the node_modules too. So we have reproducible builds at the application level, but we also hold onto all versions of Docker images (tagged by commit, and only rebuilt when their source changes), so we have reproducible deployments and - crucially - the ability to rollback to an earlier version without relying on any external dependencies.
This was not an easy system to build, but it's more of a general devops problem than one that's limited to any specific packaging system. Our monorepo includes JS, Python, C, Lua, and a bunch of other languages and packages. I will say that the code for making Python properly reproducible was a lot more complicated (we use Pants and some hackery for generating a locked requirements.txt).
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.)
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
>React - The library for web and native user interfaces
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.
Furthermore, you can hand configure Spring. If anything, the framework here is the Java servlet container, not Spring. Spring just usually lives within that context.
And at this point I'm not sure if that's completely true either. It's common to embed the servlet container - this is how Spring Boot works. I assume you can do that with raw Spring considering that's what Boot does, but I never bothered trying because I would just use Spring Boot at that point.
If having a entrypoint function/object is enough to call something a library then both Spring Boot and Spring are just libraries. But in reality they are not - so entrypoint rule is not correct.
With Rails nothing will happen unless you call `run Rails.application` or run the `rails server` command. That doesn't make it a library.
We can do this all day...
Contrast that with rails where you run `rails new $app`, then `rails server` and everything is made for you.
Not sure why you're mentioning vite here, we're explicitly talking about React and Rails, not wrappers or tooling around them.
It fills the exact same role as `rails new $app` does of scaffolding a project, which apparently is a hallmark of a framework. So where does "wrappers or tooling around them" start and end? Why shouldn't we count `create-react-app` (which was maintained by the React team), but count `rails new`?
All this just goes to show that the "you have to call the entrypoint" distinction you are trying to declare is just as fuzzy as most other library vs. framework definitions.
There is next to no difference in hand-writing an essentially fixed entrypoint of React.render vs. getting that file autogenerated vs. calling a "binary" (that is also just an interpreted script that contains the same entrypoint).
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...
> 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.
And then here you say:
> 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
I wouldn't write a small program in the hx-trigger syntax either (although, we not only have users who do that, but have contributed to hx-trigger optimizations because they use it so heavily).
Many htmx use cases don't need this at all, some need complexity up to this point, some need far more complexity. It's really up to you to decide at what point you bring in the bigger guns—whether that's hx-trigger, alpineJS, hyperscript, or a React Island.
I agree that hx-trigger is a DSL, and represents the outer limits of htmx's expressivity. My objection is to the argument that htmx's attribute design is an expressivity problem, rather than a well-chosen level of abstraction for the types of problems htmx is best suited to solve (see the sibling comment about Rule of Least Power too).
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.
Say, eBPF is prominently not Turing-complete, which allows to guarantee that a eBPF program terminates, and even how soon. Still eBPF is hugely useful in its area.
Or, say, regular expressions are limited to regular languages; in particular, they famously [1] cannot process recursive structures, like trees. Still tools like grep / ag / rg are mightily useful.
Yes, I agree that YAML is underpowered for proper k8s configuration! But it's also too powerful for its own good in other aspects [2]. I wish Google used Dhall [3] or their own purely functional config language (FCL? I already forgot the name) instead of YAML; sadly, they did not.
[1]: https://stackoverflow.com/a/1732454/223424
[2]: https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-fr...
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.
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.
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.
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.
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...
Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.
See:
I've had a codebase that sat for as little as 6 months without me touching it. When I tried to run it again, I ran into so many compatibility issues that I had to tediously copy out all of my code into a new project and then fix the remaining issues with my code itself.
Web dev build systems are dependencies on top of dependencies on top of dependencies, and they're all introducing breaking changes every other week it seems.
Of course not. It just avoids that the build system *automatically* updates X to 1.2.3 and *accidentally* breaks your code. But when it's time to bump the version up a notch, that very fragile equilibrium may suddenly crumble.
Lock files are not a substitute for sane dependency management.
Nobody in their right mind thinks you can change major versions without some elbow grease in any other language.
I have an old project that I didn't touch in more than 5 years. Last week, I decided to give it another spin, and booked the entire afternoon to deal with any issues that may arise from the update process.
It went from Python 3.6 to 3.11, and from Django 2.2 to 4.2. Postgres jumped from 11 to 16! There were 10 other libraries (PIL, ...) that I had to update too.
The only special procedure that I had to do was dumping data from the old database and restoring it from the new one, as recommended by PG when doing major-point updates. (And adding a single line to Django's `settings.py` for the new `CSRF_TRUSTED_ORIGINS`.)
When I typed `docker compose up` on my terminal, the app just run smoothly without as single problem. I even had to check that I didn't invoke the old configuration by mistake.
All in all, the process took me less than 15 minutes.
There's something seriously wrong with modern front end tooling when the norm is downloading hundreds of dependencies to display semi-interactive text in a browser.
I think you mean thousands.
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 to repeat this every few months because there's nonstop vulnerabilities flagged and APIs broken.
Nah, I'm good.
If I need one, I have to get that package's dependencies. People don't choose to say "Damn, I'd really love to have 1800 dependencies!" But if you have 4-5, you automatically get dozens or hundreds out of your control.
Yes, could you build everything yourself by hand? Sure. That's a hard sell to many depts/projects. "This will take 3 weeks to build" vs "This will take 4 minutes to npm install". That 4 minutes is introducing a lot of potential risk and headache and time later, but it's providing immediate relief.
FWIW, "dependency management" is a problem in every platform, but I have nowhere near the same number of issues in the composer/php world (nor previously in the maven/java world) as I do in the npm/js world.
But it is worth emphasizing that NPM really does stand out as a hazard compared to package repositories for other dev ecosystems. I believe that dangers are more common, and unpleasant outcomes can be more severe.
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.
Oh, that's the wrong yarn version. Oh, I thought v3 is the newest? But we still use v1? I used v3 in another project. So I need to install different versions? Ah, then I also need different versions of node? Ah, better to use nvm? Because only later versions have corepack, the experimental but recommended tool?
Or do we change back to npm? And why does an install process change a .lock file?
Person A: "Hey, so I ran bundle update and it's not working."
Person B: "You updated the dependencies? WHY WOULD YOU DO THAT!"
If a particular application has 10 patterns that support all the applications UI interactions, then a simple, constrained solution like htmx that supports those 10 patterns is preferable (to me) than an unconstrained solution like Typescript + React where each developer will likely use their creativity and experience to design slightly or wildly bespoke solutions for each feature.
- Build tools are complex
- Large FX's have 100's of npm dependencies
- Every SPA I've created has suffered from bitrot overtime, including:
- Often breaking changes on upgrade, incompatibility between package versions
- Dependencies/tools/fxs often abandoned, rewritten, replaced, etc
- Constantly wasting time working around issues
- Doesn't scale, the larger the App, the slower initial load and slower the FCP
- Heavy client state and need to manage client routing
[1] https://world.hey.com/dhh/you-can-t-get-faster-than-no-build...
Problem is why do we even need one? All I'm trying to do is for my client code to update a part of the page and not the entire page. Why do I need to even introduce concepts of bundling and transpiling for this pig-headed simple task ?
Further, react has a steep learning curve that a backend person need not be subjected to. And it evolves, so that search-copy-paste phase just never ends.
And then dependencies update. Another comment here details why that is a nightmare.
If you want to feel the pain, search for any react project from 2 years ago on github or even some showhn projects here. Literally none of them even start !
So you see htmx does address a group just like react does. Its a tool and it's great at what it does.
And most applications are far more complex than just needing to update a small part of the page.
If they use plain TypeScript and plain React, have a lock file, lock their package manager version and lock their nodeJS version and optionally ship a sane Docker setup they will certainly run.
It is true that it would be nice to have a single tool that combines a bundler, typescript, linter, prettier, package manager and runtime and have it all configured with reasonable defaults from a single file and not 5 configs. And people have tried this lately, with approaches like deno and bun. But it‘s difficult to get these adopted.
Still, it would be better for someone to take all these tools and freeze them in place or even fork them and then freeze them with only bug fixes coming, rather than throwing out 10 years of progress and going back to something that just doesn‘t work.
And the alternative of typscript + react + nodejs + npm + docker for a damn web based UI is just terrible ! Sorry, no bueno.
I don't want to be at the mercy of all the maintainers of my dependencies. So clearly, I need to cut down on my dependencies. htmx is a great middle ground. Clearly, you can now at least see the appeal of htmx + a backend service for a robust though not fully optimized web based app.
And I can't see the JS ecosystem's last 10 years as outright "progress", but rather a series of experiments, that work for some and don't for others.
Furthermore, any vulnerability in a dependency could also exist in code written by myself or a team member. And then never get fixed or even found.
I actually did laugh out loud.
Even then, most of the times it doesn't take even an hour because majority of people will grab default config or use something that allows no-config (parcel, vite, etc)... Some are fine with default CRA for a long time until they really need something custom, for example.
Why do you think that will be the case?
I'm not aware of any effort being made to evolve htmx into a web standard (either by introduction into existing specifications or direct adoption by browser), so this is about as baseless of a claim as someone saying "I see JQuery as a future polyfill" in ~2006.
It may be aspirational on my part, but I do hope that HTML can evolve. JQuery isn't a good analogy as it's not extending HTML.
https://htmx.org/posts/2020-5-17-kutty-er-htmx-0-0-3-is-rele...
better to be lucky than good, I guess
thankfully the fates conspired to force my hand
Apart from that, I'm not sure if I even agree with the point as a metaphor.
Some parts of htmx would make it easier to implement a form submit confirmation message or similar stuff.
everything else is either better served fully server-side or needs heavier client JS.
E.g. ajax pagination is useless without routing... well maybe I need to try htmx more thorougly to understand this stance. right now I don't.
it's not hard to do a fetch request and set innerHTML on an element, right?
He talked about this idea quite a bit, I love the idea of giving backend developers more control over the UI without resorting to huge JS frameworks
It’s a shame htmx wasn’t invented 10 years ago, but it makes sense that it’s bursting onto the scene now as a reaction to end-stage SPA mania.
If htmx-like functionality gets rolled into browsers with native optimizations (i.e. faster than the Virtual DOMs and custom JS runtimes of SPA frameworks, not to mention the no-build-step benefits we’re already seeing with htmx), then it hopefully won’t be just htmx that will get rendered obsolete; Angular, Ember, React, Svelte, Vue, etc. need to go even more urgently.
Pardon my enthusiasm, I really am looking forward to an HTML Renaissance.
I do have experience with plain kotlin but googling yielded not many results on how to integrate all these components you mentioned into a basic MPA. So - blog post encouraged :)
One team at my company wanted to use HTMX and write the product with it and then the PM kept asking for features to bring it to parity with the rest of the application with regards to client side behavior and things devolved. They used hyperscript and eventually the frontend was just rewritten to be react.
Once you go from simple route->page mapping to heavy HTMX usage, you now have routes that are implicitly dependent on other routes to work properly. "/users/42/" relies on hx-post="/users/42/send-email", and so on. Are there ways to model that dependency graph outside of your brain, say an IDE plugin.
Obviously like any lib it has an API but HTMX doesn't force a project structure to you.
Like any library, it has a bunch of functions available to use. The difference, however, is that you don't use them directly. You are just writing html with htmx tags, etc.. and letting htmx, the library, do the rest.
This is it for the most part - but I understand some complications could break that rule. I doubt it would be that often if at all.
This excellent essay overlooked a '*':
* unless you are using bash + jq for your backend, in which case, JSON-formatted form bodies are quite reasonable.
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 :)
There is a nice sweet spot for htmx here; whether it can build the required network effect is another story, and not always reflective of the quality of the idea.
I think htmx is doing an admirable job so far.
When you do that, you'll see the point of htmx.
HTMX is basically a backend agnostic Hotwire, which is the direction RoR has gone
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 additional cost by simply continuing to use React (or others), why wouldn't you?
Edit: As a side note, I have never used any large JS framework, only HTMX. Just trying to put myself in the shoes of happy React users and such.
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 projects that do these things better, with less pretentiousness: Phoenix Liveview or Laravel LiveWire, or even Hotwire
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
Oh, they are not. They are more powerful, but they use rather simple concepts. Speaking as the user of Phoenix LiveView who even created his own templating library to work with it.
> htmx generalizes the standard hypermedia controls found in HTML: anchors & forms
Those are not "hypermedia controls". As I said elsewhere: stop appropriating concepts for your benefit.
> the basic ideas of HTML
The "basic idea of HTML" is "render a text page with a few images in one rendering pass with links to other such documents". That is it.
You are perhaps referring to the hypertext vision of Sir Tim Berners-Lee, but that is as far removed from HTMX as HTMX is removed from any other concepts it keeps trying to appropriate.
HTMX is a utility lib with a few diffing utilities that does what nearly every other library does, but chose the high ground of "we're doing it with HTML chunks, so we're better and this is what the founders envisioned".
You're not better. This is not what founders envisioned.
What would you call links & forms? The W3C seems to agree w/my language:
https://www.w3.org/2019/wot/hypermedia
"This document introduces an ontology for links and forms, the main hypermedia controls in use on the Web."
> The "basic idea of HTML" is "render a text page with a few images in one rendering pass with links to other such documents". That is it.
I don't know about that. What about forms? And script tags. And all the other stuff?
> You're not better. This is not what founders envisioned.
I don't claim to be better, i don't know what that means in this context. I'm trying to generalize what I understand to be hypermedia controls (links & forms) in HTML, in a way that conforms to Roy Fielding's definitions of the uniform interface.
I don't understand the hostility here. htmx isn't perfect or some sort of amazing piece of software, it's a flawed implementation by a flawed human of a perhaps flawed idea of generalizing hypermedia controls. But it's not obviously terrible either: people are having success using it, as a quick cruise around the other comments in this thread would indicate.
Ah. Interesting. I stand corrected. Skimming through the document it looks like a very late retrofit and attempt at standardization for some parts of the w3c tech stack like RDF, web of things etc.
> What about forms? And script tags. And all the other stuff?
None of them existed in the "basic idea of HTML". "All the other stuff" accumulated over the years. Until early 2002 the whole idea was still to lay out the page in one rendering pass (and this was only changed IIRC sometime in 2001-2002 with optimisations for tables).
> I'm trying to generalize what I understand to be hypermedia controls (links & forms) in HTML, in a way that conforms to Roy Fielding's definitions of the uniform interface.
No, you're appropriating the definition, contorting it to pretend that it only means HTML as extended by HTMX, e.g. this [0]:
--- start quote ---
The Hypermedia Driven Application (HDA) architecture...
- An HDA uses declarative, HTML-embedded syntax rather than imperative scripting to achieve better front-end interactivity
- An HDA interacts with the server in terms of hypermedia (i.e. HTML) rather than a non-hypermedia format (e.g. JSON)
--- end quote ---
Nope. JSON (or literally anything else) can also be hypermedia as long as there's a client which can understand it and present it to the user, and can follow links etc.
> I don't understand the hostility here.
I'm just getting tired of people hijacking specific terms to suit their own narrow definitions (however many hoops they have to jump through to get there), and present these narrow contorted definitions as the only true way.
> None of them existed in the "basic idea of HTML".
Well, the form tag was introduced in HTML 2, which was in some ways the first "standard" for it, so relatively early in the game:
After the HTML and HTML+ drafts expired in early 1994, the IETF created an HTML Working Group. In 1995, this working group completed "HTML 2.0", the first HTML specification intended to be treated as a standard against which future implementations should be based.
But I can see what you mean and arguing over the meaning of "basic" isn't a hill I'm particularly interested in dying on.
> No, you're appropriating the definition, contorting it to pretend that it only means HTML as extended by HTMX, e.g. this
That's my definition of a Hypermedia-Driven Application, a term I made up to contrast with SPAs. I agree with you that a hypermedia can be imposed on top of JSON, which does not have native hypermedia controls, but I hope you can agree that this is not the way it is typically used today, and I also hope that most readers would understand that. I think the level of detail is appropriate for a high-level introduction to a concept that I created, but I see your point.
XML is another example of something that is not a natural hypermedia, but I included https://hyperview.org in the https://hypermedia.systems book, so I hope that demonstrates that I'm not wedded to the idea of HTML being the only hypermedia in the world.
I also agree entirely that a proper hypermedia client is crucial for a properly functioning hypermedia system:
https://htmx.org/essays/hypermedia-clients/
> I'm just getting tired of people hijacking specific terms to suit their own narrow definitions (however many hoops they have to jump through to get there), and present these narrow contorted definitions as the only true way.
I don't know, I think we agree I am using the term "hypermedia controls" properly, and I don't know if you have different feelings around my idea of generalizing them in HTML, given that fact. Does that change anything for you?
I certainly don't feel htmx is the only true way. I have never said that, and I try to be explicit when the hypermedia-based approach will be effective and when it won't here:
There's no contrast. It's not even a made up term. I was doing "hypermedia-driven applications" with HATEOAS in 2012.
> I agree with you that a hypermedia can be imposed on top of JSON, which does not have native hypermedia controls
The way you extend browser behaviour with Javascript to use non-standard attributes, non-standard headers etc. is literally no different from literally any other lib/framework doing the same with literally any other format.
> XML is another example of something that is not a natural hypermedia
There it goes again. "Natural hypermedia".
There's no such thing as "natural hypermedia". You're inventing stuff as you go along to try and contort terms and concepts to fit the extremely narrow definition of "hypermedia is HTML with HTMX attached to it".
It's not.
> if you have different feelings around my idea of generalizing them in HTML,
You're not "generalising them in HTML". You're literally, and I quoted, pretending that hypermedia is HTML, and HTML only (with HTMX sprinkled on top).
> I certainly don't feel htmx is the only true way. I have never said that
--- start quote ---
An HDA uses declarative, HTML-embedded syntax rather than imperative scripting to achieve better front-end interactivity
An HDA interacts with the server in terms of hypermedia (i.e. HTML) rather than a non-hypermedia format (e.g. JSON)
--- end quote ---
Literally here: you claim that hypermedia apps are is only based HTML, only use HTML-based syntax and only use HTML to communicate. Because "other formats are not hypermedia". That is, you literally claim that HTMX is the only true hypermedia driven app or something.
Also, elsewhere someone put it even more succinctly: https://news.ycombinator.com/item?id=38965060
The term HDA, which I coined and, therefore, feel like I have some ability to define, was created to contrast with the familiar SPA/Single Page Application acronym, which is a term used in web development. This is why I focus on the web with that article.
As I have repeated incessantly with you, I included HXML, a mobile hypermedia from the https://hyperview.org project, in my book on hypermedia systems, and I hope this indicates to a fair minded 3rd person (I have given up on you acknowledging my plain language here) that I do not believe that HTML is the only hypermedia in the world.
They don't.
> that I do not believe that HTML is the only hypermedia in the world.
For a person who doesn't believe that you sure spend a lot of time only talking about HTML and claiming that nothing else is hypermedia.
And yes, I've quoted what you yourself say about this.
I want a banana and you suggest these jungles. Thanks but no thanks, I'd rather try HTMX which is a library not a framework.
Typescript is popular because people don’t use it a lot, and it doesn’t break things.
If you’re introducing something new the bar is incredibly high to be obvious as to why to switch.
At least where I worked there was often a frontend vs backend divide where some devs would write backend logic, and some others would worry only about consuming backend APIs to get the UI to do certain thing. The APIs is the contract and interface between the two sides and a natural place to divide responsibilities.
Now, with HTMX, the divide is gone. The backend generates and swaps the parts of the UI, effectively driving the UI/UX directly. This cuts tons of JS out of the picture and couples (not necessarily in a bad way) backend and frontend.
If you look at a popular YT video: https://www.youtube.com/watch?v=3GObi93tjZI , the result of HTMX rewrite was "JS guy left".
So in larger teams switching from something like React to HTMX largely turns everything upside down, not just on technical level but on how people work and collaborate.
It would be far easier for new teams and projects to go HTMX route, where they can start and keep hiring people who are fine in a new model.
Yes, because of HTMX the backend is different than it would be with “plain” HTML or the JS framework du jour. But, the backend is very simple and clean, so I agree it has a nice influence whatever y’all decide to call it.
htmx triggered that random memory, and then a flood of others, like:
the gold rush of people, sometimes kids, renting servers or colocating space, installing cpanel, and starting a shared hosting company
dreamhost, remember dreamhost?
vps hosting providers that offered emulated systems, before public cloud was a thing, before vmware or hypervisor OSs, before kvm, or virtualization in general
webmin/virtualmin (which is still going strong it seems)
turnkeylinux (which is also still going strong)
linux from scratch
macromedia
betaarchive.com
Chris Pirillo
- We don't hire full-stack developers. Our UI/UX designers and web developers fully focus on the front-end (responsive for mobile/tablet/desktop, A/B testing, quick iterations of UI/UX enhancements) without bothering about the backend. The backend API developers focus on API returning the right data and don't care about UI. I like this separation as it helps to really iterate the UI/UX faster. With HTMX, those backend devs will now have to worry about returning the correct HTML fragment based on the client device, position of the HTML div, etc. The presentation concerns spill over to backend developer and we are back to the days of server-side templates like JSP/ASP/RoR/PHP/Django. Anyone else sees issue with this approach?
- React/similar web apps can handle quite complex UI with multiple flows and navigations. I assume HTMX is probably not suited for complex UIs. Is that right? has anyone built any complex UI with HTMX?
Here is an example of a fairly sophisticated application that was written in react, then moved to htmx with good results:
https://htmx.org/essays/a-real-world-react-to-htmx-port/
As far as what you can achieve with htmx, I outline when hypermedia (the more general concept behind htmx) is a good choice or a bad choice here:
https://htmx.org/essays/when-to-use-hypermedia/
You can get an idea of the basic level of interactivity you can achieve with htmx by looking at the examples:
all of which compose well together. You can get more dynamic than that if you are willing to do client-side scripting (https://htmx.org/essays/hypermedia-friendly-scripting/)
another essay that might be of interest, regarding your APIs:
https://htmx.org/essays/splitting-your-apis/
and, if you want a complete introduction and overview of the hypermedia approach, we have a book available online for free:
You can get fancier for internal pages that aren't public facing, the search bar, etc.
Also consider the preload extension for faster nav:
The sweet spot for HTMX I've found involves liberally using the hx-boost attribute enhance links and forms that already work without JavaScript. You definitely sacrifice some of the expressivity of HTMX, but you also get a website that is much less coupled to the (library|framework).
Also the constant use of pretentious memes on the official blog. But otherwise, I'm looking forward to trying it out for my next pet project.
You can use React with any backend.
A React app can live entirely in an .html file.
When coding to do that it felt like a library and not a framework and provides a lot of flexibility in design options.
And I agree that the backend should do as much HTML as possible but some times you still need to do things with js. Bu again the backend can send the html plus the bits of js specific for that UI screen or component and that's super flexible and efficient if you keep it properly factored and with nice separation of concerns.
Here is a talk where I've made the case for a particular stack and demoed it last November in the Smalltalks 2023 conference https://www.youtube.com/watch?v=4_gmvN0pimI
This is a nice thought, but I suspect hardly anyone who uses a framework or library really understands it, or makes the commitment to try.
Obviously, a subset of really talented users eventually learn to understand the framework, but most are at its mercy.
Even then, you can't study every possible framework before choosing one to master - there are too many, and the cost of understanding the foreign code is simply too high.
So I suspect that in general, people try frameworks by taking a leap of faith, and then, sometimes, make the effort to actually understand it later - if and when it becomes necessary.
Obviously you benefit from understanding the internals too, but realistically, the more complicated the thing you're using, the less of the internals even a motivated user is going to bother with.
This is a problem that grows with a large library...An api change has a higher cost than with a smaller library. Smaller libraries also tend to be easier to fully understand. Large libraries tend to be more of a "leap of faith" than small libraries.
I think people do still make this argument
You have to learn not 1 but 2 new "languages" hypermedia queries and htmx special html attributes.
And what do you receive in return? Nothing that can't be done with other JS frameworks or libraries. Yes, htmx is JS.
That HN people fall for this trick is no surprise as it's frequented mostly by booksmart idiots.
I will say that in the web dev world I'm a whole lot less worried about definitions than I am trying to figure out what library or framework works for given use cases, what its benefits are ... and where it stops being helpful.
That's not information that is nearly as easy to write though and sadly seems to just take trial and error by each individual.
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 components).
Embrace CRDTs.
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
seems more like a successful escape hatch. yes it's simpler, but it's antithetical to the goal.
it seems to have been fairly successful to me
i think you are associating 'distributed' w/peer-to-peer models, whereas i'm using it in the broader sense of networked software that can interact (link) to one another
i have no beef w/ peer-to-peer and it would be interesting to think about how hypermedia could layer on top of that model, but i'm not an expert on that sort of stuff so I can't have particularly informed opinions on it
As somebody who is not a frontend engineer, but still likes to make a website every now and then. I haven't found a full framework (vue, react, etc.) that I've been able to go full into and still use jquery and writing plain css/html.
Htmx looks like a slight feature upgrade to jquery that I enjoy.
HTMX is different and incorporates some old JSF-like ideas, which makes it feel fresh for some developers, especially those who don't really want to learn React, Angular, Vue, and others.
"always has been" ᕦ(̿ ̿ -̿ ̿ )つ/̵͇̿̿/’̿’̿ ̿ ̿̿ ̿̿ ̿̿
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 it for the sake of using it.
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 of client-side JavaScript for unavoidable things like showing/hiding elements. Of course even for this, 10 lines of CSS is preferable to 1 line of JS.
They’ll foot-gun as much client-side stuff into the back end as possible.
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.
This is true. However:
> Say you use python and Django. Why use htmx instead of Django templates?
This doesn't make sense and makes me think you might be confused about what htmx is. The purpose of htmx is precisely so you can just use things like django and render pages on the server but still make a website feel more like a modern website by replacing elements without having everything require a whole page reload and without having to write your own javascript code.
That said, I personally think there are reasons why approaches like what htmx does fell out of favor.
I'm not aware of django including a similar library, so if you want to take this approach with django I think you need to use htmx, but my impression is that hotwire and htmx are fairly equivalent.
HTMX is meant to be used WITH backend framework templates. The point of HTMX is it allows you to use your backend templating system to return pieces of HTML instead of JSON.
We are using it at our org for our intranet applications and it's been great so far.
Overall, I have used htmx successfully in several small projects, of varying tech stacks, without much effort at all.
A lot of the supposed positives of certain "technologies" that we were told were key factors to embrace several tech have been proven to be false, and yet the cultists of the endless rotation of frameworks want us to stop listening to anyone asking "huh, isn't this like... super dumb?"
This is false. All of those proprietary custom attributes mean it's for writing htmx, not HTML.
If anything, JSX is closer to HTML and htmx is.
"a system by which elements enter and exit the DOM via network request."
What is the core thing(s) I should be appreciating about HTMx?
I'm one of them. Really proud!
It's a framework.
We define "tools" to add/remove behavior to/from existing elements. The tools are added by an HTML5-compliant microformat. For example:
<div class="Q_tool Q_columns_tool">
<form class="Q_tool Q_form_tool">
</form>
</div>
event.set(handler, tool); // no need to remove it later
<div class='Q_tool Streams_chat_tool
Streams_mentions_chat tool
Media_call_chat_tool
any_normal_classes_too'
data-streams-chat='{"
publisherId": "abcjwuqk",
"streamName": "..."
}'
data-media-call-chat='{
"livestream": {
"private": true,
"max": 3
}
}'
some-other-attributes="" >
elements may be empty or have some existing content
</div>
<ul>
{{#each list}}
<li>{{tool "Streams/chat" publisherId="abc" streamName="..."}}</li>
{{/each}}
</ul>
Q.Tool.prepare(someElement, "Streams/chat", options);
or
div = Q.Tool.prepare('div', "Streams/chat", options);
You can see it in action for example at https://intercoin.app
PS: I used to originally call it the "Q" Framework but because of people on HN constantly complaining that it was conflicting with the "excellent Q library for promises", I finally relented and called it "Qbix Platform"... now the Q library for promises is obsolete but we still call it Qbix... so maybe it's better for SEO though? https://news.ycombinator.com/item?id=6053211