A way less marketed version of this is htmx [1]. It is a single javascript file that enables this functionality. I mostly see people using it with Go backends but I think it is flexible. I have been meaning to try it out for a year or so.
At least as far as Hacker News is concerned, I'd call htmx way more marketed. It has hundreds of HN submissions in the past year alone [0] including one that broke 1000 points. Compare that to Hotwire which is sitting at less than 30 submissions in the past year [1], the most popular of which is this one.
I guess it is that HTMX just feels like one guy's side project. Granted he is great at posting. TFA feels like 37 Signals took the same idea and is trying really hard to sell it.
But not before Intercooler.js (the predecessor to HTMX) or Turbolinks (the predecessor to Hotwire). This is an idea that has been developing for as long as the web itself, I don't think it's important to assign inventorship of the concept as a whole to any one project. They've all been learning from each other and innovating in their own ways.
It's not just that the idea has been developed over and over, but it is constantly hyped as a return to the golden past, and yet never gets the love that new client side spa messes end up attracting.
htmx was a mashup of $.load(), pjax and angular 1 style attributes (very different conceptual model but I saw how angular used custom attributes and thought that looked better than the JavaScript api I had cooked up)
later on I figured out that what I was doing was generalizing hypermedia controls, but that took me years to figure out.
Turbo is more or less a continuation of Turbolinks, which has been around for ages. The Turbo repo goes back to 2015 (htmx starts in 2020), but Turbolinks is many years older. Of course there have been other "htmx-like" frameworks before; who even knows who or what was first at this point?
I don't think "feels like 37 Signals took the same idea and is trying really hard to sell it" is very fair (I've never seen them try to "sell it" at all, much less "very hard"). Regardless, you're allowed to "steal" ideas.
His mastery of millennial style memes is so rich. You can tell he just believes he is right and everyone else is dumb but he’s just “in it for the lols”.
I don't know _htmx personally, but I think he's more than willing to poke fun at those heavily invested in technology that is overkill for their needs. He most definitely is poking fun and laughing at the current mindset of javascript culture.
A good thread for understanding the different ways people think of it. I always go with @speg's interpretation, because the pejorative meaning just isn't used that frequently on HN:
> I tend to rethink of it as "the featured article".
In fairness to the commenter, I don’t know either of the projects but htmx’s _page_ is way less marketing focused that hotwire’s page. The hotwire page’s marketing is crazy: ‘turbo’, ‘stimulus’, ‘strada’…
Crazy but yet commendable.
Yes, they are. And the product names are an artefact of the marketing effort.
By ‘crazy’ I mean ‘crazy good / near over the top’ effort marketing.
Agree they both look good products. But put the websites side by side and ask what page has had more marketing effort put into it and I’ll think you’ll see the commenter point.
I'm curious as to what people think is the appropriate amount of time to wait before reposting the same story.
I know people complain about any and all reposts in the first place (https://xkcd.com/1053), but obviously there should be a priority on teaching people things they didn't already know instead of punishing people that never read old news.
You may have noted this from my links, but just in case—when I say the htmx has a lot of submissions I'm not referring to duplicate submissions, I'm referring to dozens of different submissions of different projects using or adjacent to htmx.
Re: the meta question, dang's policy that he repeats a lot is that reposts are fine every year or so [0]. Individuals may obviously disagree, but that's the rule that's actually enforced.
Personally I also find value in those posts even if knew about those technologies before. I often find interesting and up-to-date information or opinions in the comments.
Can I come live in whatever bizarro world you're in? I've never heard of Hotwire before but I'm up to my ears with htmx this and htmx that. It's impossible to spend a minute on Youtube without seeing programmer influencers with their moronic thumbnails featuring their face twerks next to htmx.
I researched it yesterday and there are differences, htmx is a lot lower level, hotwire cover only some narrow usecases but from a high level, and finally unpoly is highlevel with a lot of usecases coverage
It’s pretty marketed though. That’s why it has become more popular than Unpoly, which has been around for longer, was not rewritten 10 times, and has a lot more useful features.
For those looking for something similar in PHP/Laravel, I strongly recommend checking out Livewire:
https://laravel-livewire.com/
I still use React for more complex projects but it’s always a breath of fresh air to be able to write everything in Blade/PHP while keeping the reactive UI elements.
Edit: Although I have not used, I remember seeing this package which lets you render React/Vue components within Livewire when you need it: https://minglejs.unitedbycode.com/ an interesting escape hatch for when you want to pull in existing packages
I used to be really negative on Hotwire/Livewire but I now realize it’s a horses-for-courses kind of thing. Sending partials over the wire is a hypermedia thing, and I just don’t write hypermedia apps nowadays. It was htmx and re-reading RTF’s REST paper that got me to this place: I still don’t think hypermedia is inherently the superior architecture, but it is a legit peer among several, and it’s nice to see it keep evolving, even if slowly.
This is by far the easiest way to do PWA without getting into the rabbit hole of react/Vue/svelte. I used them, and are awesome, don't misunderstand me.
While comparing with htmx it feels more developer focus than tech focus, but I believe the race between the two will depend on which one is integrated with your backend framework.
Maybe if one’s mobile apps are just a WebView. Otherwise you’re maintaining a REST API for the mobile apps and the Hotwire/Livewire request handlers that deliver html fragments.
IMO PWA is a client issue and should be handled client side without introducing server dependencies.
The difference is developer behavior that each framework encourages.
While htmx/turbo focus in just couple of helpers and then leave you with the full HTML/JS, in a react ecosystem you end having with 3 party components, and a state management system and build system that will change in 10 months. I don't say it isn't justify and that it have its pros, but it's a rabbit hole in my experience, where you easily end fighting with the framework than focusing on business.
Huh, there hasn't been a significant change to our build system for our React application in the last ~5 years. Same is true for state management (redux). Our users include half of fortune 100 companies.
Really don't understand the argument that React apps must be rewritten all the time. Most of our code is still old class components that still work in the latest version of React.
I can’t speak to React. But with Vue it’s been like this. Vue 3 we’re not deprecating the Options API. And we’re not recommending the Composition API. But if you read into that you can mix and match the two, any pain you experience in the corner cases where they don’t play nice, well, that’s on you. All of your Vue 2 components might work but not really. Also the Vue 3 versions might happen. We’re switching from WebPack to Vite as the build system. (Does Vite actually use WebPack as a component, a question that lingers in the back of my mind) Oh and now the “CJS build” of Vite is deprecated so you’ll need to go from TypeScript 4 to 5. Your IDE may or may not work with the new Vue-specific tslint infra and when you’re done sussing that out now you find code that worked just fine in your previous build is rejected when you do a npm run build (no longer prod btw).
Can you imagine needing to fix a bug requiring a dependency (upon dependency and so on and so on and so on) update on code you haven’t touched for a year and suddenly having a herd of Yak like that need shaving?
Vite uses esbuild for fast dev builds and Rollup for production bundling, not webpack. Once the Rust port of Rollup is ready (called Rolldown) it is likely Vite will migrate both dev and prod bundling to that.
Re: Typescript 4 => 5 that should be a trivial migration. All we needed was to bump our node version IIRC.
And yes I can imagine the sort of bug you describe, because I'm the guy who fixes these sorts of things on my team. Usually just a few hours of head banging once or twice a year. Though the apps I've built on Vite have never required this. Really cannot recommend Vite highly enough for web frontend tooling.
Yes getting the JavaScript community to just STFU when it comes to revising for the sake of revising is an entirely different issue. Some day they will have to maintain something they haven’t touched in 5 years and then they will learn. Well, some of them.
yeah, just a couple of them, like 11 core html attributes and 25 additional html attributes, oh, also some events and also a JavaScript API. So easy to remember compared to 7 scary react hooks.
It's sort of in between. I wrote a browser extension (in Arc btw!) that has Emacs-style keyboard shortcuts that let me do things quickly. I look via HN search for related past submissions, open the relevant threads en masse in browser tabs, and build a list of IDs of the ones that are interesting. Then the browser extension sends the list of IDs to the server and gets back formatted text like you see in those lists ("title - link - mm yyyy (n comments)).
We’ve come almost full circle. I remember using this approach back in 2005 or 2006 by intercepting clicks and appending a parameter that just returned rendered html partials that just .innerHTML replace the main contents.
Sometime in the early 2000s, before AJAX was a thing, Adam Rifkin showed me a demo from his startup KnowNow that was achieving the then-mind-blowing thing of a web page updating itself without refreshing. Their trick was to keep the HTTP request open and the server to send occasional updates. More HTML. I don't think they could even manipulate the DOM back then, it may literally have been a page that just never closed the <html> tag.
I did something similar (same time frame) that definitely manipulated the DOM, but I didn’t keep the HTTP connection open, I used hidden Iframes. Clicks got redirected to the iframe, which returned <script> elements that would replace DOM elements (in the parent frame) using their .innerHTML.
AJAX streamlined the process, but there were a lot of hacky ways to get similar dynamic HTML effects. I like the idea of keeping the HTTP connection open, but that seems quite resource intensive… particularly for the early 2000s.
This technique is called COMET. The very first web chat that I used way back in 1996 was COMET based, tho the term hadn’t been coined yet. It was the chat room on Sierra Online’s website. The app had two frames, one for the input field and another for the room feed, which was a long running connection. No JavaScript, just a never ending HTML page. I suspect the backend was written in Perl, as it was a cgi script.
Basically the server sends a multipart content type header, never sends a content size, and simply doesn’t terminate the connection, so the browser just waits patiently for more parts and renders them as they come. My team experimented with it a bit back in 2000 for doing what would eventually be termed JSONP Streaming. It was really cool tech, but we didn’t have a practical application for it.
It was fairly easy to communicate between frames with JavaScript, so before this was widely adopted, I remember the way we used to “fetch” new data was with an iframe that always had a meta refresh tag in it, and the server response would include JavaScript that would call into functions from the main window passing along any data that was needed.
I might be wrong, but I think even early versions of Gmail did something similar.
People were definitely experimenting with it before that. Developers were mostly using it to load direct server-side snippets of HTML, dynamically. It took the evolution of SOAP and (especially) JSON/RESTful APIs for it to start seeing mass adoption as the combined technology of "AJAX".
Prototype.js and jQuery had a big hand in the latter.
what made Gmail memorable was cross browser ajax. Prior to, you had things like OWA but it only worked right in IE.
The big inbetween OWA and Gmail, was Oddpost, which was also IE only, and was purchased by Yahoo three months after gmails April Fool announcement, to become Yahoo Mail. In a roundabout way, you can argue gmail was a copy of what was eventually Yahoo Mail.
Rather than come full circle, I think it's more accurate to say that the different web UI paradigms are expanding their scope. Server rendered frameworks are making it easier to do client interactivity, and React is making it easier to do server rendering (via RSCs).
For highly interactive web apps you would still benefit from a SPA since that's what they're designed for.
I feel like everytime Hotwire and similar libraries get posted we hear this, but the reality is simple CRUD w/ AJAX never went away… Sure theres loads of SPA projects out there but that doesnt account for every single website ever.
I'm doing something similar with [1] where pagination (scroll down, click on "Show more") is implemented by requesting the next page as an HTML fragment from the server, loading it into an invisible iframe and once it finished loading, appending it to the current page.
We used to let people browse and page through photo galleries by preloading the next columns or rows of photos, then on click URL swapping under the static HTML page grid. The order you replace the URLs gives a visual of a paging motion.
And for infinite pages, a long forgotten technique: for scrolling or continuing content, you could use "multipart" since the 90s, effectively streaming the additional page content to the user as you got more bytes to send them.
Yeah I was really into Wicket in late 2000s and while I personally liked it and hated JS, managing UI state and templates on the server was always kind of a foot gun for performance and scale in a team environment. Really hard for me to be excited about this approach again, especially after all the improvements to web, JS, and TypeScript in meantime.
I haven’t worked with web apps that need highly interactive frontends, but for our e-commerce stores and internal rails apps turbo and stimulus have really lowered the bar on how much new developers must learn to build a nice to use website.
If you keep your stack simple, it's never been THAT hard. For example, with one Django project, I spun up whole office-facing tools using the tried and true KnockoutJS - which is kind of in the spirit of HTMX (and so is the still nascent Arrow.JS).
Most of the complexity, especially the UI part, has been self-inflicted. The old ways are very much not outdated, and are actually coming back.
There is a whole young generation of devs who came into the job at the stupidest possible time, when the industry convinced them that every web application has to be an overcomplicated, insufferable mess.
So... I'm a paying customer for Hey since it launched. And frankly, if the experience of the Hey webapp is an example of the best of Hotwire, no fucking thanks. On a slow connection, it's bad. Maybe that's the developers not adding loading or error states. Maybe it's just a lot of complexity. Maybe it's bugs in Hey. I don't know, but it's not good.
In the face of medium-high latency, stuff behaves in an unpredictable/buggy way. Boxes open with no content. Links don't work like you'd hope. Lots of actions in quick succession don't abort in a way I'd find intuitive. It just feels off.
As bad as an SPA might be, this is a step away from UI feeling native and natural, in my opinion.
It created a bunch of heated conversation (DHH saying the original video was throttled, other people saying Hotwire is too reliant on the network if a modal needs time to load, people defending Rails/Hotwire, people disagreeing with its approach, etc...).
Basically, it's been a big topic on Twitter the past week.
It was. Author said as much: "This is slow on purpose asa demonstration. This isn't meant to show the experience someone in SF on a fancy MacBook with Gigabit internet has. No matter which tech, they're good. It's about the person on a cheap laptop on slow mobile internet." https://x.com/noahflk/status/1795855075526471915
People also pointed out that the Google Calendar SPA is much slower.
And not like "SF Gigabit internet" and "highly throttled 3G" are the only two options...
The original post was highly misleading. Basically just a lie.
I'm checking out Hey and am finding it super zippy on my 600MBit connection, and still pretty usable on "slow 3G". What I'm not impressed by is DHH's snippy response, but having read DHH's outbursts before, neither am I surprised.
I last looked at Hey about a year ago and it seemed pretty snappy even from the the wrong side of the Pacific. The page architecture impressed me specifically ... things like, applying progressive enhancement to a details/summary/anchor element trifecta for a contextual menu overlay, and if you disabled Javascript or assets didn't load or whatever, it gracefully fell back to loading the menu content in a simple layout. There are a bunch of other well-considered uses of the Web APIs in there. I recall that practically all their client code was unobfuscated and source mapped, too, if you wanna take a look. I'm no fan of DHH and have no interest in boning up on his drama of the week, but it seemed to me that 37signals got it right this time.
I've used Hotwire for a few sites. I much prefer it to HTMX since it's significantly easier to implement.
My No-React tech stack is Alpine.js, Hotwire, EJS, and Express. Works very nicely for simpler sites.
Though for the majority of the sites I make, React wins almost every time since it's way easier to use as a templating and interactivity engine. And Tailwind works a lot better with React.
Turbo’s morphing is insane. With 2 lines of code: 1 in the model and 1 in the view, you can make any previously static page an instant updating multiplayer experience.
Very cool. It's interesting to see REST become REST again. Also cool to see this come from 37signals. I use Basecamp for a makerspace that I am a part of, and it works quite well for our needs.
It's perplexing to me that Hotwire isn't more popular. The main documentation site doesn't mention this prominently, but it's basically the canonical way to do this sort of stuff with Rails now, as it's all originally from Basecamp.
It may be intentional that it's relatively low key, or broader promotion is at least a non-goal of the project. But if you're still doing anything with jquery - rails or not - you owe it to yourself to look at this as a great replacement, and a very strong competitor to bloated client side frameworks for most webapps.
There are also helpers to build webview apps for both IOS and Android too [0].
Hotwire is the umbrella term for turbo, stimulus and strada. Turbo has client and server side components that enable easy ways to do partial page refreshes and send html templates (turbo streams) to initiate page updates from the server. That’s all without writing any js (using mostly data attributes and custom html tags, like turbo-frame).
Stimulus comes in as a small framework for the cases where you want to write some JavaScript, in a way that you still control the behavior from html, by attaching controllers to elements explicitly.
These two aspects are similar to htmx:
- send html from the server even for partial page updates
- encode desired js behavior into the html
The main difference is that turbo is designed with a convention over configuration attitude, as many of it’s behaviors are automatic (like intercepting all form submissions and handling them using fetch, preventing a full page reload). When custom js is needed Hotwire defers to letting you write actual js code, htmx has this tailwind style shorthand that allows you to basically write js from the html.
I’d add - stimulusjs lets you write your own htmx-like functionality by providing a convention for triggering and passing data to js via html data attributes.
The stimulus JavaScript controllers (not to be mistaken with the Rails mvc controllers) are reusable and nest-able which makes them very powerful and quite fun to write.
I love the idea of Hotwire and I'm already using it in one of my production project. Overall it saved me a lot of time and frustration having to deal with a separate frontend project, and the frustration having to manually manipulate the DOM with JavaScript in traditional MVC project.
However I faced some other new frustration, such as when trying to make a dynamic nested form (similar to cocoon gem) but only with hotwire stack (turbo frame/stream). It is also hard to think of each hotwire controller as a component, you might face some problems when trying to do some nesting.
I think Hotwire will be a perfect fit if you want a traditional websites with a few dynamic, interactive features. If your website is too much app-like, you should consider switching the frontend part to SPA entirely.
For frontend, one has to decide - am I making a website (informational pages) or an app (interactive widgets) ?
For a website, SEO is important hence good ol html server rendering wins. There isn’t much interactivity.
For an app, how fast UI responds to user input matters. This is where JavaScript shines because interactive logic lives in the client device. User could be under a tunnel or offline, and a well written app will work.
Hey app had some Twitter discussions (can’t find thread), that it slows down to respond to clicks on 3G speeds. Because it had to call the server to load what UI snippet to show to user.
Essentially - choose the tech that fixes the best user experience.
A bit late to the party here, but I’ve used Hotwire for a little while now.
Turbo is wonderful and seemingly straightforward, but also has some real hidden gems that aren’t well-documented (a problem which plagues Stimulus as well).
Stimulus is also great, but you can’t go into it expecting React. State management can get very tedious.
I use Turbo and Stimulus for most interactions in my current project, but I pull in Preact and HTM where I really need them. It’s trivial to have a Stimulus controller mount a Preact component and sync state between them, so it’s all very transparent.
I passed the video to GPT4o through Kagi and then asked "What is Hotwire and how does it work?" and got a satisfactory write-up. I can email it to you if you'd like (I think posting LLM generated text here is frowned upon).
It does once you dig a little into the documentation, you need to click past the first two pages of self-flattering and you’ll see that it’s mostly just going back to writing old world JavaScript.
Yeah your comment ironically points out the issue (at least I have) with this - you are maintaining state on a server, and so messing with a UI isn't just dealing with local UI state.
I'm no JavaScript fanboy, but I'm also not bent on avoiding it at all costs shrug.
I’ve been using Hotwire for a greenfield project for the last year. The hotwire framework they’ve created is pretty nice but I miss React and will probably choose it for my next project.
Not just because it’s decoupled from the backend api. The React/Vue ecosystems have a lot more useful open source components, and you can build faster, more cache friendly front ends, among other benefits.
I agree React is more complex, but as with many things if you are gonna need it then it’s great to have started with it.
I appreciate there are projects which will hit no limits with the Hotwire/stimulus/turbo mix. I’ve worked on them before and would choose Hotwire when appropriate (eg for government services Hotwire is perfect).
The SSR vs CSR debate is quite tired and played out at this point, and doesn’t lend itself to thoughtful threads… While hotwire does make it easier to do SSR with progressive enhancement, for some projects it’s easier for me to just build a single “enhanced” experience with React (for performance, ecosystem, and IME UX).
Here we go again! I have been using it 15 years ago.
I am a user of Hey and what I can say is the UX is dreadful. I am seeing spinner way more than I can handle, really.
I assume this proposal is to moving backwards.
Instead we would need to sort of data on client and full-body client app, doesn’t matter if it’s for web, ios, android. And the data should be given back to us - users.
The problem with that is that services like Hey become a true commodity and doesn’t lock users by keep exclusive access to their data anymore. So it’s to be figured out what is the new business model.
ASP.NET WebForms had an "Ajax component" called UpdatePanel, that was just a div and a HTTP call to rewrite the whole div from server. Seems like the same to me :D
It's insane to me we simultaneously have LiveView, LiveWire, and HotWire, all referring to somewhat similar but different frontends... I guess that's really LiveWire's fault for most recently combining those names, otherwise the other two would be distinct.
Phoenix live view is awesome. If you use Phoenix that's the way to go. If you don't want to go to the erlangvm, htmx or hotwire/turbo are the only options I would consider.
I thought “HTML over the wire” was literally what the web has always been about from the very start.
Even if you redefine “the wire” to “XHR requests” or “Ajax requests” it’s still weird to treat this as a revolutionary thing since the “X” in XHR and Ajax is “XML” which is just a sibling markup language to HTML.
Also, IIRC the original Rails approach to Ajax like 15 years ago or so was sending page partials like this.
It feels like we’re going in circles.
(I’ve also never been impressed with their “turbo links” which just seem like “we think we can do caching better than the browser makers” and thus dubious. Core Rails seems great but I’m always wary of this stuff at the edges with the extra dollop of hype.)
Most dynamic websites do not pass html for updates, the communicate with a backend using json (normally) and the frontend figures out what to do with that data. Hotwire is about removing that JavaScript layer, to have a dynamic app without a heavy UI framework.
wait, is that a directory of dynamically loadable web content thats interactive i can surf? please i do not know the old ways, i only know they were forgotten :(
Second, I actually thought the same as you but digging into the history I don't see any records of a public release of Hotwire until December of 2020, and HTMX was public in May of that year. Both commit logs and first HN submissions are in agreement on those dates, but if you have other evidence I'm open to it.
I'm pretty sure what I was thinking of was actually Turbolinks:
As noted by @madeofpalk [0], Hotwire is the successor of Turbolinks, which dates back to at least 2012 [1].
That said, I'm not particularly interested in litigating who inspired who. Both libraries are neat and have developed in parallel for ten years. That's cool!
For what it's worth, I mentioned HTMX to a Ruby developer friend, and his reaction was "oh, like Turbolinks", so I think the mindshare was probably there first. That having been said, HTMX is my preferred way of making dynamic frontends now. I've never been a React developer, but I've always found SPAs way, way overused.
Yeah, Turbolinks was huge throughout the Rails era—I remember it even being part of the random beginner tutorials that I did back in the day. I only ever heard of intercooler.js after htmx was announced.
I agree that that calendar doesn't seem great, and the problems do exist. However, adding tons of latency while saying you're not doing so in order to make fun of someone's work is either malicious or extreme lack of competence.
In the video he sets the chrome throttle option to slow 3G, and that adds large restrictions on bandwidth, and a ton of latency. He states that he is not doing so, and that adding latency can't be done in the browser. That is literally what the option does.
If you add seconds of latency then requests will take seconds, who would imagine...
A. The complaint about how every keypress goes to the server says literally nothing about HTML over the wire. It’s obviously how Hey chose to do things (or it was a bug), but Theo should be experienced enough to know that most approaches don’t need to be like this. Attributing a sloppy implementation by Hey onto a video about Rails as a whole is inflammatory.
B. And if he isn’t, and doesn’t realize that HTML over the wire doesn’t mean you can’t have any JavaScript, he should stop talking about what he does not understand.
C. This is personal taste, but a man with his hair style shows he can’t recognize good taste if it hit him in the face.
I don’t think you’re intimately familiar with the concept of maintaining state server side vs client side. The field is reactive, therefore under Hotwire/Livewire/etx state changes (aka ‘typing on keyboard’) require a round trip to the server to get the state updated server side and to get the re-rendered component to update the client. Could he perhaps have chosen a different reactivity model, perhaps, or maybe not. In any event this is a clear illustration of client-side vs. server-side reactivity.
This is why we abandoned DHTML 2 decades ago, invested in jQuery to encapsulate variations in JavaScript across browsers and worked hard on standardizing JS so you could write code once and have it work across vendors.
Or, as many approaches i.e. Livewire use, you can just use some JavaScript for basic interactivity, and send a non-trivial amount of state to the server in a batch rather than a request for each item.
This is how I’ve implemented my website. I am quite aware of how this is done, I suggest you look further into it.
I think that has more to do with the fact that he is paid for by Vercel than anything. He's mostly been saying negative things about Rails despite not understanding how it works.
Hi, I work at Vercel. We have sponsored some of the videos on his YouTube channel, but this is not one. And FWIW, I don't agree with the approach here.
Why does everything Theo touch go up in a flaming shitshow? DHH can be an inflammatory prick himself, but he just about balances it with competence.
I hate how there are JS influencers now. And I hate how they repeatedly cause drama for clicks. There will be a fresh idiotic topic bubbling up every few weeks. It will be semicolons soon, I am sure of it. I hate it.
It’s entertaining and he points to some bugs like race conditions that shouldn’t be there, but I’m not sure if it’s specific to Hoywire. Also his statement that DHH/Rails claim Hotwire is the only way, or that you cannot also use React or plain JS is just silly and disingenuous.
Nah, creating duplicate calendar entries because you did not receive visual feedback before getting frustrated and making another one sucks. Maybe watch the video instead reading the bullshit the narrative drivers are feeding you.
1. https://htmx.org/