Hotwire: HTML Over The Wire | Hacker News Reader

Hotwire: HTML Over The Wire

hotwired.dev

244 pointsbpierre167 comments

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.

1. https://htmx.org/

HTMX probably has the best marketing of any framework. The twitter is very active, it's all over The Primeageon's youtube channel. It's quite popular.

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.

[0] https://hn.algolia.com/?dateRange=pastYear&prefix=true&query...

[1] https://hn.algolia.com/?dateRange=pastYear&prefix=true&query...

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.

Live views in Phoenix were way before both.

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.

Meteor, Ember, Derby were the "next big thing" 10 years ago.

Principles of Rich Web Applications (rauchg.com) Nov 4, 2014 https://news.ycombinator.com/item?id=8559519

https://www.infoworld.com/article/2612250/application-develo...

https://shiggyenterprises.wordpress.com/2013/03/11/picking-a...

https://blog.emberjs.com/inside-fastboot-the-road-to-server-...

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.

Pjax, 2011. We can probably keep going back further. No-one has a monopoly on this idea.

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.

why does this matter ?

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.

I definitely don’t think everyone else is dumb, or that htmx is right for everything, or particularly novel.

I do enjoy the lols I will admit that, hopefully as much at my own expense as anyone

A bit presumptuous of me. Maybe it's just me that thinks you're smarter than everyone else.

What’s TFA?

The fucking article

This is how I've always understood it.

Not pejorative btw - just a phrase to refer to the current article.

https://news.ycombinator.com/item?id=19781756

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".

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.

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.

[0] https://news.ycombinator.com/item?id=40523838

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.

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.

Aren’t those just product names? They don’t strike me as crazy.

Hotwire and htmx both look like good products to me.

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.

Also worth mentioning https://unpoly.com which packs other features.

Quite complex though.

The last commit on Github was 2 days ago so I think it's safe to say this is a dead project.

the Django community is pretty vocal about htmx too (in a good way)

Less marketed? I’m flooded with htmx on every social platform.

Grassroots evangelism != marketing

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

> A way less marketed version of this is htmx

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.

Can you post links to some interesting go/htmx projects, please?

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.

What makes this less of a rabbit hole than the alternatives you mention?

If you have discipline, probably none.

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.

Lol react has been more stable than rails.

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.

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.

For sure, there are cases in which a PWA focus is to add offline support, and you are totally right there.

However, I will argue that 80% of PWA exist to have proper push notifications, or faster development than native.

Here's the HN conversation from 2020 [1], a little closer to when this came out.

- [1] https://news.ycombinator.com/item?id=25507942

Thanks! Macroexpanded:

Hotwire: HTML over the Wire - https://news.ycombinator.com/item?id=25507942 - Dec 2020 (545 comments)

Also related:

Why Hotwire Could be the Future of Front-end Dev - https://news.ycombinator.com/item?id=26195969 - Feb 2021 (6 comments)

Hotwire: A new old way to build web apps - https://news.ycombinator.com/item?id=25942864 - Jan 2021 (56 comments)

How does the macroexpansion actually work? Does it automatically grab the relevant links, or do you have to manually get them?

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)).

(This comes up a lot! https://news.ycombinator.com/item?id=35668525)

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.

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.

[1] https://animasci.com/

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.

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.

Well, you could manipulate the DOM with that technique by sending <script> tags to do so.

Internet Explorer 5 introduced XMLHttpRequest (ActiveXObject) in 2001.

Yes, but developers weren't widely aware of its power until the launch of Gmail in 2004, and the term "AJAX" wasn't used until 2005.

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.

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.

Below is an interesting read about the history and evolution of XMLHttpRequest.

Started in 2000 in Exchange/Outlook web and took a year or two to become prevalent in the browsers and other places.

https://medium.com/@mohamedtayee3/make-an-http-request-in-ja...

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 is how AJAX in Java Server Faces used to work nearly 2 decades ago. There were even more fancy technologies like https://www.icesoft.org/wiki/display/ICE/Direct-to-DOM+Rende...

I bet ASP had something similar too around the same time

I meant to reply to GP about partial updates rather than parent post about keeping connection open.

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.

Thank you, I'd forgotten that name Comet. Wikipedia has some more info: https://en.wikipedia.org/wiki/Comet_(programming)

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.

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 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 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.

Having worked with Stimulus, I can safely say it's hot trash and will never use it again. Hotwire was good though.

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.

For anyone curious why this is popping up now:

Last week, someone posted online how Hey (created by DHH, who also created Hotwire and Rails) is slow when opening a modal: https://x.com/noahflk/status/1795758603577545035

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.

Direct link to DHH's response: https://x.com/dhh/status/1796163806650868149

For context, people have been able to reproduce this with gigabit connections too.

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.

Thx for context!

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.

They've fixed it. You can check out the update here: https://x.com/dhh/status/1797370923391357143

> DHH saying the original video was throttled

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.

With the same idea but more minimalistic, I have done Swap JS two years ago :

https://github.com/josephernest/Swap

Used it for a few projects it works well !

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.

In the same vein, I've used Unpoly: https://unpoly.com

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].

[0] https://strada.hotwired.dev/

How does this contrast to htmx?

Hotwire integrates with Ruby on Rails. (EDIT: The linked page shows how to integrate Hotwire with Ruby on Rails. See fxn's comment https://news.ycombinator.com/item?id=40555577)

I had the same question, then watched the video to get the answer.

No, Hotwire is framework agnostic it is web components and JavaScript, basically.

You can Google Hotwire with Django, or Laravel, or many others (https://hotwire.io/frameworks).

Thanks for the information.

The linked page shows only integrating Hotwire with Ruby on Rails, giving me my original impression.

Some links do not have information yet, others do, for example https://hotwire.io/frameworks/laravel or https://hotwire.io/frameworks/django.

> framework agnostic

Framework agnostic but Ruby-only it seems.

No.

No. Turbo is js and HTML.

If your backend can send templates down the websocket, you can use Hotwire.

Hotwire is in JS and is used by multiple back-end frameworks including Rails.

Rails has a lot of affordances for Hotwire and is the back end framework for which Hotwire was originally written.

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.

For what it's worth, Hotwire isn't very interesting. The real magic is in Turbo or Turbolinks (the pre-Turbo version of Turbo).

Turbolinks is the HTMX-Boost before HTMX was HTMX.

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.

It looks like the only way to get a sense for what this does and how it works is to watch videos? If so, blegh.

Surprised something like this wouldn't have any example code or demos to look at.

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.

It’s really very disappointing.

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.

It's html over a websocket. What is there to understand?

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).

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.

Like what?

I also use Hotwire/Stimulus and haven't run into any issues yet. Happy to share links with you on anything I know about.

> Like what?

Not sure what this is in response to, sorry.

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).

If a truck uses more gas than a car while going at the same speed, is the truck more gas-friendly?

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.

If you dislike it so much why do you still use it? Just curious.

It’s too much of a hassle to move from it now, since I have alot on my plate and they don’t support any other GUIs (a classic vendor lock).

I have planned it for the second half of this year though.

Great library that’s let down by its documentation. It’s very hard to figure out how to do things in Hotwire without a YouTube tutorial.

Glad to see this is getting attention again. But for those that don't know, this is several years old. See https://news.ycombinator.com/item?id=25507942

I must be missing something but React seems more straight-forward than this.

Different points of view. To me react seems like the least straight forward way of making a web app I can think of.

Been some developments since 2020, this isn't new.

Context for why this might be coming up now:

https://news.ycombinator.com/item?id=40555541

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

I understand that hotwire is already an established term but it has hacky connotations and hyper(textlanguage)wire sounds infinitely cooler.

There was some news about phoenix, which seems to use similar approach. More on the backend, direct computed view elements sent over websockets.

LiveView is the OG of this approach:

https://phoenixframework.org/blog/phoenix-liveview-1.0-relea...

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.

So I guess if you’re looking to start a new frontend framework with the same principal, name it HotView?

I recall Java Server Faces had something similar long before. But the JSF architecture was so twisty that it wasn’t ever that practical.

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.

all my 6 websites are using Hotwaire framework. and I love it

You should look at django-unicorn for the python equivalent

Or Django LiveView

This is the future

I would rather call it an alternative approach to SPA

Is it me or does it look like JSP/ASP all over again?

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.

Yes obviously. It wouldn’t have made sense to say “we are going in circles” otherwise!

Can we rip down all the "Don't use Eval() in a web browser" warning signs from 30 years ago yet? F of X FFS

This isn't using eval() in a browser, this is /cgi-bin/ :)

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 :(

Click scripts ran on the server. Often written in perl. Standard output was redirected to the user agent and showed up as HTML.

CGI scripts that is.

Theo dug into Hey and Hotwire only a day ago and has a less than flattering take. Not on the concept necessarily but some implementations.

https://m.youtube.com/watch?v=5jIwILYjXrU

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.

if this is real, that is sad from vercel and sad for all the lunatics that listen to him. we move this yelling crap from politics to programming.

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.

Interesting. The way he said it I thought it was an ongoing arrangement.

Idk why he does videos like this because it ends up reflecting poorly on Vercel or other companies he's associated with.

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...

To me,

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.

B. The fact that he's aware there is still JS is obvious from the first minutes of the video and is repeated many times throughout.

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.

This should be the top comment. Unfortunately you’ve got the 37Bury Brigade out here in force. Mind your thoughts is their message.

Read the other comments. The video creator is literally adding artificial latency and then complaining about bad performance.

Watch the video, he does both no latency and introduced latency. And is quite up front about it. Nothing wrong with his methodology at all.

the app does not work, I dont have internet. the app and the owners are terrible developers. that sums the video.

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.

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.

Reply on news.ycombinator.com