From the turbo handbook: "An application visit always issues a network request. When the response arrives, Turbo Drive renders its HTML and completes the visit." Using the phrase "When the response arrives" begs the question of what happens if it doesn't arrive, or if it takes a minute for it to arrive, or if it arrives but with a faulty status code.
Hotwire: HTML over the Wire
41–50 of 573 posts
Re: Hotwire: HTML over the Wire
#42It 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. [1] https://laravel-livewire.com/ [2] https://news.ycombinator.com/item?id=25497065
Re: Hotwire: HTML over the Wire
#43Re: Hotwire: HTML over the Wire
#44Re: Hotwire: HTML over the Wire
#45My 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 state over the network (Phoenix LiveView seems closer to that), but this feels like it involves a lot more framework-specific logic (and markup) with special cases - stuff that's likely to change as the framework evolves, so I'm not sure how I feel about it.
I guess it makes sense in terms of making this easier to add to an existing rails app incrementally (since it's more-or-less "opt-in" for each model, view, and controller), but if I'm building a new project with this and want it on everything, it feels like it will necessitate a lot of code duplication. Either that, or I use it judiciously only when absolutely needed (and use traditional rails behavior for everything else), but that feels like a mess of two very different approaches bundled together in one codebase.
Re: Hotwire: HTML over the Wire
#46Re: Hotwire: HTML over the Wire
#47Re: Hotwire: HTML over the Wire
#48I 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 :)
.NET's Blazor (server based) uses this.
Re: Hotwire: HTML over the Wire
#49Re: Hotwire: HTML over the Wire
#50This 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…