It 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
Caleb Porzio (creator of Livewire) made videos about "Server-Side Applications": https://laracasts.com/series/javascript-techniques-for-serve... His work inspired me to build my app (TravelMap) with SSR views: https://clem.travelmap.net
Hotwire: HTML over the Wire
301–310 of 573 posts
Re: Hotwire: HTML over the Wire
#302Is 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…
Re: Hotwire: HTML over the Wire
#303Re: Hotwire: HTML over the Wire
#304As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well. However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cros…
This, while very interesting and might have a preferable set of constraints for some projects, is simply not a good fit for many others, as you mentioned in your comment. This looks amazing, and I would definitely try it for a project in which it would fit, but I don't really see a reason to disparage the work others have been doing over the past decade. We need those other tools too!
(sorry for the rant)
Re: Hotwire: HTML over the Wire
#305Earlier quoted context omitted.
But... that's one of the pro's of not having to do the rending cycle on the server. Also caching of framework libraries off CDN's and such. I don't see much merit in moving back to server side rendering aside from obfuscation & helping SEO ratings (web crawlers have a hard time with SPA)
> But... that's one of the pro's of not having to do the rending cycle on the server. Also caching of framework libraries off CDN's and such. This doesn't save battery life on a device. If someone downloads a few meg of JS their browser has to parse and execute that JS locally. This use of processing uses power. If that same person had half as much JS to parse and execute it would use less power. A CDN does not save…
The two things that use the most battery in a phone are the radio and the screen.
If you can do most of the work client side, the phone can turn off the radio and save battery. The amount of battery savings of course depends greatly on what the application is actually doing.
Re: Hotwire: HTML over the Wire
#306Earlier quoted context omitted.
Literally nobody is saying this
They are, look at the context of what they're saying. JS is simply a programming language in a VM like plenty of others, there's nothing inherently bad about it. But every thread here's the uneducated hate for it, completely misunderstanding that html/css static pages don't solve the problems a programming language does. I'd like to see these people make applications in pure XML. No programming.
The bad experiences stick out to people, whereas all the well behaved JS-heavy apps out there likely don't even register as such to most people.
Even with SPAs, it's very possible (and really not that hard) to make them behave well. Logically, even a large SPA should use less overall data than a comparable server-rendered app over time. A JS bundle is a bigger initial hit but will be cached, leaving only the data and any chunks you don't have cached yet to come over the wire as you navigate around. A server-rendered app needs to transmit the entire HTML document on every single page load.
Of course, when you see things like the newer React-based reddit, which chugs on any hardware I have to throw at it, I can sort of see where people's complaints come from.
Re: Hotwire: HTML over the Wire
#307As others have noted, seems reasonably similar to LiveView, Livewire and Blazor. I’m somewhat bullish on these approaches - server side rendered monoliths (Rails, Django, etc.) are SO productive, at least for the first few years of development, but lack of interactivity is a big issue, and this solves it well. However, another big issue is the dominance of mobile. More and more, you’ve got 2-3 frontends (web and cros…
Re: Hotwire: HTML over the Wire
#308I wonder how long it will take before we reinvent SPAs? I like Hacker News in part because the tech is so boring. Server-side rendered, static HTML with a minimal amount of JS[0]. [0]: https://news.ycombinator.com/hn.js
Re: Hotwire: HTML over the Wire
#309Earlier quoted context omitted.
> But... that's one of the pro's of not having to do the rending cycle on the server. Also caching of framework libraries off CDN's and such. This doesn't save battery life on a device. If someone downloads a few meg of JS their browser has to parse and execute that JS locally. This use of processing uses power. If that same person had half as much JS to parse and execute it would use less power. A CDN does not save…
I think there's some kind of weird mentality among web devs that client-size computations are free, but server-side ones cost resources because you do more of them the more users you have.
Re: Hotwire: HTML over the Wire
#310This sounds a lot like server-hosted Blazor, streaming HTML snippets though websockets. Am I understanding it correctly?