Htmx is part of the GitHub Accelerator(htmx.org) |
Htmx is part of the GitHub Accelerator(htmx.org) |
I have to assume that just like most web apps don’t need aggressive SPA front ends, many mobile apps fall in the same boat…
When accounting for the limited amount of time and mental load people have, wouldn't the best bang for your buck be doing react/vue/js?
HTMX is more limited, but also _radically_ simpler to modern frontend development.
Not that the comments are “wrong” but it feels slightly contradictory, in a way.
It's not a startup accelerator - it's a part of GitHub's efforts to support open source projects with funding and mentorship.
I've gone to the home page it poorly explains what it is and doesn't say why would you want to use something like this.
Seems like another distraction.
Seems clear to me but I've been watching this project grow for a few years now. If you read the brief introduction, motivation, and quick start on the homepage what do you think the project does?
> why would you want to use something like this
I would agree that part wasn't clear to me either, at least not right away. When compared to something like a SPA the state has to persist on the server while an ephemeral state exists on the client. With HTMX the state only needs to exist on the server. If this sounds like the MPAs of yesteryear, it is. You render the HTML using the frameworks/tools/languages you fancy. HTMX provides custom attributes you can use to update content within a page without having to reload the entire page.
Is this HATEOAS?
It adds some special attributes to HTML that magically perform some logic and it is not clear how and why. Why would I use something like this over React? What this thing is trying to solve?
> You render the HTML using the frameworks/tools/languages you fancy. HTMX provides custom attributes you can use to update content within a page without having to reload the entire page.
I still can't see what's the point of it. Why would I want to do it?
There's a stable implementation for PHP too.
No frontend developer that cares about the details, the UX and has to deal with the evolution and maintenance of any non trivial UI would use this.
But as I said, this is great for everyone that just wants to make a frontend for their Go/Django/Clojure/etc backend. You’ll notice this pattern in most positive comments you see here.
Also, as someone who also used these kind of tools, I still prefer Unpoly over it. Sadly it didn’t get as much marketing.
Project is really cool, I'm itching to use it in the right side project.
Congrats on shipping !
Oh yea the https://htmx.org/essays as the author mentioned is also fantastic. Their twitter is "fun" :D
I would expect it to be "done", or maybe could be refined with a couple more little things, but definitely not needing full-time dedication on making a version 2.0 or adding new features.
Aren't we going to end up with a new react?
the 2.0 would drop IE support, remove the older SSE and WebSocket support, and switch a couple of defaults (e.g, using template wrapping for parsing partial content, which handles troublesome elements like table rows better, but isn't available in IE) so it would be a breaking change (not for most folks, but still, breaking for some) which I only like to do w/ major versions.
we may have one major addition: a morph swap based on idiomorph:
https://github.com/bigskysoftware/idiomorph/
i'm on the fence on that one: it is currently available as an extension and maybe doesn't belong in the core, still thinking about it
so, in comparison with most libraries, 2.0 is going to be very minor
https://github.com/jperla/pebbles
Later when I worked at Facebook I saw that someone later made a similar library internally.
Solution 3 gave me a good laugh though.
- Rails
- AdonisJs
- ASP.NET Core
- CakePHP
- CanJS
- Clojure
- CodeIgniter4
- ColdBox
- Django
- Go
- Masonite
- Mithril.js
- Node.js
- Phoenix
- PSR-15
- Statamic
- Symfony
- WordPress
- Yii2
- Flask
A sense a lot of familiarity
Very refreshing and extremely productive! Goland, browser window and Bard for code snippets and from idea to first working flow in less than an hour!
With other frameworks I would first have to struggle for a day or two setting up the tooling and understand all of the new concepts and constructs. Or worse, learn completely new language (Flutter, Typescript)
Thanks @recursivedoubts and team!
What am I missing?
This is a complete non-issue in unpoly as you can have multiple targets:
<a href="/posts/5" up-target=".content, .unread-count">Read post</a>
HTMX gets a lot of attention, but I think it's not the best option in its field.
I've done tabbed UIs that worked like HTMX. But instead of trying to do div surgery it replaced the entire tab. It was like 20 lines of JS and a few lines in Rails to render without a layout based on a URL query param.
When we're talking dozens of KBs of HTML for a tab it's not the extra complexity to try and slim that down.
Of course the downside is everything must go to the server. While not perfect, many spa also do not work nicely without a connection, although they could.
Another thing is that the templates can get a bit crazy quick.
I found a good solution is to use swap-oop (https://htmx.org/attributes/hx-swap-oob/) for everything and have a "component" wrapper server-side to abstract the ids and which template to choose.
Then, some kind of typed data structure tracking all the element ids, since you need to refer to them from the templates to know which element to update. This way you can easily find all the templates that update a specific id or all the ids that are updated by a template.
Also, no compilation step, so no need for npm, etc
Exactly. It can serve HTML partials, or utilize `hx-select` attribute to extract required elements from a full page
> Is there a simple example of a static site using Htmx somewhere?
Not that I'm aware of unfortunately
Counterpoint: a majority of websites are for business where they want the form to submit and update the database.
And to me, pretty = CSS + removing full refreshes, which is what HTMX does.
It depends on how you like to build projects. If you like the current state of client-side rendering there is no point to using HTMX. If you like server-side rendering (my personal preference) then HTMX fills the gap of doing partial DOM updates without needing to reload the entire page. Some people will argue about perf metrics until they're blue in the face. I mostly rely on personal preferences.
Right, which you can achieve by replacing the main content div. HTMX takes it many steps further and allows you to slice the HTML up into small bits and replace only those. This adds a lot of complexity for little benefit.
It would be interesting to see how it’s been working out for folks.
Your frontend makes a request to your server, the expectation is that will respond with html.
If you have other services you need to bring in to the mix that responds with JSON then make the request to them from your server, have that parse the JSON in to HTML (most likely some kind of templating system like handlebars) and then send that back to your frontend as html for htmx to handle.
Or am I missing something?
[0] https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
htmx might be great for server side rendering, but for client-side-rendering(SPA) which consumes json data from the backend, I doubt htmx is a good fit, and there are lots of json-api-service(instead of html) these days for client to consume.
the original version of htmx was intercooler.js:
released in 2013, and that version depended on jQuery
Could you elaborate?
We used it in a project and it worked perfectly. If you have the need to write a lot of logic and changing of most of the UI parts dynamically on the page then React/Vue/Svelte/Angular is better suited. If you on the other hand has page that could be server rendered and some parts or lists that should load new parts into the page this may be the easiest way to do that.
You can also combine it with any backend language instead of us having one framework for C#, one for Java, one for Go and so on. I think this is one of the biggest USPs for Htmx.
Angular and React started this way on the frontend, while ASP and PHP started this way on the backend (of course eventually they all grow "full-stack" solutions).
EDIT: And how could I forget, Tailwind, whose tagline reads: "Rapidly build modern websites without ever leaving your HTML"
The fact your HTML barely reads like HTML after Tailwind, and reads more like your file is corrupted is I guess not mentioned in the tagline.
> looking for a nice framework for website
> ask dev if their framework is hypermedia or javascript
> doesn't understand, pull out long essay on hypermedia as the engine of application state
> dev laughs and says "its a good framework sir"
> check github
> its javascriptHtmx is JS in string.
Goodluck stringify :))
It’s extending html to make the most of http by adding some simple attributes.
Like all great things - the building blocks are simple, but the possibilities of what you can build with them is vast.
I think this is really well dealt with in the “opportunities” to extend html in this chapter of the Hypermedia Systems book: https://hypermedia.systems/extending-html-as-hypermedia/
Not my experience for the record. I use Tailwind in my side project, and it is exactly as convenient as it sounds to write my styles directly into HTML rather than think of a class name, add it in HTML, switch to the proper CSS file (or create it if it doesn't exist and make sure it's part of the build step), forget what name I had decided on, check the original HTML to remember the name, then go back to the CSS file and write the class name and then finally within that block add my style.
I think you’re talking about just serving a .html file for every page in a site right? Having all of your styles duplicated everywhere would be much more confusing than writing CSS (and having to invent one name per groups of common things.)
IMO it’s only viable if you can create your own components. Which you will also have to give a name.
> forget what name I had decided on
I think that's not the problem with CSS, but with how you approach design. If you treat your design process as editing a document, and just want to "Ctrl+B" to bold necessary parts, yes, I'm sure Tailwind's better. But, I can see how it could be a problem with maintenance and collaboration as there isn't an agreed upon design language or a document structure.
I understand that managing multiple files and going back and forth can be considered an overhead, but that's a componentization problem, not a problem with CSS per se, and you expect to recuperate your losses with the time you gained when finding and fixing bugs. Otherwise, there's no point in componentization. You'd have the same tradeoff when writing JavaScript code, for example.
You'd encounter the same set of problems the moment you start refactoring your styles into Tailwind components.
Circa 2007 or so it seemed a to be a huge mistake because it didn’t play well with the so-called “model-view-controller” paradigm where, most importantly, the request handler could decide which view to render. (e.g. you fill out a form and if you mad a mistake it redraws the form with an error message, otherwise it might render one of several different forms depending on what you filled out on the first form.)
He thing about HTMX is that it really wants support on the server side. For instance, you might have a <select> that gets drawn as part of an HTML page or that gets updated with new <option>(s) via HTMX when you push a button. Similarly you might have a form that can be rendered as the only form on a page or that can be rendered as a modal dialog that is pulled from the server when you open the modal (as opposed to unhiding it.). Either way the code that draws the HTML fragment (both the template and any database fetching/thinking) has to be runnable in more than one context. (Modal dialogs are so fun to implement with HTMX.)
It’s something you can do in a situational way or that you could have a framework to help with, but it is part of the HTMX puzzle.
I remember having the server render js multi-dimensional arrays consisting of key and html snippet that client js could reference to do html manipulation more quickly.
Good times.
Imagine what everyone was saying about spaghetti PHP intermixed with HTML - but with 2 backend languages plus HTML and CSS, at least that was early enough that clientside JS was limited to changing images on hover...
I can say I migrated away and mostly separated render/js/backend with ASHX handlers until MVC took hold. These days, I tend to prefer the modern SPA models for browser applications. Though will also use static generators, server generation or other techniques if you don't need an interactive application.
HTMX seems pretty interresting as a kind of in-between, closer to the ASP.Net Webforms without the complete excessive overhead in the box.
I'm sure it's the matter of time for isomorphic HTMX-based frameworks... but they won't degrade gracefully. but then they will, as a new feature. the circle of life!
I still have hope that frontend will eventually turn back to web components now that HTML templates, Custom Elements, Shadow DOM, and ES Modules are fully adopted. One of the problems is that this stack is foreign even to professional web devs that hail from React land. It's weird because it's native browser tech adopted by the W3C and painstakingly built into the browsers. Maybe it picks up after someone rewrites the react-dom internals to support web components and adds a new tooling layer over it?
It's not bad tech and web components are built into the platform of the web now so they're not really going anywhere...
So many web revolutions touted as "don't use Java and all that big stack, instead use our SUPER SIMPLE stack called:"
Rails: wow did rails eventually encompass a massive stack of dizzying extensions options and frameworks.
React: I laughed when I saw basically a full rewrite of various Java unit testing frameworks in javascript.
But HTMX seems to get love that angular/react/etc never got from a HN front page perspective.
I take a dim view of AI so far, but one thing it could be fantastic for is "take this basic HTML application and write it in framework X" so I can finally see a good comparision.
The web framework landscape has needed a "reference web app" since the year 2000 where frameworks could demonstrate their way of doing rendering, layout, validation, forms, routing, error handling, data binding / data retrieval, tables/grids, media. As in your web framework isn't even close to prime time unless you can show WHY it is novel or useful.
Why?
Can't run java in a browser. (And don't bring up applets.)
I suppose you could keep most of a testing framework as Java code, and adapt the rest for testing javascript, but that seems fussy enough for a rewrite to makes sense.
Edit: Okay, if people are going to downvote, then I'll elaborate. I understand amusement in people moving from one server language to another, only to recreate the same things they already had, because they could have just stuck with the original. But you can't just stick with a server language when you're writing an interactive web page. Trying to port the tools you like is making the best of the situation, not creating work out of nothing.
There are a ton of ways to solve this issue but most people just look at tailwind on the surface and go shitpost about it on social media.
Its the equivalent of saying "I wrote this 2k line program in one file, its so bad and disorganized <insert language here> is bad!"
Look at this here and the ridiculous extent they insist on "NO, YOU MUST COPY AND PASTE ZEH STYLES!": https://tailwindcss.com/docs/reusing-styles
It's rampant dysfunction on full display, my friend. It's as clear as daylight. Copy/paste is the rookie approach, and Tailwind targets rookies. So it focuses on "it's not your fault, copy paste is good, they... they don't get you" approach and then throw @apply in there as some half-baked solution for those who are starting to wake up from the Matrix.
You are in an abusive relationship. Seek counsel.
Huh? I am not sure what you mean here. Tailwind generates css that is completely explorable in any browser dev tooling. Its precedence is the order of the css classes just like any other css class.
You can solve class overload by just making components. Create a Button component one time, have it contain the tailwind classes you want, and then all through your app, just call your Button component and never think about it again.
You can also just define custom tailwind classes in the config you want to do something really specific or crazy.
If that is too much work you can use Daisy UI which is just a tailwind plugin and it creates a ton of classes that essentially compress tailwind classes down to manageable chunks if you are fine with Daisy's style.
const $ = document.querySelector.bind(document)
const $$ = document.querySelectorAll.bind(document)https://api.jquery.com/category/ajax/
Have you seriously looked at this and thought "yeah thats better than using a single native function (fetch)"?
As for the rest of the API - what would you even use besides the css and selector functions? Which again, the native `classList` and a simple bind to the selectors are simpler and less verbose.
1. Most of us are using landscape displays. I can have my functionality on the left and my CSS on the right. If the style information is interspersed with the functionality at component level in the same file, I can’t do that and I can only see half the information at once.
2. It fits my working pattern. Usually when I’m editing styles I’m flying between the styles of many different components. If the style code was interspersed with the functionality this would be a lot slower - with stylesheets I just have to scroll.
$(this).closest(".cont")
<a class="item" ng-repeat="action in activeField.actions" ng-click="follow(action, $index, $event)">
{{action.text}}
<i class="{{action.icon}} icon"></i>
</a>In react you don't use the mechanism of directives, you use JSX or React.createElement in standard Javascript statements or expressions.
I think it's important because it decides your templating and composition, which is what React solves with its Components.
I played with pjax which is similar.
EDIT: For example, you might not want ng-click in your HTML if you think that is wrong for example, as it's like DHTML and onclick="" (I don't have a perspective on this at this time)
But JS, from the moment it was introduced, was quite capable of carrying out a great number of interactions. We tend to project our subjective beliefs on the objective world. We don't see potential in JS and so we didn't use it up to its potential.
I recall working on a webshop back in the day that opened in an embedded IE in the app for a popular music company (so I had also full control over the browser engine and could rely on JS), and there was a complex system of discounts as you add plugins to your cart and so on, and I thought: I'll use JS for this. And despite the discounts were verified on the server side, all my coworkers and my boss were intensely worried about me using JS for this, because I'll make the store insecure, and this is a very noob thing to do and I shouldn't be using JS for this. And... it worked fine. The tech was always capable of this, but none of then would've even TRIED, because they "KNEW" it's not supposed to be done.
Eventually the tide turned, but it turned to another extreme, that is even more BS now. Many websites load more JS code than they load images. Why? Because we subjectively believe the server is not capable of all the richness that JS can deliver. Basically we didn't get smarter about any of this.
We're stupid and led by superstitition about the tech we use, we don't really understand it, we don't grok it. We go by fashion and trends. Most do. And that's the danger of starting a stupid trend. It may take years before the bubble pops.
Javascript was fast enough back then to make much more complex applications than most people were making back then but the complexity was mind-numbing, particularly considering that you didn't have tools like async/await to help manage asynchronous communications.
I built frameworks for managing the flow of data in that kind of application and didn't feel it was so catastrophic when Microsoft banned synchronous communications in Silverlight... I knew what to do.
Having had that experiment I tend to laugh at today's Javascript frameworks because they work really hard but aren't suitable for the kind of apps I built back then.
Sometimes it seems there is a lot of "lost" technology in software like the production rules systems of the 1980s, CASE systems and Lotus notes from the 1990s, Google docs in the 2000s that are like Stonehenge or the Egyptian Pyramids seen from the state of programming in 2023.
Sorry, poetic diversion.
It's implicitly expected you're already doing so, such as web components or whatever your selected framework uses to abstract components.
> Having all of your styles duplicated everywhere
Locality is a feature. It's much easier to jump into any random bit of HTML and understand what's going on and confidently make changes without having to pull up multiple other files to grok the classes involved.
Compression is going to solve most of the issues with repeating classes everywhere, and while not recommend you can still use something like Sass/SCSS and Tailwind directives like @apply to separate classes into their own files.
.my-class {
@apply p2 mr-4 mb-2;
}We can agree to disagree about readability though, I have a lot of trouble groking long class=“…” strings.
This is still what you're doing with any components, only the CSS is localized to the component vs. its usage.
Copy/pasting, which Tailwind is so proud of, is to fork, and never merge. Let's fork all the things. We end up with a bazillion little things and no coherence/alignment between them. Hello, second law of thermodynamics.
Quick detour: our universe is so organized, that inanimate matters forks, and animate matters looks at the forks and is trying to find ways to solve these pieces together into coherent systems by merging putting together, deduplicating, generalizing. Inanimate and animate are two opposing forces, increasing entropy requires no intelligence, decreasing it does. It's no surprise Tailwind promotes lack of intelligence by saying "copy paste bro, it's good, turns out". Because that's who they target. People afraid of thinking. "Oh no you gonna like have to name a class, that's terrible". Woah woah... rocket engineering territory here!
For those starting to get back to their senses... they added @apply. But @apply is by Tailwind's own admission "like using CSS". I'd add it's like using CSS but with 1/1000 the capability, unclear/surprising precedence, and tons of extra steps/indirection, because... you could've been using CSS, simply.
And one more word about "compression". Do you know what you're doing when you name a reusable case and put it behind a class, function, package, module, library? You're compressing. So yes compression does solve issue of repetition, but intelligent compression (YOUR BRAIN) does this in a much better way aligned to your project's needs, compared to, say, GZip. GZip can't think for you. It can shrink things for transmission, but its only job is to shrink transmission. Your project still needs to evolve in time, and when you look at it... you're looking at the repetition, not at the GZip.
Or maybe I'm wrong, do you edit the .gz directly? Heheh. If so, I take all I said back.
But compression, in the context of broader space (your project, your industry, your target audience, coworkers, customers) and broader time (project evolution, change management, new requirements adaptation, changing platforms) is your job. The job of intelligence. The moment a computer compresses better than you, is the moment you become useless. LLM is a form of compression, because compression relies on prediction of what's next, whether it be what we desire is next (needs, desires, goals) or what is next regardless (outcomes, events, probabilities). When I tell an LLM "code me a modern site" and it does better than you (i.e. not using Tailwind, but with proper minimal CSS with well named classes), compression replaced you.
^_O
The main reason is that it doesn't necessarily play well with proxies. Most notoriously, Vary: Accept is not supported by Cloudflare (with the exception of images). This means it's not safe to use the accept header if your site will ever be backed by Cloudflare, as you could end up returning cached HTML to a JSON client or vice-versa.
https://developers.cloudflare.com/cache/concepts/cache-contr...
My other problem with it is that it's not very discoverable - it can be surprising to interact with an endpoint that varies based on the accept header. It's not commonly used, so many developers are unfamiliar with it.
And even if you do understand it, it's still hard to tell which endpoints support Vary and which don't.
Finally: I like to debug things by copying and pasting URLs around. The Accept header doesn't support that kind of communication - you need to share not just the URL but also the accept header you were using when you saw a specific response.
I personally don’t care about what cloudflare does because I don’t use them.
The rest is RTFM for whatever API you are calling and you usually have to send auth or cookies anyway, so an accept header isn’t that big of a deal.
If you get a request asking for json, you just return a json with the same thing. Not much changes with API design if you were designing the API well in the first place.
How likely is it every API will adhere to that though?
Anyway, I guess this is yet another reason to not use cloudflare. Thanks for your comment.
htmx has seen a surge in popularity, triggered by a video by fireship dev (https://www.youtube.com/watch?v=r-GSGH2RxJs) and a series of videos by ThePrimeagen, a popular twitch streamer on it
hacker news readers might be interested in the essays I have written on htmx & hypermedia in general here:
and in a book I authored with a few other writers that we recently released on hypermedia, htmx and a mobile hypermedia called Hyperview:
while I am a fan of htmx, obviously, I think the deeper concept that it touches on is hypermedia, which is a worthwhile idea for people to explore even if they don't plan on using it in day-to-day programming.
There are also lots of other great hypermedia-oriented libraries worth checking out such as Hotwire from 37signals, or, my favorite after htmx, https://unpoly.com
This is a boon to many django developers.
I remember few month ago I was making a post liking system, before htmx, I had to use jQuery to fetch the json api server and update the like count, but with the use of HTMX, oh boy it was like I was just writing plain html along with my django logic.
This is one of the greatest thing I've found.
Also, handling forms with HTMX is also very easy.
HTMX really improve both user and developer experience.
By avoiding needing to add lots of client side logic to still get very low latency updates, it's given me the best of both worlds.
The way Django's template system works also makes it so easy to render a full page initially, then expose views for subcomponents of that page with complete consistency.
On a tangent, Django's async support is still half-baked, meaning it's not great for natively supporting long polling. Using htmx to effectively retrieve pushed content from the server is impeded a little by this, but I slotted in a tiny go app between nginx and gunicorn and avoided needing async he'll without running out of threads.
For those curious, here's some numbers for the last 6 weeks to put things into context:
- 4147 new stars
- 86 new contributors
- New contributors account for most of the commits and issues created which is a very strong sign of growth. Even in very popular projects, it is usually existing contributors that contribute most of the code.
https://devboard.gitsense.com/bigskysoftware/htmx
Full Disclosure: This is my tool
we've had a new person come on the project who is focused on auditing PRs and getting the good ones in front of me, which helps a lot w/ getting new contributors in
I have read a little of the website and picked through many of the online examples. One thing I did notice is the preference to update client state (DOM rewrites) based on server HTTP request responses containing full-blown markup. Does the HTMX framework provide concessions for client-side-only triggers and client generated content?
The reason why I ask is that an advantage of the current crop of JS heavy-client frameworks is they offload as much work to the browser as possible. This can result in less resource use on the server end (e.g. data, CPU), which is a big deal for web-scale apps. Is HTMX able to meet these kinds of engineering goals or is the project intended to do something different entirely? I totally get that something like a Facebook client is not at all hypermedia oriented, but folks are going to draw the comparison anyway.
https://htmx.org/extensions/client-side-templates/
however, I would encourage most folks to use HTML as the network format: it typically isn't much more CPU to generate the equivalent HTML string that corresponds to a JSON string (sometimes even less, as with tables)
for pure client-side, htmx is largely hands off. We support an `hx-on` attribute to address the fact that HTML doesn't support general `on*` attributes, but that's it
it does, however, emit a large number of events that you can hook into to extend things:
https://htmx.org/reference/#events
And it plays well w/ scripting solutions like Alpine.js or, our our own scripting solution, _hyperscript: https://hyperscript.org
I just had a fresh read of the docs and htmx is refreshingly, gloriously simple--such a breath of fresh air. So natural, self-documenting, and well thought out. It _does_ feel like a natural extension of html.
To me, the only "missing" piece of htmx is a component model, but for anyone looking for that, htmx would pair amazingly well with Astro[1] which allows you to define and use html components without the runtime overhead of say Vue or React.
javascript fatigue:
longing for a hypertext
already in handThat's a great video explaining the core use-cases of htmx in 100 seconds. Would be great if all projects had such a thing! Htmx reminds me of tailwind in that you've created a set of attribute names and values that are picked up at runtime by a singular library. There's no front-end build required, which is a Very Big Deal for most devs who don't want (and shouldn't have to) to mess with npm and webpack. It looks like the "breaking point" for page size is something like a small SPA - when it gets to big, make another SPA.
Particularly for react/vue devs I think the thing they'll miss is the idea of a uniform, singular object representing global state that is rendered by a single function (defined hierarchically in your component codebase) into the UI. However, it must be accepted that this idea is very demanding in itself, resulting in lots of opinions and hurt feelings, and in addition comes with the weight of a front-end build (and all the confusing variation there).
I don't use it but I'm already a big fan. Congrats!
I land on the index page, and get the full site, then click on about page, and now htmx swaps the content for the about page. However if i refresh the url stays the same, but i now only get the content without the container.
I know this can be solved with checking for a htmx header, but i feel like "there must be a better way" like raymond httinger of python fame has said multiple times.
worth thinking more about though
You make two skeleton templates: One for full documents, one that has nothing in it except the parts that change (say, the meta > title, the body > main and the body > header > nav parts) each wrapped in a hx-swap-oob.
In general, out of band swaps are really, really convenient for non-hierarchical layout relationships.
That's interesting. I discovered Unpoly after HTMX (which I like) and decided to stay with Unpoly for a few reasons. Do you think hypermedia libraries will converge or do you think there is space for different interpretations ?
unpoly is higher level than htmx, with different design sensibilities and concepts like 'layers' (https://unpoly.com/up.layer) which is something that doesn't make sense from htmx's "just extend HTML" perspective
Will there ever be a “htmx“ for building mobile apps?
Adam Stepinski, the creator of Hypreview, built it after his experience with intercooler.js, the predecessor to htmx. It is a very interesting piece of technology and, through the magic of HATEOAS, allows you to update your mobile app instantly for all your users, without dealing with the mobile store!
There is an entire section on Hyperview, written by Adam, in part three of our book:
https://star-history.com/#bigskysoftware/htmx&bigskysoftware...
his video posted on july 7th
Since htmx works by way of custom attributes, can you write a bit about a11y recommendations for developers using htmx? It would seem to me that a lot of things that we get from using standard attributes are lost, and we’d need to do more nuts-and-bolts type work with regards to dom structure and aria attributes. Or does the htmx engine deal with this to generate relevant aria attributes etc.? I couldn’t find any references to this in the documentation.
Also, I love your username!
[1] https://hypermedia.systems/hypermedia-reintroduction/#_hyper...
For reference, I'm currently working within the T3 Stack.
It's just a nice, convenient way of handling such things. The argument in the article is that "this is how HTML should've been from the start" because it lets you do some pretty sophisticated stuff just by adding some simple/intuitive attributes to the HTML.
This way htmx would be even easier to implement in any front-end.
Or maybe I am just crazy.
Edit: or is it this? https://htmx.org/docs/#selecting-content-to-swap
https://github.com/sponsors/bigskysoftware?o=esb
but please don't feel the need to do so
Then once you've got it figured out you just return the part of the template that you actually need to. Makes sense when you think of it as a progressive enhancement on a plain html page.
i agree it can spiral out of control if you try to do too much, e.g. a routes file that is just incomprehensible
i often end up reusing the same controller method to handle a few related routes, using pattern matching in the route declaration
i think also picking your battles and not getting too fiddly with screens that don't matter so much also helps a lot here
Curious to hear thoughts, I haven't done web in a while, so understanding your thoughts might help understanding the whole thing better.
I have had good success and a rewarding experience using htmx the past year. It has been so great in tandem with Clojure using hiccup for SSR.
Once htmx clicks for you, you are almost left stunned by how simple and flexible it is. You can't believe that this isn't how HTML evolved to as a hypermedia. It becomes very obvious that this is how web development should have evolved. I hope someday that what htmx is doing through javascript becomes baked right into HTML and the browser clients.
If you are mistakenly believing it is just some derivative of Angular or you are not grasping the significance of its advancement of the architecture of hypermedia, please do yourself a favor and read the excellent essays on their site; you will then truly understand what REST is and what the importance of real HATEOAS means: https://htmx.org/essays/
They also have a free book here: https://hypermedia.systems/
We made a costly wrong turn 10 -15 years ago by attempting to rebuild thick clients on the web with a JSON API architecture instead of expanding and enriching the new and powerful idea of the early web: hypermedia.
Very happy for the recent attention and "success". Also enjoying the shitposting and backlash mostly from the front-end crowd who believe the Web was invented in 2013 and they "made that city". :)
I'm biased since the time Backbone.js came around, I understood part of the pain but was moderately skeptical, fast forward to React with the young energetic bros building dead simple 5 page websites with a Rube Goldberg setup of front-end frameworks, I've cashed out my tech chips and never touched those things.
Htmx asks us a good question: “does the complexity of your work reside essentially on the server or essentially on the client?”
The complexity for the vast majority of websites resides essentially on the server. Most of us are not building Figmas and Google Sheets. Most websites, even if heavily interactive, are just CRUD apps with pleasant interfaces. Frameworks like NextJS attempt to rectify the problem of overly complex clients by moving React to the server, but this often magnifies complexity rather than minimizing it.
Wouldn’t it make sense to remove React from the stack? For complex clients, skip the DOM and JS with canvas and compiled web assembly. For complex servers, use some form of server-driven granular updates to the DOM.
The problem I see with this approach is that although most complexity reside on the server for most websites, there are almost always a few high-complexity task that needs to reside on the client — image editing, real-time sorting/filtering/calculation, drag-touch gestures, etc.
A hybrid approach is necessary. It isn’t good enough to allow compatibility. Although htmx and React can be used on the same web page, they need to be kept in isolation. But I’m not looking for isolation; I’m looking for fundamental integration.
My ideal framework would allow for reactive granular updates to the DOM while also being tightly integrated with compiled web assembly powering complex client operations. I’d write all my code in a powerful language rather than JavaScript. My debugger would operate on both server and client because the difference between the two has disappeared. It would be true full-stack development — a single-stack application (SSA)
Clojure + ClojureScript comes close to being an SSA, but only superficially.
If ever there was a killer framework for Common Lisp, I think an SSA fits the bill.
I plan on using it again for a future Golang project and look forward to following it's development. If you're in need of a simple/medium complex front end for your app, and _especially_ if you're already using template fragments[0], I really recommend giving HTMX a shot. It's pretty fun to work with coming from Javascriptland.
Also, the guy who runs their Twitter account[1] is hilarious.
Could I have made it work? Yes
Could I have just made the map it's own self-sufficient component and left the rest of the app as is? Also yes
Did I do these things? No. As one tends to do, I just nuked it and started over
* Faceted search with configurable filters, like filter date on before, between or after, but only show the filter if the user wants it.
* Configure result view with different columns or even different views like maps or drawing something on a canvas like charts. You can maybe do some of this stuff with htmx but at some point you'll just need the json.
Even Angular can do this, and with something like SolidJS it is actually a pleasant thing to do.
A JSON api can be re-used by other apps while htmx feels like someone reinvented Thymeleaf
This is a regression on graceful degradation.
It takes careful but not extraordinate thinking to think of ways to get consistent results with or without JavaScript turned on. Indeed, when a visitor hits a site for the first time they get the full response so everything for a graceful degradation should already be there to use. If I can figure it out, I'm sure big CS brains can.
People have typecast htmx as something to use for simple use cases that dont "warrant" getting out the serious guns. There is something to that, but it is limiting. Htmx and related 'back-to-the-server' approaches are a distinct category that could have been explored much earlier but for various reasons isnt
I think you misunderstand HTMX. It’s the revival of an old class of apps in a backend agnostic way. It’s not doing anything new, or anything that warrants a “new class of apps.” It’s a way to build hypermedia (read: content) focused sites. Classic sites like shopping catalogs, forums, admin front ends, blogs, etc.
It’s just jquery/liveview/turbolinks, but backend agnostic and without needing you to maintain much (or any) frontend js logic.
Once you need heavy interactivity (think google docs or figma) it stops providing much benefit.
Maybe I should give htmx a go without hyperscript or maybe I should give hyperscript more time. But on anything that I'm expecting to be maintaining for years it's just too unfamiliar and I don't want to be stuck with it if I wind up never using it again.
1. A lot of custom middleware in controllers to decide if endpoint should return HTML for whole page or only fragment that htmx needs. On the side of htmx that sounds simple but it is something that probably every project using htmx have to reinvent.
2. Bookkeeping around `hx-trigger`. If UI is getting complicated, many elements need to react to external changes. Instead of reading some state and hope that framework will schedule updates, I have to manage a list of events to react by hand.
Anybody had similar impression?
Does anyone know what they have on the roadmap for 2.0? I'm curious what they are working towards.
I did a lot of sideprojects in Knockout and one large one in Angularjs 1.
I feel all the frontend frameworks need to talk about what they see the problems are and decide how to fix them.
I would like some solid foundations and avoidance of common pain and gotchas of scale and complexity.
My old sideprojects are broken because I didn't fix library versions. My JSBIN sqlite file with my knockout projects in is also in an unknown version of JSBIN which latest JSBIN doesn't work with.
The speed that frontend development moves has broken lots of my code.
EDIT: Screenshots of my old experiments: https://github.com/samsquire/interface-experiments
In my dream world, HTMX could become part of the HTML6 spec, and beginners could spend more time dipping their toes in the water testing their .html files in Chrome before they face getting gobsmacked by the greater JS ecosystem.
I worry it will be truly challenging without a big compromise to morals/openness/etc. I kind of wonder if stuff like htmx should just be funded with a big grant so it never needs to worry about selling out users for profits and operating income. Or at the very least that it learns to run extremely lean, to not chase expensive fads, and to build itself into something that can survive off a modest "please donate/buy some stickers/tshirts or my book" income stream. I hope we don't see the day that suddenly there's no download link on their site and it's replaced with a, "please contact our sales team for a demo!".
i have a day job (a couple) so there is no financial pressure around it
i hope that it will be a long term public asset for developers
(I don't like javascript and i think making websites sentient was a mistake)
I mean, for example, the first motivation it lists is 'Why should only <a> and <form> be able to make HTTP requests?', why is that an issue? And 'Why should you only be able to replace the entire screen?', I mean that hasn't been an issue since XMLHttpRequest or am I missing something?
I wouldn’t call it an issue, but maybe you would like individual elements to fetch their own data. Sure you can do the same thing with JS in the browser (calling fetch or XMLHttpRequest), but htmx lets one do it with attributes on tags.
The “replace the entire screen” business is a jab at React-like frameworks. Although they all claim to update only the DOM parts that change, it’s very easy for a codebase to [accidentally] force a full page redraw.
I can see the appeal, it's what ASP.Net WebForms probably should have been. And for that matter could probably cleanly fit with ASP.Net MVC and Razor views.
So many stories start with "I used htmx with (rust|go|ocaml|django|etc) and had good results".
Feels hard to not use JS/TS on the backend if you are already using it on the frontend (unless you have a specific need node can't fit). Why intentionally use two different languages, yadda yadda, etc, if you don't have too.
Its refreshing.
After seeing _hyperscript, it looks like they may have invented that first, and a lot of people's heads exploded, so they decided to try to make a "gateway drug" to sneakily introduce _hyperscript, and came up with htmx.
htmx is version 2 of intercoolerjs:
which had a proto-scripting language in it, the `ic-action` attribute:
https://intercoolerjs.org/attributes/ic-action
i dropped that attribute (along w/ the jQuery dependency) when I created htmx, but I felt there was some merit to the idea of a lightweight scripting language that abstracted away async behavior. Once htmx had stabilized I revisited the idea, remembered my experience w/ HyperTalk as a young programmer, and decided to take a shot at that, but for the browser.
I'm very happy with how it worked out, although I expect it will always be niche when compared with htmx, which has much broader applicability and isn't as insane looking. :)
Nah sorry, not convinced.
- Websocket & SSE support will be completely pulled out to extensions (already available in 1.0)
- We will drop IE support
- We may include a "morph" swap strategy based on idiomorph (https://github.com/bigskysoftware/idiomorph/)
- We will change a few defaults around how HTML is parsed, taking advantage of the removal of IE support
Hopefully transparent to the vast majority of htmx users.
But why are the websockets and SSE are migrating to extensions?
Maybe stupid question, but what are the downstream implications for folks like Vercel/Netlify/etc. who bet the farm on complex server rendered JS pipelines?
there is no reason that they can't tweak their services to be more hypermedia friendly if and when this approach becomes more popular
netlify (which offers free hosting for https://htmx.org, so is a sponsor of the project) is very HTML/hypermedia friendly as far as I can tell, and I don't have enough experience w/ vercel to say much other than a vague sense that they are extremely react-oriented
no reason that can't change as the market changes though: hypermedia pushes the main value locus of applications back on the server side and so server-side companies should like that
I use DRFs renderrers so my Django backend can render either JSON or HTML, so my API is still "restful", it just serves HTML to clients that request HTML like browsers with HTMX and JSON to other clients that request JSON.
Does this work with Web Assembly? Of course Web Assembly will die too since it can't do SEO.
In all seriousness though, what is the "core" reason to actually adopt this over the current approach?
You mean "This just won't die"? Because it seems to me that Web Components are here to stay, especially since something like htmx boosts their functionality with absolutely minimal added cognitive load.
I feel that, pretty soon, the choices for a full-functioned web application that is easy to maintain with high development velocity is going to be:
1. Master HTMX and Web components in a day, and be productive
Or
2. Spend a month learning React, and still get hit by all the footguns.
https://htmx.org/essays/hypermedia-driven-applications/
and then work through the rest of the essays:
I have to disagree with that. I’m happy htmx exists and that it works for many but in my professional life I've found few cases where it's the best choice. And that’s fine! It’s a wonderful thing that the web has been able to grow in so many diverse ways, there should be no one way it “should have evolved”.
IMO this is the biggest mistake in web dev in the last decade or so: that there should be One Right Way. No matter if you’re making the next Gmail or if you’re making a static blog the cargo cult of an industry tells you it should all be done the same way when common sense would tell you that’s not the case at all.
For one, htmx is not a full solution to avoid JS. It's excellent for the parts that are AJAX/CRUD, which certainly covers a lot of ground. You still need something more if you're doing stuff that doesn't fit here like interactive visualizations and many other use cases. However, it integrates very well with other lightweight libraries.
Secondly, htmx is great if you're developing full-stack (like GP). Meaning you touch every part of a site from the data model to coordinating messages to the frontend etc. If you want a much clearer separation between frontend and backend of a site, especially in terms of contributors/teams, then it might not be the right tool. IMO there are plenty of good reasons to do either.
Third, and this is a bit of a combination of the first two points, if you directly fetch data from a third party, say a JSON API, then htmx doesn't help you at all.
So really as you said, there is no one right way. For me it has been working very well though. People should look into it for sure though. There's an opportunity to combine htmx with orthogonal libraries that do the dynamic parts like lit etc.
That is why I wish HTMX to be merged into HTML5 spec. For something like 98%+ of the web it will be good enough. You then have a small JS library for the other 1.9%.
The 0.1% left is just pure JS Web Apps.
If I had to pick an “Angular-1-like” framework, I would pick the one that clearly documents it’s boundaries and provides a clear way to use a mature SPA framework when there is a need to cross those boundaries. If anyone is aware of such framework, please share.
as much as possible, htmx tries to take HTML to its logical conclusion (from my perspective) as a hypermedia, rather than imposing other ideas on top of it
What kind of app are you working on?
Yeah, so moving to htmx has allowed us to jettison ClojureScript which just entailed too many parts. As a matter of fact, before going more htmx with our projects, we had moved away from ClojureScript to React directly.
For instance, inside an HTMX application, I just coded up a plain ordinary <script> (no framework, no build system) that displays a count of how many characters are in a text field and also disables or enables a submit button according to that size. It's 9 lines of code plus an attribute on the input. It might be less if I did it in
Immediately it faces the problem that there are two paths: (1) the initial setting of the length display (the field is pre-populated with text, I ended up setting it in the SSR) and (2) what happens when the text content changes.
If you use signals or hooks or useEvent or lifecycle methods or whatever you always see a certain amount of awkwardness that stems from the above.
Note I could have done the above with "pure HTMX" in that I could have had the event handler trigger a server round trip that repaints the text field and the submit button, it wouldn't be as bad as it sounds in performance, but boy it seems like a waste.
I've built applications that were a lot like Figma, Photoshop, or Eclipse, where the user could update some data and it could have very arbitrary effects on the UI because the user is able to add and remove many different UI elements and in a case like that you need some system that can manage dependencies at runtime.
React has revolutionized how people build widget-based frameworks, there is never going to be anything like Tk, Cocoa, GTK, WPF, Spring, JavaFX ever again, or if it is it is going to be influenced by React. There's the awkward fact that React is overkill for the typical form processing and e-Publishing applications people write with it but it is not up to the task (without an additional state management frameworm) of applications like Figma.
Personally I'd like to see a mostly declarative form processing framework with a sprinkle of scripting: before there was the iPhone there was WAP
https://en.wikipedia.org/wiki/Wireless_Application_Protocol
which had a way to send multipart forms to the client. Something like that designed to work with a software factory
https://www.amazon.com/Software-Factories-Assembling-Applica...
(one of the most visionary books of all time... the authors built an enterprise software development framework for Microsoft that was nowhere near as cool as their vision)
or a "no-code" app builder could be great.
I'm still trying to get my head around websockets. I've built some small demos that are awesome, like a program that controls the volume of my smart speakers and has the sliders move when I change the volume with the remote control. I really wish my RSS reader could update my "favorites" window as soon as I add a favorite in another window, but doing that efficiently requires answering questions all the way from the front end to the back end to the database. I'll probably find a half-baked way to do it but it's sad that I'm settling on a web application to have the limitations web applications had 15 years ago.
We unfortunately weren't able to win hearts and minds around these concepts in the long run, and blog driven development (a.k.a. cargo culting) replaced our efforts. I feel somewhat redeemed now that HTMX seems to increase in popularity, it's nice to see that we weren't alone in thinking along these concepts.
Of course, if the concepts were strong that implies my execution wasn't, so maybe I shouldn't feel so good about it after all... :o)
A good idea or a good product are never enough. You have to sell the product in order to have it be successful.
In your situation, you were at a bank, so your TAM was roughly 1 enterprise (or maybe a dozen, tops, if divisions had federated or siloed tech). And your 1-to-a-handful of potential customers were probably of the large and difficult to change variety. That's a huge constraint, and not landing it there doesn't mean your idea was bad, it just means you weren't successful in selling it and I'm going to tell you that you probably _couldn't_ have been successful in selling it where you were, when you were there. I worked for your lazy cousins at the same time - big insurance - and had the same issues selling my own ideas internally, if that makes you feel any better.
HTMX has no such constraints. It's a decade later and the TAM is more or less everyone doing or preferring to do SSR. The same/similar good idea, but different place and time.
Ironic considering what the OP attributes to HTMX's current popularity.
Like angular, react got the huge initial boost in popularity because of the brand behind it.
I hear that you and your band have sold your guitars and bought turntables.
I hear you rewrote your http endpoints to return JSON because that was REST.
I hear that you and your band have sold your turntables and bought guitars.
I hear you rewrote your http endpoints to return templated html fragments because that was HATEOAS.
I'm losing (regaining/losing/regaining) my edge
I'm pitching a mobile app built in Unity and a custom ruby backend on digital ocean.
They questioned my tech choices on a working app! Apparently if you want VC money you must use their approved tech stacks.
But Backbone was a bit sloppy, not very enterprisey, until Angular came around.
Anyway, this string of web applications became popular (in my world) because it meant that we could separate back-end from front-end, and have one back-end (usually REST/JSON) fueling mobile and web clients separately. That was it, that was why we built SPA's, but by now that has been forgotten again.
And in my world, it made sense because the apps were behind a login. But then They wanted to make SPA's facing the internet, for things like webshops. And I get that too; I've made a few websites using Gatsby, they're crazy fast for navigating AND still indexed by search engines.
Anyway, in some cases it did get more and more complicated, then with server-side React and the like. I never had to touch that, thankfully.
on the other hand, my hope is that eventually htmx (and, more generally, hypermedia) is accepted as a tool, a useful too, but just a tool, even by the front-end folks who haven't thought very much about hypermedia in a while
i don't see the two approaches as mutually exclusive and agree w/ Rich Harris' concept of 'Transitional' web applications that mix the two approaches. I would just draw the line where you abandon hypermedia for a more elaborate client side approach in a different place than him.
I certainly do.
I went to a series of JavaScript conferences and React is extremely diverse.
Good to see diversity all around, I just wish there also would be diversity of thought and it comes to building web pages. But I guess that would lead to people admitting ~80% of all the stuff they build does not require React or equivalent js frameworks and that would be both an ego and economic/résumé problem..
> A hybrid approach is necessary.
This is "the islands" approach, as advocated by Astro, for example:
https://docs.astro.build/en/concepts/islands/
This approach is consistent with htmx and friends, and we're using it on an htmx project with simple vanilla JS for the pieces of interactivity. For small and medium projects and a small team, this can be enough, and it's a breath of fresh air to be able open up dev tools, point to part of a page, and understand everything there just by looking at the html and small snips of JS.
Blazor United promises this hybrid approach. You code in C# in one way regardless of server or client. On first page load it renders everything from server-side. Then webassembly gradually takes over and it starts loading C# code on the client to speed up UI interactions that don't require server side data.
It works well but their current challenge is reducing webassembly files size which is about multiple MBs.
https://visualstudiomagazine.com/articles/2023/04/20/blazor-...
God hear your words
For the second part you probably go with your own javascript or get away with hyperscript
The point about a JSON API is a good point and if you need a public API then you should probably factor that into your decision making but not everything has this constraint.
> The point about a JSON API is a good point
The HTMX-specifc API applies a template/transform over the model and returns HTML instead. If one thinks of hypertext as another serialization target, it's easy to see how one would easily be able to serve both JSON for pure APIs and hypertext for HTMX.
So for such things I would give the user a very broad set of data via htmx and then allow for further (realtime) filtering via JS.
If I want them to be able to search through data that isn't displayed initially I just deliver it with a hidden css class and remove that class if it is searched for.
Htmx, like any technology, is very well suited for a certain set of problems — iif you don't try to make it do tricks it is not good at, you should be fine.
something like this is complex enough to require some front end scripting, which I am not opposed to:
I mention C# in that ASP.Net MVC + Razor seems like a very clean match to the HTMX paradigm.
Not affiliated with them in any way, but it's made with htmx and some JS for more complex features
As for "new class of web experiences", given that htmx explicitly aims to expand upon what is considered the Old Good approach, not sure if it can provide that
Something like this
https://reviews.gitsense.com/insights/github?q=pull-age%3A%3...
might help as well. Click on the different pills (Authors, Targets, Days open, ...) to get a different view of the contributions.
The point to take away from htmx and hypermedia more broadly is that there isn't a clean separation between the front end and back end of a site. The concept of completely separate front and back end teams building SPAs/JSON APIs has been a very costly development that has brought substantial complexity that is wholly unnecessary for most applications.
Your banking/project management/todo list/budgeting/insurance/education/whatever app almost certainly doesn't need to be an SPA and would be developed faster or for less money if it leaned into server side rendering (SSR) and used a library like htmx or Stimulus to enhance the user experience as needed.
my use case is embedded systems that can typically do client side rendering in browsers, the only server side rendering I can afford is some simple lua or c/c++ mvc alike backend,Django is too 'fat' on resources. there are some of them but none that is great and actively maintained as far as I know.
If I get the time I will publish and link it for you.
The way it works is by leveraging the existing aws client libraries to sign and (de)serialise parameters and responses, so you can do something like:
hx-ext="aws" hx-post="aws:ec2:us-east-1" aws-action="DescribeInstances"
and it will just work with any params such as form inputs or hx-vals etc
the reason i haven't posted it yet is i want to find a good way of mapping parameters since the aws api can have some notoriously complicated parameter formats
I recognize thats how templates work but for some reason it seems weirder when applied to the element, rather than page level.
Recursivedoubts has legitimately demonstrated he's not a one-trick pony (previously built intercooler, concurrently building hyperscript) and he deals with skeptics like yourself dozens of times every time an HTMX article gets posted on this site (which all seem to go to #1, if that serves as an indicator of the library's popularity). He handles himself with grace and patience and humor, far better than most of us would do.
You don't even state what your "current approach" happens to be in order for him, or anyone else, to provide you with a satisfactory answer.
i think one of the strengths of htmx is that it isn't really trying to change the paradigm to something brand new, it is instead going back to the original web paradigm of hypermedia and asking how HTML could have advanced within that paradigm, in contrast with the SPA paradigm that replaced it
so less of a wild bet, with more known advantages and disadvantages
For example, global state management approaches like Redux were more or less incompatible with how we approached state management. We thought it was insane to build apps around the idea of global state stores (and I still do) but Redux became all the rage and eventually won the day. There was a lot of collateral damage as people then tried to shoehorn Redux everywhere. I left around that time, but hear that the cycle have repeated a few times since. Redux (and other tooling) didn't work out as expected so wheels have been invented again over and over. It's the way things go I guess, I don't dwell too much on it.
We probably could've done a better job at communicating why our approach was better, but ultimately we had limited ability to force anyone to use our tooling. There's also a hiring aspect in there. As Redux and other libraries that were "the thing" started to make their way into job descriptions it became harder and harder to convince talent that they should join us, because we didn't have that brand recognition and used in-house tooling. At some point you have to make trade offs and sadly top tier financial institutions aren't necessarily known for leading the pack in terms of innovation. It's kind of sad really.
Anyway I'm not particularly hard on myself or bitter about it at all actually. The self deprecating jab about poor execution should be read as tounge-in-cheek really, I'm very proud of the work we did back then.
That’s still an issue I have with HTMX, but I understand for simple use cases it’s fine. I’d rather use HTMX than JQuery that’s for sure.
But I do appreciate that you tried to parse it.
It's some lyrics from an LCD Soundsystem track with some topical snark mixed in
If you replace a 22,000 LOC React + Python app with 1,000 LOC of whatever framework you choose, I would be very, very, very, very impressed. I don't believe you.
whenever agile project fail, agile shaman say "you didn't do agile right!"
LOL
No. Htmx supports extracting a subset of received HTML and merging it with the current page.
So, for a typical form, you _could_ do a request to validate the entire form then extract the relevant error message for the input field that triggered said request.
This would re-use most code of the actual form submit endpoint except it _only_ does the validation.
> And somehow keep it styled and matching all of the UI elements rendered on the frontend?
When using Htmx, the backend would typically own the frontend. So the styles and UI elements are already "matched" as it were.
> No thanks, I'll just give you data and you can present it however you please.
This makes sense when there are multiple frontends and/or consumers of the API. When there is exactly one API consumer, and that API consumer is the frontend, Htmx can save a lot of time by reducing the overall complexity of the project.
Thanks.
What's the alternative?
You want interactivity that users can trigger. You'd need to call an endpoint in some way or another, giving you updated data, no?
> And somehow keep it styled and matching all of the UI elements rendered on the frontend?
Wait, how are your other UI elements rendered? How are they styled?
Somewhere in your code, you'll have a step where you generate HTML with CSS classes. It's popular to use React for this step, or some form of SSR where you render HTML templates.
With HTMX, you can simply reuse the same backend SSR templates that you were already using, and extract some parts of it which you want to be interactive. These will be rendered whenever you trigger an action, by HTMX fetching that part of the template.
If you want to strictly split frontend and backend development for some reason, you can totally do it: You'd have a business logic layer that provides data to the view layer within your app (be it JSON, or POJOs), and the frontend team styles that data in the view layer however they please.
And the benefit is that you'd all render it on the server. No need for the client's browser to do anything anymore. It's all coming pre-rendered, cacheable and indexable. Done.
And on that note do you think that a smaller striped down version of HTMX is feasible like petite-vue is for vue
yes, I think you could do a stripped down htmx that doesn't support a lot of the stuff htmx does, particularly life cycle events and more elaborate swapping mechanism
for example, most response headers could be just done as the HX-Trigger response header + some client side scripting
history support and form-value gathering is likewise a source of complexity and code that could be omitted or done less completely
I agree. I think what we're seeing is investment risk assessment as a proxy for a deep understanding in technology. After all, if you don't know how anything works, all you can do is look to what _has_ worked for you and other investors in the past.
I'm guessing here, but it's plausible that once a given stack has proven to make money, the fix is in. It wouldn't matter if it's the best choice out there or not. The track record itself makes it more attractive. Example: Ruby on Rails.
React didn't get much adoption initially and FB didn't spend money on marketing their framework, like Google did with Angular. Developers started using React to speed-up table rendering in Angular application, and only after some performance-related blogposts adoption started to grow.
Not everything Microsoft has produced is terrible, but for a while there it seemed all developers I knew couldn't see past the brand even if the tooling/products/ideas were solid. I feel it's gotten better since Nadella took the reins, but the smell still seem to linger sometimes.
Time to go snow skiing in hell, I guess. It's deeply frozen over.
If Microsoft provided a Developer's Edition of Windows -- without telemetry and ads -- that also came with access to a knowledge-base of best practices for Windows-based software, and why you want to use each major Windows component, for a flat, one-time fee, I'd strongly consider building things for that environment.
I feel like Microsoft's current approach of buying their way under the free software world via GitHub is kinda scummy, and all that code's now under Copilot and other LLMs. If they were a bit more upstanding and had a clean, mutually respectful business model, I might consider buying their products.
In the mean time, I'd rather use something written by a random hacker, because I can at least read their code, or even hit them up and have a conversation about their project.
I inferred that the intent was to say that not all people using React fit into one category.
> ~80% of all the stuff they build does not require React or equivalent js frameworks
I'm well aware of this for some portion of the things I build, but I don't agree that these frameworks are generally unnecessary or not preferable. It's also hard to say when something "requires" these tools or not. Arguably you could say nothing requires them these days.
I like to build with all kinds of tools though, and React and Vue are for example are often more helpful than harmful to my development experience. I'm speaking as someone who has been building things for the internet for around 20 years, so I remember life without these tools.
> that would be both an ego and economic/résumé problem
Maybe. I think this might be more true in roles that are closer to entry level, though.
edit:
From your previous comment,
> fast forward to React with the young energetic bros building dead simple 5 page websites with a Rube Goldberg setup of front-end frameworks
This is a good point. It's still a thing and will probably never go away, regardless of which frameworks we have. I think it stems from people fundamentally misunderstanding our core web technologies and not realizing how easy it is to do what they're doing without React or Next or Nuxt or what have you.
In many cases I've worked with people who wanted to do the most trivial things in their UIs and they worked tirelessly and earnestly to implement it with React or Vue, but it was something that already exists in the Web API or HTML elements. Basic stuff like reinventing checkboxes. Or reinventing the button element by styling an anchor and altering its behaviour with JavaScript to submit a form. So many younger people have started their careers in web development on frameworks, and they genuinely don't understand how the fundamentals work.
True - but not by much
> Parsing large json objects and then building up a corresponding html structure may be more difficult than on the server
I doubt it. And you'd only be doing "large JSON objects" for a desktop web app, where CPU differences vs web servers are even smaller
> where you already have it loaded into memory anyway
Likely not true if implementation uses streaming semantics
we have written a book on the topic here:
you can read chapters 1 & 2 for an overview of what hypermedia is at a systems level:
https://hypermedia.systems/hypermedia-reintroduction/
https://hypermedia.systems/hypermedia-components/
As far as what the term _hypermedia_ means: it is a media, such as a text, that includes within it _hypermedia controls_. Those hypermedia controls allow non-linear branching and interactions with the media, hence the term _hyper_, that is, above, "normal" media, which is consumed passively.
The hypermedia controls we are all most familiar with are anchors/links & and form tags. htmx attempts to generalize the concept of a hypermedia control.
The book goes into gory detail if you are interested in further exploring the idea.
So it's not really an "Angular-1-like", but more like Vaadin in JS.
Being able to write components in a single HTML file would be wonderful.
Frameworks like SolidJS and Svelte simply got rid of the virtual DOM and reaped massive performance wins from it. I find it hard to believe that adding a worker and a virtual DOM back would end up making them faster. Quite the opposite in fact.
Then there's the dev experience. Would it be easier for a developer to work out what to do in a separate thread and post messages back into the UI thread? Seems like extra cognitive overhead to me.
Ideas are great. They move the state of the art forward. But if your idea doesn't comport with positive results from testing, it's not useful. Intriguing, to be sure, but not useful.
I meant to suggest that frameworks might be able to take this approach internally and make the DX transparent. I actually had a go at this using Mercury back in the day, but didn't have the motivation to finish it properly.
False. https://infrequently.org/2022/12/performance-baseline-2023/
Or do people study this while thinking about IoT which may use more limited resources while still relying on the internet?
Especially since a server has to handle multiple request concurrently, it doesn't seem to be remotely the same workload that a single device CPU would see anyway?
I will allow that it is probably theoretically possible to do client-side rendering in a CPU-efficient way, but it sure isn't the standard.
1. Server-side rendered sites in Python using either Django or FastAPI/Jinja2 and htmx;
2. Dotnet back end with Angular front end.
In practice - for the apps I've been involved with - option (1) provides a more than acceptable user experience. There's no doubt Angular can go beyond the capabilities of SSR+htmx. But, in practice, it's in the long tail. Throw in the odd js lib, e.g. for charting, and option (1) is good enough for the vast majority of things.
The complexity is not comparable: (1) is much simpler. For a start, all logic is in one language. There's no separate build for the front end and back end; no need to reconcile state in a front end cache with the back end. There's no need to export every view as a REST API; it's a native function that gets called from the view handling function.
Others will have different experience: I'm not saying this is universal. But in my experience, objectively, it's not true that the complexity moves from js to htmx. At least, not if that implies the complexity is equivalent. It's just not the case.
To me, htmx isn't as revolutionary as people make it out to be, and possibly that's due to the fact I'm just not burdened by the old days of gigantic Angular apps and massive ASP.Net stacks. My history was mostly JQuery where needed (which was all the time before JS got its act together).
Plus, if it's done right, you can get a lot of functionality while remaining No-JS friendly.
Can you elaborate on what you mean by this? Front-end framework don't care what language back-end logic is written in. For example, I have a Vue/Vite site that calls back-end functions that I'm gradually migrating from one language to another, and no front-end changes have been required.
Its not a fit for every site or use case but more than any other front-end tool or library or framework, it has enabled me to actually realize the UI concepts in my head to the actual screen, and usually a lot quicker than I'd expect.
This is what I don’t get about HTMX, you can’t give a good experience without client-side JS, sure some developers might love it, but that shouldn’t be the yardstick.
htmx should remind you of those times.
I certainly has for me - it's just (fundamentally) a fancy and clever wrapper around jQuery ajax requests made via HTML attributes.
But then I would be using only JS. I want a backend to be something else so that I don't go insane.
The advantage of htmx over jquery is declaring the replace condition & behavior inline as part of the component. Conceptually this is easy to reckon with as a separation of concerns thing as well as a sandi metz-ish "when would this code need to be changed" thing. The html tag is responsible for its own update, and so its update is part of the html tag.
Jquery does the same things but requires you to declare the behavior separately from the component, decide on & maintain abstractions and reuse patterns. And manage code organization so that for any updatable template code you can find the corresponding behavior declarations and understand their scope w/r/t other template code.
Moreover, HTMX makes it incredibly easy to change the whole paradigm of submitting data. You can eliminate some forms entirely and just enable a series of individual questions/inputs/selects one at a time, especially useful when a single static form isn't always appropriate (multiple pathways, questions/options that are contingent on the response to a previous question, etc).
In my experience the UI flow and degree of detail for avoiding common errors is greatly improved.
There isn't one thing called "conventional React", there are all kinds of validation libraries on npm and many strategies laid out on Stack Overflow. https://stackoverflow.com/questions/41296668/how-do-i-add-va...
I think it's fair to say we have different opinions on good UX, no need to debate it any further
You can also do the same in Node if you want to, I currently have a TS website that is mostly templated HTML in production (without htmx). Htmx would be perfect for that site.
Ah, so "with htmx you can use any language" is true because its users are no longer using a programming language per se for the front-end, but instead are defining logic with htmx's DSL?
There's also WASM, which is slowly gaining steam, but it still isn't a first class citizen like JS is.