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
Hotwire: HTML over the Wire
21–30 of 573 posts
Re: Hotwire: HTML over the Wire
#22I 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
Re: Hotwire: HTML over the Wire
#23I read a little about Turbo, not sure I get it, is this like htmx? https://htmx.org/
Re: Hotwire: HTML over the Wire
#24Re: Hotwire: HTML over the Wire
#25Re: Hotwire: HTML over the Wire
#26For 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
#27Is this a joke? What's new about sending HTML over a TCP connection?
Re: Hotwire: HTML over the Wire
#28This 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…
Re: Hotwire: HTML over the Wire
#29Re: Hotwire: HTML over the Wire
#30This 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…