I like this fuzzy definition better than "your code calls a library; a framework calls your code."
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).
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.
It's more than just a library, there are "starters" that they've developed that will pull in everything you need for certain stuff (such as web, or database, etc), and it will auto-find and configure everything for you.
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.
Some people jokingly call Spring Boot a framework to manage Spring - another framework.
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.
Obviously, you need to start the application somehow. But when you initially setup a rails project, do you write the code that bootstraps the application? Or do you just run `rails server` and the application figures out what to load, and starts the application for you?
But when you initially setup a React project, do you write the code that bootstraps the application? Or do you just run (`pnpm create vite` +) `pnpm run dev` and the application figures out what to load, and starts the application for you?
When you initially setup a React project, you run `npm install --save react react-dom` or similar, create a HTML file that loads a JS file that you also need to write, that includes a call to `ReactDOM.render` somewhere. That's it, no more, no less.
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.
`pnpm create vite` is one of the modern alternatives of `create-react-app`, which isn't maintained anymore.
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).
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'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.
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 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.
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)
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.
So what's the problem with a bundler/transpiler etc?
You set it up once. It takes a few hours, maybe a day. Then your platform _is_ TypeScript + React. This abstraction basically never leaks. I never need to look at the transpiled files to find an error.
Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.
But in the browser the browser interacts with it anyway. It‘s not like the app would run in a repl and now doesn‘t. There is no meaningful difference in this case, even less so if hot reloading is used.
I don't know how build systems work at lower levels, but things move so fast in the web development world that it renders your codebase inoperable if you don't maintain it.
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.
Does the lock file render the need to update dependencies obsolete?
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.
Yeah, just lock your versions without updating in the JS ecosystem with typical projects having thousands of dependencies, and watch your CVE count go up every day you don't update.
Inevitably someone will respond claiming that if you don't like the current ball of duct tape, it is because, "you haven't wrapped this weeks hottest flavor of duct tape as yet another layer on top"
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.
> You set it up once. It takes a few hours, maybe a day.
Until you need to update a dependency on a large codebase, which takes weeks because dependency A doesn't work with dependency B version X, and updating dependency B means that it no longer works with dependency C version Y, and so on. And nobody uses dependency C anymore -- it's unmaintained, so you need to rewrite everything to use dependency D.
Then you need to repeat this every few months because there's nonstop vulnerabilities flagged and APIs broken.
Dependency management is an unrelated issue and it exists for any platform. Unless you copy paste code or unless you just avoid dependencies. Which is easy to do in TypeScript as well. Nobody says you need to install hundreds of packages.
> Nobody says you need to install hundreds of packages.
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.
Agreed! For this reason, we use very few third-party dependencies in our big TS monorepo. NPM is a jungle, and for an experienced team of TS developers, a new dependency just isn't worth the risk -- we'd rather just code things ourselves.
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.
This is exactly what we’re dealing with right now trying to upgrade TypeScript. We’re stuck on an early version of 4.X because of some dependency triangle I haven’t had time to work out.
Hello, I have nearly 10 years of experience dealing with this. Do you need help?
I am sure I could fix it in a few hours - either I fix it within 5 hours or you don't pay anything. My hourly rate is 150 EUR and my email is in my profile.
No disrespect but frankly I don't think you could, I don't think anyone could. It's a giant tangle of grunt and require and special custom build systems.
I am always perplexed by how many people deny the reality of this. Upgrading TypeScript major versions for any package of non-trivial size and dependencies is often (not always, but often) quite difficult! I wrote about that in my last htmx essay.[0]
Seems a bit of an over reaction. Never experienced anything like you say since working with typescript after working on multiple billion+ $ SaaS apps. It’s basically the same as any other language.
Did you not deal with the debacle of js changing imports how imports work? That was absolutely miserable and js libraries have a very short half life indeed. JavaScript's culture of small, relatively short lived libraries makes maintaining a JS app particularly miserable for many (see the comments affirming this misery). It is not anything close to the same.
Yeah, as a full-stack / backend developer using PHP / Symfony (and Twig), I only occasionally need to update the frontend. But then all these problems keep popping up.
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?
One challenge a bundler and transpiler introduce is they enable an unconstrained set of solutions.
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.
For one thing I may have very simple requirements that I don't want to buy into maybe a day long setup for, nor hand write js when html could support it.
- 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
I now prefer using #NoBuild [1] ESM builds of progressive JS FX's for adding behavior to static rendered content where each page only loads the JS it needs, which ends up being much simpler [2] and resolves these issues I used to have with SPAs. Blazor with static rendering and Enhanced Navigation is even nicer which gives SPA-like navigation responsiveness without SPA-like complexity [3].
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.
TypeScript is simply a much more robust type-safe language and the compiler abstracts away subtle differences between browsers. Likewise React abstracts away subtle differences between browsers.
And most applications are far more complex than just needing to update a small part of the page.
They don‘t start if they use complex frameworks, many dependencies, don‘t use lock files, don‘t lock their package manager and don‘t lock nodeJS and don‘t use Docker.
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.
Lockfiles aren't a magic bullet. They point to an a specific old version of all internal dependencies. That still requires the maintainer of each of my dependencies to have published a patch to an OLD version when vulns show up.
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.
Many of these libraries cannot have meaningful vulnerabilities. What‘s a possible vulnerability in lodash that can be exploited without already being able to inject code?
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.
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.
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 prefer to refer to htmx as a "future polyfill". Eventually, htmx semantics will become part of the web standard, and older browsers (or those that choose not to implement the feature) will need this polyfill.
> Eventually, htmx semantics will become part of the web standard
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.
Hadn't considered it before, but thinking about it now, I can see that a brilliant name choice probably played a big role in the traction that it's had.
CoffeeScript inspired ES2015, jQuery inspired querySelector and some other DOM APIs, but none of them would be a usable polyfill, and the standard APIs/syntax is not the same.
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?
Haven't heard of htmx before, but I might use it on a future project if I remember.
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 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.
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.
Timezone support, no date ranges (eg from-to), date formats are a mess (mdn: "At the moment, the best way to deal with dates in forms in a cross-browser way is to have the user enter the day, month, and year in separate controls, or to use a JavaScript library such as jQuery date picker."), often rules are needed (eg only weekdays), non gregorian calendars, ...
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.
The imperative part is required to build a Web Component.
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.
I'd say that it's the other way around, and native elements that are not system-dependent (say, a video player) should lose prominence. There's no reason to have a "native-looking" button on a web page, which otherwise cannot (and should not) be made native-looking.
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.
Which controls stabilized around Bootstrap styles (now there's a a name I haven't heard in a long time)?
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.
You will need to wait another 10-15 years before they overcome the issues that they caused for themselves (while twisting and contorting the platform in unpredictable ways): https://threadreaderapp.com/thread/1717580502280867847
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).
If you're going to get that picky (and please be aware I'm only doing this for the sake of the argument) media can never be hypermedia in the absence of the client. HTML opened in notepad is just text. Cat GIFs, rendered in the correct client, would absolutely be hypermedia (you could inline link data as QR codes, if you felt like being perverse).
Hypermedia starts with the client, not with the file format.
I agree that a hypermedia can't act properly within the uniform interface constraint, without a hypermedia client, that is, you can't have a hypermedia system without a proper hypermedia client:
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.
> 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
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.
Yeah, I went overboard with the example. The issue is that HTMX tries to take over the concept of hypermedia as if it means only HTMX and whatever HTMX is doing :)
Htmx posits that current browsers aren't "truly" hypermedia since only anchor tags and forms can initiate GET/POST requests. It is more of a tech demo showing what client with ANY tag being able to do requests would look like.
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
> The author posits that these features should be 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"
> 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.
Um, yes friend, that’s exactly what it’s trying to be. Carson has said numerous times that in an ideal world, the html spec would evolve to the point the htmx becomes redundant.
It’s not about htmx or any library/framework - it’s about extending html.
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.
At this point you are very loudly and publicly grinding your axe to the point that you’re telling someone to their face that they don’t understand their own viewpoint. Putting aside briefly the insanity and futility of that, it makes for a bad experience for literally everyone else.
OK, this is just completely unreasonable of you. HTML is a natural hypermedia in that it has native hypermedia controls. JSON & XML are not natural hypermedia because they do not, however hypermedia controls can be added on top of them, as in the case of HXML/hyperview, which, again I include in my book on hypermedia systems.
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.
> 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.
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:
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?
yeah, i don't think the htmx API would be the right thing to add to HTML, it's too specific to htmx, but the idea of generalizing hypermedia controls is something i hope the browser people look at
They have, and it failed. "Hypermedia controls" are for machines, first and foremost. That's what RDF and semantic web were supposed to be about, but that never took off in any significant shape or form.
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?
The point of HTMX is that any element can submit HTTP requests, and you can drop the response anywhere in the document. It no longer has to be just <a> and <form> with full page reloads.
It's not different.
The question is if we would have current JS capabilities in the past would we choose adding handling of <form> to HTML or would we say use JS for that. I am not sure what is the right answer but adding features to both sides is probably not a great idea because you just bloat everything.
It's a language paradigm thing. You can implement anything, from HTML to CSS, in pure imperative JS, but the result would be extremely verbose and virtually impossible for machines to interpret on the fly (i.e. little accessibility support).
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>".
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.
> 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.
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?
That's like preventing HTML5 to include a native date picker. Because if you want anything more complex than a basic date picker, then what? Rewrite everything in JavaScript?
htmx is one of those things, like SQLite on the server, that you will incessantly see on HN, but rarely see used at large profitable companies.
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.
This is not necessarily refuting what you said but perhaps a different point of view. I wrote a simple backend servive with go and wanted to have some on off switches and status icons for it. I don't know js and am not interested in learning it. Htmx gave me enough interactivity to put together that one status thing with buttons in a few hours. To me that's valuable.
People use it for the sake of not using JavaScript.
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.
Maybe some people are using it to avoid JS at all costs. I am using it to have everything (validation, authentication) in one place, the backend. It also saves me currently four serialization and deserialization steps, which drastically improved performance. meanwhile there will also be a few 10s or 100s lines of JS to enable some specific behaviour that I do not want to (or would be awkward to) implement in HTMX.
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.
> htmx is one of those things, like SQLite on the server, that you will incessantly see on HN, but rarely see used at large profitable companies.
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 don't understand what you mean. Hotwire uses javascript internally just like htmx does and neither require you to write your own javascript.
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.
Things need time to take hold while people unlearn what they thought was "law". Python had its time of being "the new hipster language" (in whatever disparaging vernacular we used back then, I'm too old to remember)
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.
I did a little POC for myself for an internal app that provides pass-thru access to a menu of tools (most of which are java-based microservices) and I'm using Django templates to deliver content to htmx-controlled slots in the UI. Works great and is very easy, from someone who is not an expert in either tech.
Overall, I have used htmx successfully in several small projects, of varying tech stacks, without much effort at all.
if we go by precedent, every single thing that we were told was good because it was a trend has lasted less than a year and had to revamp and mutate itself out of a supposed position of streamlining and simplicity.
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?"
htmx + kotlinx.html + kotlinjs is an excellent combo that gives you an MPA that looks and feels like a modern webapp, with minimal stack complexity, and fully typesafe/compiled UI code. I'm also layering in tailwind & flowbite. With the hotswapagent project, you get hotswap that works for when you're building out UIs. One day I'll blog about this stack in more detail and post here.
This sounds interesting. Would you be so kind as to explain how to set this up or link to an example?
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 :)
I definitely will post about it, but it's probably a blog length walkthrough :). I have an email notification form on my blog if you want to be notified when I get it done: https://smaller.fish/ (I promise no spam.)
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.
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.
htmx is not a framework, or even library. it's only one implementation of an idea. an idea that needs to be implemented by the browser instead of something external like a js file.
There are simple things it would be nice to do without either 1. A server + framework, 2. A full on SPA, 3. Hand writing tedious js.
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.
Don't get me wrong - I love the idea of an open source project pushing mainstream ideas of how tech should be done, but those projects should be scrutinized and will always need to prove themselves in real world implementations. When that happens, the tech needs to evolve, be well-documented, and well-maintained.
I’ve had a lot of fun building an app with HTMX and Django. Makes things so much easier as I don’t need to use anything other than the standard templating system and still get an SPA-like front-end experience.
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.
Alpine is for client-powered reactivity and HTMX is for server-powered reactivity.
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.
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.
The problem I have with this style of library for frontend dev work is eventually the scope of the problem exceeds what the library is capable of doing. Then you have to embed JS which then gets pretty messy and spaghetti code and enough of this you are right back to where you started setting up a JS build system to make up for the deficiencies. Only now it is worse because you are working around one library and you start fragmenting your app because you started with the wrong thing.
But it is not a given that the scope of the problem eventually exceeds what HTMX is capable of. It is perfectly fine to set HTMX aside and choose another framework if you feel that it better suits the problem at hand. Meanwhile there is still a ton of projects for which HTMX is more than enough (and always will be). So what you are mentioning is not an issue of HTMX, but one of "chosing the right tool for the problem".
That’s fair. I guess my comment was inadvertently responding to another about why you don’t see it at large companies.
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.
Well I would not dare going through the hassle of moving from React to something like HTMX if the former is already well-established in the company, except when everyone is on board. So I totally get that.
317 comments
[ 3.4 ms ] story [ 302 ms ] threadThe 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).
>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.
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).
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...
I think people do still make this argument
Nobody argues that a C compiler is worse than assembly or that drivers or an operating system are bad.
See:
https://htmx.org/essays/no-build-step/
https://dubroy.com/blog/cold-blooded-software/
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.
[0] https://htmx.org/essays/no-build-step/
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.
[1] https://world.hey.com/dhh/you-can-t-get-faster-than-no-build...
[2] https://servicestack.net/posts/javascript
[3] https://servicestack.net/posts/net8-best-blazor
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.
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.
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?
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.
[0] https://www.youtube.com/watch?v=r0XBULqzsT0
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:
https://htmx.org/essays
https://hypermedia.systems
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...
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"
Obviously like any lib it has an API but HTMX doesn't force a project structure to you.
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?"
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 :)
"always has been" ᕦ(̿ ̿ -̿ ̿ )つ/̵͇̿̿/’̿’̿ ̿ ̿̿ ̿̿ ̿̿
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
"a system by which elements enter and exit the DOM via network request."
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.
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
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.
https://htmx.org/essays/hypermedia-friendly-scripting/
https://hypermedia.systems/client-side-scripting/
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.
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.