Is this a joke? What's new about sending HTML over a TCP connection?
For a minute I thought it was the html version of vanilla-js http://vanilla-js.com/
Hotwire: HTML over the Wire
51–60 of 573 posts
Re: Hotwire: HTML over the Wire
#52What'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…
Oh yeah. I remember that ViewState could reach 100s of KBs on a page if you weren't careful. It was a huge juggling act between keeping state in your input fields vs ViewState.
Re: Hotwire: HTML over the Wire
#53Gentlemen, we have come full circle.
web development has jumped the shark, I thought this was a parody at first.
Re: Hotwire: HTML over the Wire
#54Gentlemen, we have come full circle.
web development has jumped the shark, I thought this was a parody at first.
reminds me of the http://vanilla-js.com/ which is actually a parody, but also... not?
Re: Hotwire: HTML over the Wire
#55What'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 t…
Preach! Websites don’t seem all that much better to me than they did 10 years ago [^fn], so what are we gaining with all these much more complex and fragile tools?
[fn]: Arguably, the web is worse with chat bots, sticky headers, and modals constantly vying for your attention.
Re: Hotwire: HTML over the Wire
#56A while ago, way before SPA were cool and even AngularJS was around, I had done something sort of like this, based on Ajax calls though, so the underlying tech was definitely different.
While this is truly clever and being based on sockets does seem to simplify communications between client and server, I'm not fully convinced.
Currently I see client side rendering as a way to delegate some computing to the clients. Which is a nice way to lower operating costs.
I can see the benefit of this and the reasoning behind it. Because SPA still need a server (serverless still implies server side coding) as long as you are executing code on the client you need two codebases. One for the client, one server side.
With this solution it would seem that it's possible to serve a web app with only one codebase, so that's definitely a plus. But then performance and costs do preoccupy me a little.
Perhaps the ideal scenario for this tech would be for (enterprise) apps to be deployed on proprietary servers, where scale is a minor concern.
Re: Hotwire: HTML over the Wire
#57I 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.
yeah... fallback is not a problem, you can always long-poll as socket.io has done for years
Re: Hotwire: HTML over the Wire
#58This all seems super cool, but mega complicated. I'm not in the Rails ecosystem at all, so would love someone's assessment.
Is this a new, giant complexity or a nice add-on? A huge mental/development shift or a nicely paved new path to something better?
Re: Hotwire: HTML over the Wire
#59Gentlemen, we have come full circle.
I thought this had to be satire when I opened the page. Now I'm still not sure.
Re: Hotwire: HTML over the Wire
#60This 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 lo…
Literally LOL'd at the first part of this. A+++.