[deleted]
Hotwire: HTML over the Wire
61–70 of 573 posts
Re: Hotwire: HTML over the Wire
#62This 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)
GitHub scales just fine on their own variant of Turbolinks.
Re: Hotwire: HTML over the Wire
#63There will be a very hot wire when I have to ask the server to render a component on the server after I asked to increment a single counter
it might not be so bad
42
is not so many more bytes than...
{ counter: 42 }
also - no massive up front JS bundles to contend with
Re: Hotwire: HTML over the Wire
#64I 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.
Turbo uses Ajax for most of its functionality too. The WebSockets bit is an optional add-on if you want to push updates from the server e.g. for notifications.
Re: Hotwire: HTML over the Wire
#65Is this the "new magic" that DHH teased on Twitter, or are we still waiting to see what that is? Also, should we expect this to be included in a future version of Rails? My first impression is that the API seems a little convoluted, but that might just be me. In an ideal world, I'd love to just build components (similar to React components) on the server side, and let the framework intelligently handle synchronizing…
Yes, this is the "new magic".
Re: Hotwire: HTML over the Wire
#66A 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. W…
The one performance concern on distributed systems is on data coherence. You optimize it, and treat anything else as relatively free.
Rendering (or anything else that you can choose to do on the server or the client) has no impact on data coherence. Thus, as optimization goes, it's something you care about less than nearly anything else.
By the way, I have seen my share of really horrendous code though my life. Only twice I have seen something that isn't data coherence being a bottleneck to anything. Both times were really stupid bugs.
Re: Hotwire: HTML over the Wire
#67This 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?
If you're used to SPA-style frontend development with React, Vue, or any similar framework, then yes, this will probably be a big mental/development shift.
Turbolinks (the project at Basecamp that Hotwire grew out of, now it seems it's called Turbo Drive) was a way to bring single-page style load times to traditional, server-rendered apps. Hotwire is the evolution of that: Turbo Frames let you dynamically replace certain parts of the page on the frontend, rather than having to throw the baby out with the bathwater on every page action. If you're used to developing server-rendered applications without much JavaScript using Ruby on Rails, Django, or a similar "batteries included" backend framework, then you'll be able to add a more dynamic feel to your web app without much of a mental shift: certain template partials (basically the components of your frontend) will be wrapped in this `turbo-frame` HTML tag, which will be slotted in to your page dynamically by Turbo.
Re: Hotwire: HTML over the Wire
#68Laugh all you want but the hey.com website loads wicked fast.
Re: Hotwire: HTML over the Wire
#69I've never seen one of these "logic in html-attributes" systems take error checking seriously. In stimulus they start to mention it in "Designing For Resilience" (though only for feature-checking), but in "Working With External Resources" where it uses calls network/IO bound calls they never mention how to handle errors or if the framework just leaves it up to you. Stimulus is also where you need to write your own js…
A very good point! Presumably the appeal of a system like this is the potential for graceful degradation where if sockets aren’t working or some requests are failing then the default html behavior should still work: links will just take you to the original destination, but there’s no indication that this is actually what happens.
Re: Hotwire: HTML over the Wire
#70This 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…
[deleted]