Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hotwire: HTML over the Wire

hotwire.dev

Post reply on HN
Print view View original

31–40 of 573 posts

Re: Hotwire: HTML over the Wire

#31

Post by w_t_payne »

zomgwat wrote: post #23
fuball63 wrote: post #6

I read a little about Turbo, not sure I get it, is this like htmx? https://htmx.org/

They're similar in concept but Turbo uses WebSockets and htmx is more about AJAX.

I've been using HTMX to send "server push" updates over SSE ... I think it wouldn't be too hard to use websockets as well..

Re: Hotwire: HTML over the Wire

#32

Post by konha »

city41 wrote: post #12
corytheboyd wrote: post #7

I get the feeling it will draw a bit of criticism from this crowd. IMO it’s fine to experiment with tech like this, but I have to wonder where sending HTML fragments over Websockets instead of HTTP falls apart. Curious to hear about the success/horror stories in a few months/years from any adopters :)

I found this little thread on Twitter interesting, complaining Hey (powered by hotwire) is too slow https://twitter.com/youyuxi/status/1337851036015480843

The inventor of one of the most successful js frameworks might be a tad biased when it comes to the whole „as little JavaScript as possible“ thing.

Re: Hotwire: HTML over the Wire

#33

Post by deltron3030 »

My first thought was that some dude is ripping off LiveWire and Turbolinks because of the strange centered text (no professional web designer would do that), until I saw that those were renamed evolutions of those technologies from Basecamp, cool!.

Re: Hotwire: HTML over the Wire

#34

Post by save_ferris »

bschne wrote: post #28
JeremyBanks wrote: post #18

This kind-of tangential reply is in bad taste, but DHH is currently being an asshole about this very topic on Twitter, so: This seems cool, but the progress that HEY has made since launch isn't very impressive if that's the flagship example. HEY's search UX, which uses these capabilities, has been abysmal since the day it launched. It's a much better experience if you disable JavaScript/Hotwire and fall back to the s…

I‘d be curious to hear about your general experience w/ hey - from the outside it looks like it has some cool new(er) approaches, but I‘ve seen someone‘s actual full email account in a screencast once and it looked like it‘d get messy with actual heavy usage really quickly and the UX might deteriorate. Any takes?

Not OP, but I have a Hey account and I really enjoy it. The screener feature is worth the price alone IMO. The biggest challenge for me was having to re-conceptualize email after switching over since Hey doesn't use traditional email terminology (i.e. "paper trail" vs "archive").

The amount of inbound email I get has dropped immensely due to the screener and my inbox ("imbox") is so much easier to manage with Hey, IMO.

Re: Hotwire: HTML over the Wire

#35

Post by kfk »

elamje wrote: post #26

This is the Ruby on Rails version of what Elixir Phoenix Live View and .NET Blazor do. For those not familiar, rather than using a standard web framework where a lot of processing is done client side, these frameworks allow html buttons etc to call native Ruby, C#, or Elixir functions on the server rather than using some sort of post/get request to do that. Every UI interaction goes over the wire, which is where perf…

It depends right? If your app is a dashboard this could be less work when using smart cashing. You could cache entire html fragments on the server for specific user defined filter values. If you are serving hundreds of users you’d have dashboard faster than most BI tools out there including PowerBI.

Re: Hotwire: HTML over the Wire

#37

Post by nlh »

Gotta give @dhh credit - he is one of the world's great marketers/promoters. He's been building hype for this as the "next Rails" for months and the man knows how to pique an audience's interest.

Re: Hotwire: HTML over the Wire

#38

Post by JeremyBanks »

bschne wrote: post #28
JeremyBanks wrote: post #18

This kind-of tangential reply is in bad taste, but DHH is currently being an asshole about this very topic on Twitter, so: This seems cool, but the progress that HEY has made since launch isn't very impressive if that's the flagship example. HEY's search UX, which uses these capabilities, has been abysmal since the day it launched. It's a much better experience if you disable JavaScript/Hotwire and fall back to the s…

I‘d be curious to hear about your general experience w/ hey - from the outside it looks like it has some cool new(er) approaches, but I‘ve seen someone‘s actual full email account in a screencast once and it looked like it‘d get messy with actual heavy usage really quickly and the UX might deteriorate. Any takes?

I find HEY's general workflow very good for my medium-volume personal email. It encouraged me to filter a lot more stuff out of my inbox than I did with Gmail, while spending less time configuring filters. The ability to leave internal comments on external email threads (business accounts only) is very useful as a first-class feature, instead of relying on fiddly BCC. The apps are quite nice to use. Overall, there's less clutter and it is a more pleasant experience than other email clients I've used... until I try to search in the Hotwire-powered web view.

Re: Hotwire: HTML over the Wire

#39

Post by dhh »

elamje wrote: post #26

This is the Ruby on Rails version of what Elixir Phoenix Live View and .NET Blazor do. For those not familiar, rather than using a standard web framework where a lot of processing is done client side, these frameworks allow html buttons etc to call native Ruby, C#, or Elixir functions on the server rather than using some sort of post/get request to do that. Every UI interaction goes over the wire, which is where perf…

I get the rush to provide technical comparisons to something that was just revealed five minutes ago, but none of what you just said is actually how Hotwire or Turbo works. There's no client DOM in memory on the server, there's no html buttons that call native code.

There are forms being submitted, there are normal requests happening, there are templates being rendered on a per-request basis (just like a full page load).

This is like a normal web application that renders HTML, from the perspective of how the server works. Just as scalable as every other Rails application that renders HTML. Be that GitHub or Shopify or Zendesk or Basecamp or HEY or any of the many, many other apps that have long ago definitively proven that Rails Scales.

Although I do find the commentary that the current #1 comment on the HN thread is literally a "bUt DoES iT SCaLE??" take, based on a misunderstanding of how this works. All is indeed as it's always been

Re: Hotwire: HTML over the Wire

#40

Post by axegon_ »

mmastrac wrote: post #4

What's old is new again. I recall ASP.NET had some interesting tech around this in the 2000s where it could dynamically update parts of the page. If I recall correctly, this made use of that new technology of the time called "XMLHttpRequest" (/s) which pretty much jump-started web 2.0.

My thought exactly, though I fully support that. I often rant about how the modern web is billions of layers of duck tape over duck tape and it has become an unmanageable mess of libraries, frameworks, resources, all while javascript remains the most outrageous and absurd language ever created. I'm by no means a fan of rails or ruby for that matter but I think things like these are a considerably better alternative than all the ridiculous libraries and frameworks everyone uses, which result megabytes of javascript and require corporate-grade bandwidth and at least an 8-th gen i7 and at least 8gb of memory to open. And all that to open a website which has 3 images and a contact form. I mean someone should create a package that analyzes websites and creates a minimum requirements manifest. It's good to see that there are people who are trying to bring some sanity.
Post reply on HN