Laravel's crew had a very similar idea with Livewire (even the name sound similar, probably not intentionally) and it also created a lot of buzz back when it was released - but I don't think it really got past "let's play with it a bit" step for most of teams. We'll see how well this one does...
Hotwire: HTML over the Wire
201–210 of 573 posts
Re: Hotwire: HTML over the Wire
#202This is sort of ironic because many years ago what caused me to move functionality to client side was the fact that Ruby on Rails was slower on server side and required horizontal scale and things like memcached to meet my demands.
[deleted]
Re: Hotwire: HTML over the Wire
#203What are the pros and cons of this technique? Seems like this pushes a lot of the rendering compute power from the client to the server. I guess that is good for low power devices but now you need more powerful servers?
Re: Hotwire: HTML over the Wire
#204Laugh all you want but the hey.com website loads wicked fast.
Why wouldn't it? It's got like 2 pictures and isn't long. I also wouldn't call it wicked fast - this is normal speed, which everyone seems to have forgotten
Sorry, this is right. You have all forgotten about how fast the normal web is or are too young to have experienced it. Sub 100ms is normal. 1000ms is not normal.
Re: Hotwire: HTML over the Wire
#205I love that these new techniques come out to make web dev simple again. I however think Phoenix Liveview is still the best from all the alternatives I have seen so far and that is mainly because Elixir as a language seems to be very stable and suited for having a lot of websocket connections open at the same time. It seems easier to accomplish this with Liveview and perhaps Alpine.js for displaying stuff like modals…
I've been using Phoenix LiveView and I love it. I'm much more comfortable with Erlang syntax, though, and wish there was still a viable Erlang web framework.
Re: Hotwire: HTML over the Wire
#206Am I the only one who was very, very surprised when the screencast immediately jumped into Rails? There's no mention of Rails anywhere on the landing page.
Re: Hotwire: HTML over the Wire
#207Earlier 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…
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
#208This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we ar…
I’m glad this technique is making a comeback. The last 10 years of JavaScript on the client have been an utter shit show that left me wondering wtf people were thinking.
Couldn’t have come soon enough. I’m exhausted
Re: Hotwire: HTML over the Wire
#209Earlier quoted context omitted.
Livewire, of course, having been heavily inspired by Phoenix LiveView https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html
How does Hotwire compare to Phoenix LiveView?
> How does Hotwire compare to Phoenix LiveView? It seems the same to me.
It's much different based on a preliminary reading of Hotwire's docs.
Live View uses websockets for everything. If you want to update a tiny text label in some HTML, it uses websockets to push the diff of the content that changed. However you could use LV in a way that replaces Hotwire Turbo Drive, which is aimed at page transitions, such as going from a blog index page to contact form. This way you get the benefits of not having to re-parse the along with all of your CSS / JS. However LV will send those massive diffs over websockets.
Hotwire Turbo Drive replaces Tubolinks 5, and it uses HTTP to transfer the content. It also has new functionality (Hotwire Turbo Frames) to do partial page updates too instead of swapping the whole body like Turbolinks 5 used to do. Websockets is only used when you want to broadcast the changes to everyone connected and that's where Hotwire Turbo Streams comes in.
IMO that is a much better approach than Live View, because now only websockets get used for broadcast-like actions instead of using it to render your entire page of content if you're using LV to handle page transitions. IMO the trade off of throwing away everything we know and can leverage from HTTP to "websocket all the things" isn't one worth making. Websockets should be used when they need to, which is exactly what Hotwire does.
I could be wrong of course but after reading the docs I'm about 95% sure that is an accurate assessment. If I'm wrong please correct me!
Re: Hotwire: HTML over the Wire
#210This is so exciting to see, especially for older folk like me. Almost 20 years ago, one of my professors told us before graduation that hot tech is mostly about the idea pendulum swinging back and forth. I immediately chalked it up to 65+ above white wise men snobbery. However, this is exactly that. We started with static pages, then came Ajax and Asp.net and the open source variants, then we went full SPA, now we ar…
I’m glad this technique is making a comeback. The last 10 years of JavaScript on the client have been an utter shit show that left me wondering wtf people were thinking.
I’m glad I’m not the only one who thought this.