This sounds a lot like server-hosted Blazor, streaming HTML snippets though websockets. Am I understanding it correctly?
Hotwire: HTML over the Wire
11–20 of 573 posts
Re: Hotwire: HTML over the Wire
#12I 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
Re: Hotwire: HTML over the Wire
#13I 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 :)
It falls apart in environments where WebSockets doesn't work, unless there's a fallback mechanism using XHR.
Re: Hotwire: HTML over the Wire
#14Is this just PHP templating with extra steps?
Re: Hotwire: HTML over the Wire
#15It sounds a lot like Laravel Livewire[1]
Also a lot like React Server Components that we saw on HN yesterday[2]
It seems like this is the next wave of web apps. Hopefully once the hype settles, we'll be able to decide which approach is best for which project.
Re: Hotwire: HTML over the Wire
#16Sounds like Phoenix LiveView. I love phoenix <3
Re: Hotwire: HTML over the Wire
#17These folks literally invented Ruby on Rails and were building web applications for over 20 years now. This tech seems "old" but it's solid.
Re: Hotwire: HTML over the Wire
#18This 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 server-side-rendering instead of the hybrid mess they push down. I'm very disappointed that this hasn't been improved. (I sent feedback about this while they were still in their invite-only phase.)
We were also promised custom domain support by the end of the year, and we don't have a timeline or even pricing yet. (That's obviously backend and unrelated to this announcement.) I don't want to go back to Google, but the lack of improvement isn't giving me a lot of confidence as a HEY customer, so I'm considering alternatives.
Re: Hotwire: HTML over the Wire
#19It's hilarious that web servers rendering HTML and sending it to the browser over a TCP connection is now "cool new tech".
It's actually not as simple as that. The simplification is too brutal and doesn't appreciate the details.
It's the answer for people that sick of the weight of modern webapp, where everything need to be rendered client side.
Re: Hotwire: HTML over the Wire
#20What'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.
AjaxContentPanels or something to that effect. Those things were a nightmare. At the time, asp.net pretended to be stateful by bundling up the entire state of the page into "ViewState" and passing it back and forth client to server. Getting that to work with those panels was more work than just ajax-ing the content and injecting it with jquery.
In the Microsoft-verse, this might also draw some comparisons to the more modern server-side blazor.