Hotwire: HTML Over The Wire

by bpierre • 2 years ago

244 160 2 years ago

Zambyte2• 2 years ago

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.

agumonkey• 2 years ago

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

cpursley• 2 years ago

LiveView is the OG of this approach:

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

reducesuffering• 2 years ago

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.

chuckadams3• 2 years ago

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

cientifico4• 2 years ago

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.

cientifico4• 2 years ago

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.

scosman• 2 years ago

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

cientifico4• 2 years ago

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.

CodeWriter237• 2 years ago

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.

cientifico4• 2 years ago

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.

whartung• 2 years ago

How does this contrast to htmx?

one-punch2• 2 years ago

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.

fxn3• 2 years ago

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

felipemesquita2• 2 years ago

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.

andrei_says_2• 2 years ago

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.

eduction2• 2 years ago

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

nilamo• 2 years ago

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.

eduction2• 2 years ago

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

leviathan2• 2 years ago

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.

ggeorgovassilis• 2 years ago

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/

Terretta• 2 years ago

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.

NelsonMinar2• 2 years ago

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.

eurleif2• 2 years ago

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

skeeter2020• 2 years ago

Internet Explorer 5 introduced XMLHttpRequest (ActiveXObject) in 2001.

mbreese• 2 years ago

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.

marwis2• 2 years ago

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

ChiperSoft• 2 years ago

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.

nosefurhairdo3• 2 years ago

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.

gedy2• 2 years ago

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.

giancarlostoro• 2 years ago

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.

felipemesquita2• 2 years ago

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.

renegade-otter• 2 years ago

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.

brink• 2 years ago

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

bityard• 2 years ago

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.

devjab• 2 years ago

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.

gedy2• 2 years ago

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.

danlugo922• 2 years ago

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

Zambyte2• 2 years ago

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

tholman• 2 years ago

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

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

dang2• 2 years ago

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)

Akronymus• 2 years ago

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

gkoberger• 2 years ago

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.

dewey• 2 years ago

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

mardifoufs2• 2 years ago

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

ChrisArchitect2• 2 years ago

Thx for context!

inopinatus2• 2 years ago

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.

leo-tada• 2 years ago

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

arp2422• 2 years ago

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.

retrac98• 2 years ago

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.

navs• 2 years ago

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

DoesntMatter224• 2 years ago

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.

claudiug2• 2 years ago

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.

NorwegianDude• 2 years ago

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

gjsman-10002• 2 years ago

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.

CodeWriter237• 2 years ago

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.

eviks• 2 years ago

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.

gingerlime• 2 years ago

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.

CodeWriter237• 2 years ago

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

DandyDev• 2 years ago

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

claudiug2• 2 years ago

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

gherkinnn• 2 years ago

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.

start123• 2 years ago

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

koolala2• 2 years ago

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

lxgr• 2 years ago

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

koolala2• 2 years ago

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

danlugo922• 2 years ago

This is the future

Alifatisk• 2 years ago

I would rather call it an alternative approach to SPA

chuckadams3• 2 years ago

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.

BillFranklin2• 2 years ago

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.

buf• 2 years ago

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.

BillFranklin2• 2 years ago

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

big_hacker2• 2 years ago

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

chrisvenum• 2 years ago

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

mosselman• 2 years ago

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.

65• 2 years ago

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.

carom2• 2 years ago

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/

DoesntMatter224• 2 years ago

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.

lolinder4• 2 years ago

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

carom2• 2 years ago

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.

ranger_danger• 2 years ago

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.

creativenolo2• 2 years ago

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.

wicz• 2 years ago

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

lgvld• 2 years ago

Quite complex though.

big_hacker2• 2 years ago

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

MrOxiMoron• 2 years ago

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

andrewstuart• 2 years ago

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

taberiand• 2 years ago

Grassroots evangelism != marketing

Fire-Dragon-DoL• 2 years ago

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

anfogoat• 2 years ago

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.

SergeAx• 2 years ago

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

0xblinq• 2 years ago

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.

ChrisArchitect2• 2 years ago

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

dopp0• 2 years ago

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

jrs235• 2 years ago

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

fofo44• 2 years ago

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

llmblockchain• 2 years ago

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.

josephernest• 2 years ago

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 !

gardenhedge• 2 years ago

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

recursive3• 2 years ago

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

focom• 2 years ago

You should look at django-unicorn for the python equivalent

andros• 2 years ago

Or Django LiveView

olebedev2• 2 years ago

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.

DoesntMatter224• 2 years ago

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

olebedev2• 2 years ago

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.

bastawhiz• 2 years ago

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.

graftak• 2 years ago

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

JodieBenitez• 2 years ago

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

nojvek• 2 years ago

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.

JeremyNT• 2 years ago

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/

castaigne• 2 years ago

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.

fs0c13ty00• 2 years ago

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.

Hotwire: HTML Over The Wire

Related Stories