Cheers! We've been running the various betas in production for a couple of months now. For our Rails app we replaced most of our Hotwired/Turbo with HTMX. For me at least, HTMX just makes more sense: you control the flow of content from the client, not from the server as you do with Turbo.
For pushing updates, we use ActionCable, but we do it in a different way from what we used to do with Turbo Streams: when a record is updated, instead of sending HTML from the server to the client with instructions on what to replace, we only send a small JSON payload with the ID of the element that was updated. On the client side, an event is dispatched that any DOM element with <hx-trigger="<resource-id>:updated from:body"> will trigger on. For the rest it's just basic HTMX, only the trigger is "custom".
Same, although my M1 pro has only 16 GB of RAM and that does seem to slow it down a bit with my current usage. I recently bought a used Mac Studio M2 Max with 64 GB RAM and it's much faster, both subjectively and objectively by looking at how long it takes to run the full test suite of the Rails app I'm working on.
Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed.
The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.
LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.
> The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.
I was going to suggest anchor positioning. I found it difficult to wrap my head around too, but once it clicks it's pretty simple. As a bonus, you can use it to position many other things than just popovers.
Baseline newly available. For Germany that means 80% vs the usual 90% (I wonder how the Internet looks for those 10% who use ie, Firefox 20 and Chrome 1 or whatever), which, considering that it doesn't really degrade well, makes it pretty much unusable for serious sites.
Thanks for giving me some confidence, I converted one of our popovers to use anchor positioning and it was actually rather easy. Just had to use anchor-scope which not all tutorials use!
Can we stop calling them skills? They're mostly just documents like any other. Call them cheat-sheets or guides.
Wrapping an .md file in all this circus, with lingo carefully designed to hide the fact that under the hood you're really just dumping another text file into the LLM's context , helps nobody but people's AI psychosis.
But I guess "my LLM can use skills" sounds a lot cooler than "my LLM can read text files", so we'd rather keep pretending really hard.
> The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it.
If you put something like this in your popover class, it will resolve to the button that called it when position-anchor is not set:
top: anchor(bottom);
I'm not sure how widely supported it is but I've been using it in Firefox/Chrome.
All current browsers support anchor positioning including popover buttons being the implicit anchor. However, the anchor positioning polyfill does not support this, it requires an explicit anchor-name.
This seems like a common enough issue that it would be worthwhile publishing a "Markdown library" of "stuff HTML can do" that you can "call" from your AGENTS.md.
(They made it a skill, which brings me to another thing I've had on my mind lately: that's annoying if you know when you start the harness that you will want it to read the skill. It's a roundtrip through the model to activate it. But maybe there's a way to fix that?)
(Edit2: Claude says if you activate the skill via /skill-name in the initial prompt, you get what I want)
I'm curious how many people are involved in the design of your app and what their concerns are.
Testing for accessibility and on mobile devices has a tendency to derail the best intentions. What tools are you using for those concerns? I'm not asking because I need advice. I'm asking because I want to know what you or your team did.
It's a small team of four, everyone works on the "full stack" which is Rails with HTMX and very little JS. As the lead dev, I am usually the one to make the decision that we should use the modern browser standards.
It's a niche B2B SaaS app and luckily we know most of our users personally. They all use modern browsers, usually Chrome or Edge on Windows. There is not a lot of mobile usage although we do support it.
I'm not an LLM, but that was my immediate thought - how new does a browser have to be to support these and which browsers am I excluding by using these features?
> LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.
I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.
The top-layer + cascading-close behavior is exactly why we finally dropped a bunch of custom overlay managers.
On positioning: we got farther with CSS anchor positioning once we stopped treating it like absolute offsets and started from "this is the preferred edge, then let the browser flip." Still awkward for nested context menus, but far less brittle than measuring getBoundingClientRect in a resize observer.
Did you read actually read the article and if so, did you read until the end? Let me just respond by quoting the article:
> When experts started speaking out about the Ocean Cleanup several years ago, I witnessed several of them endure online harassment from supporters of the organization, often phrased as “At least they’re trying to do something to help, all you do is complain.” (Note that this was being said to people who devoted their lives and careers to evidence-based solutions to cleaning up the ocean).
This feels like an uninformed, generalized opinion from someone with zero experience on the topic. Have you even used HTMX or a similar approach?
Besides the memes, it is absolutely not hype-driven, but hypermedia driven. It asks the question: could HTML be even more powerful than it already is?
The creators of HTMX even want to standardize core ideas of HTMX into the official HTML specification: https://triptychproject.org/ Please read this and reply when you still think it's hype.
I have been writing frontends since early 2000. So I have seen it all, from activex being shinny to jquery, mootools, backbonejs, angular 1.0, php, Java Spring, Go.
Hypermedia is what to web apps what XML is to programming languages. We have tried HTMX as a concept many times over, there is nothing new here, and like everything declarative, sooner or later it will fall short and you're going to reach for escape hatches and what not.
And the features specified in that project is nice to have, in the same way that it is nice that we have Date Pickers or other advanced input features, but it is never going to replace React-like frameworks.
Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
> Hypermedia is what to web apps what XML is to programming languages.
I have no idea what this means. The World Wide Web itself is quite literally hypermedia.
The fact that a lot of front-end frameworks appear hell bent on ignoring this fact doesn't make it any less true.
> Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management...
You may have stabilised on JSX, "we" have not. React is one way of building web applications. It's appropriate for a certain subset of highly interactive SPAs, and completely inappropriate for many other things.
I listed frameworks that makes majority of the market share that are based on JSX and react-like reconciliation loop. This architecture is also now dominate in the mobile apps space via React Native and Flutter as well.
So I am not sure what you're talking about. The industry has largely stabilised on this architecture because it works. So I don't know who this "we" you're talking about or what you're even talking about anymore.
> Again, the reason we have finally stabilised on JSX is because you can't really "Declare" away HTML or sophisticated data and event management, Google really really tried that with Angular 1.0, and we know it doesn't scale.
You're just arguing for sake of arguing. Goodluck.
> I have no idea what this means. The World Wide Web itself is quite literally hypermedia.
I think he's saying that the Web is hypermedia plus Javascript, rather than just hypermedia. Which means, from the standpoint of the power of hierarchy, that it's Javascript, which also happens to use some hypermedia. Even if you use only a tiny bit of a Turing-complete language, Turing-completeness defines what your system actually can do.
This makes the Web fundamentally awkward, because most of the behavior is defined by the hypermedia part, and users have inconsistent expectations for what happens when you break the illusion.
HTMX works by extending the illusion. JSX works by breaking the illusion earlier rather than later.
For me personally, there is no point in using more reasoning than medium or sometimes high. It just gets so much slower and expensive, meaning that i have to wait longer to evaluate the results and provide feedback or continue to the next task.
I had an enjoyable conversation with it just now where it repeatedly told me it had generated an SVG of a pelican riding a bicycle along with a clickable data: link. Obviously, this is just harness polish. Overall, it's quite impressive.
Someday we'll have a tokeniser that works directly on human speech instead of doing speech-to-text and text-to-speech steps in between.
> Some of these features can be turned off. Others can’t. Or if they can, it means also turning off useful long-standing features like automatic thread categorization.
This, I absolutely hate it. And like the author said, it must be intentional, so that someone at Google can show the usage numbers and get a promotion.
I recently installed an app to manually activate the fans on my MacBook Pro M1 Pro as I've never been able to trigger them over the past 4+ years. Just to check whether the fans even work (they do).
You must be using only lame languages like C or Go or Python that aren’t optimized for laptop warming during compilation. Try using a Real Language with a Real Compiler, like C++ or Rust or Swift, and build decent-sized projects using all cores.
(All joking aside, this is why I have a MacBook Pro. Compilation easily hits the Air’s thermal limits and the performance boost on the Pro with its fan is impressive.)
For pushing updates, we use ActionCable, but we do it in a different way from what we used to do with Turbo Streams: when a record is updated, instead of sending HTML from the server to the client with instructions on what to replace, we only send a small JSON payload with the ID of the element that was updated. On the client side, an event is dispatched that any DOM element with <hx-trigger="<resource-id>:updated from:body"> will trigger on. For the rest it's just basic HTMX, only the trigger is "custom".
reply