Live data from Hacker News

Hotwire: HTML over the Wire

hotwire.dev

301–310 of 573 posts

Re: Hotwire: HTML over the Wire

#301
post #15

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

Very good work!

Re: Hotwire: HTML over the Wire

#302

Is 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…

You should check out React Server Components.

Re: Hotwire: HTML over the Wire

#304
post #252

As 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…

Everyone who is talking about how the route the industry took with SPAs was just a silly mistake, and that we should go back to the good old days of PHP are forgetting that at the end of the day the most important thing is to choose the best tool for the job at hand.

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

#305
post #165

Earlier 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…

You're right it's not all cut and dry.

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

#306

Earlier 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.

People often conflate use with abuse.

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

#307
post #252

As 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…

We gotta wait and see what Strada has in store. Looks like Basecamp and Hey mobile apps are fairly good.

Re: Hotwire: HTML over the Wire

#308
post #123

I 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

Hackernews, Crigslist, the old redddit (which is still VERY actively used). The list goes on.

Re: Hotwire: HTML over the Wire

#309
post #165

Earlier 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.

They are free, just not to the client.
Post reply on HN