Live data from Hacker News

Hotwire: HTML over the Wire

hotwire.dev

21–30 of 573 posts

Re: Hotwire: HTML over the Wire

#21
post #12

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

And here's some additional followup. Minor speculation that maybe his location is what caused slowdown.

https://twitter.com/swyx/status/1292825527116369922

Re: Hotwire: HTML over the Wire

#22
post #12

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

I got into the Hey beta, wound up purchasing it and I haven't had any performance issues to speak of. I'm curious to know what their setup is.

Re: Hotwire: HTML over the Wire

#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 performance can be hurt.

Having used Blazor in production for nearly a year, it speeds up development, but your server is doing a lot more processing and will not be able to handle an equivalent amount of users that a normal web app would because it’s keeping a copy of the clients DOM in memory. It’s updates the dom on the server then streams that update through websockets to the clients dom, creating your magic Single Page App experience.

I think it’s cool tech, but not necessarily scalable due to the increased server load. I’d be interested to hear from people using it to serve large orders of magnitude of clients at once.

Re: Hotwire: HTML over the Wire

#28

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?

Re: Hotwire: HTML over the Wire

#30
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…

Any idea how many people use Hey.com? That might be an early indication as to how scalable this is (at least for hotwire's concerns)
Post reply on HN