4 ms·

> solution that lets you send snippets of HTML over the wire I haven't touched rails in a long time but isn't that how it all used to be done way back when? I

> solution that lets you send snippets of HTML over the wire I haven't touched rails in a long time but isn't that how it all used to be done way back when? I feel like my original rails apps were making requests and I was returning HTML partials to be (crudely) diffed into the DOM?

dilyevsky 4y ago
Yes this is how it works. This framework was created by rails people - 37signals
nickjj 4y ago
> I feel like my original rails apps were making requests and I was returning HTML partials to be (crudely) diffed into the DOM? They weren't diff'd into the DOM client side. Optionally, there was SJR (Server-generated JavaScript Responses) from 10 years ago[0] that you could do to get similar behavior but now it's much easier and much more maintainable with Hotwire. In your original Rails apps you could make a request, render a template that has 0 ore more partials and the HTTP response from Rails by default would be all of the HTML, from <html> to </html>. Your browser would parse all of that and produce the page. Then Turbolinks came into play around 2016 and it's a 1 line of JS drop-in solution so the above still happens, except now instead of <html> to </html> being rendered by your browser, only the <body> to </body> gets rendered. This is a massive improvement for page load speeds because now all of your JS / CSS in your <head> doesn't get parsed on every page load. Even with caching this is a big win since your browser still needed to parse it. It intercepts your links and makes them ajax calls transparently. It worked for form submissions too but you had to do a little bit of work on the back-end to make this work (Rails did it by default). This works with any tech stack tho. Then Hotwire came along: - Now you can swap the whole body with Turbo Drive in the same way as Turbolinks did in the past except it also works for form submissions now too with no backend modifications. It's IMO the single biggest bang for your buck that you can do on a site to make it feel fast with no effort at all. - You can also use Turbo Frames to only swap a portion of the page instead of the whole <body>. It's 1 new HTML tag, you just wrap your content into a frame tag and you're done. Everything "just works". Only that frame's HTML gets sent over the wire, the other content on the page remains untouched. For example if you had a main content area and a sidebar you could have the main content be in its own frame and as you click links and do things in that area the sidebar will never get re-rendered unless you purposely break out of the frame by setting a target on the link. - Then there's Turbo Streams which works for non-GET requests by default. So if you posted a new comment on the bottom of a blog post you can tell the stream to append it to a div (or prepend, update, delete, etc.) so you end up only sending a tiny bit of HTML over the wire for that single comment's markup. Optionally you can also instruct that to be broadcast over a websockets channel. In Rails this is seamless, it's 1 extra line of code and now you have live updates broadcast to anyone connected to that channel. You can also use streams to update multiple areas of a page if you wanted to, such as append the comment and add a (1) notification to your nav bar or page's title. You as an end user don't need to write much JS to do all of the above. Then there's the Stimulus part of Hotwire for when you do need to write JS for more client side interactivity. All of this works with any back-end tech stack. [0]: https://signalvnoise.com/posts/3697-server-generated-javascript-responses https://signalvnoise.com/posts/3697-server-generated-javascr...
- AlchemistCamp 4y ago
  And here I thought you spent most your time on Flask!
  - nickjj 4y ago
    I do a mix of Flask and Rails personally. Hotwire Turbo works with Flask out of the box minus the websockets bits which you could make work but you'd need to handle the broadcasting server side bits since Turbo is a client side library. With contract work I get exposed to a number of different tech stacks too.

dilyevsky 4y ago

Yes this is how it works. This framework was created by rails people - 37signals

nickjj 4y ago

> I feel like my original rails apps were making requests and I was returning HTML partials to be (crudely) diffed into the DOM? They weren't diff'd into the DOM client side. Optionally, there was SJR (Server-generated JavaScript Responses) from 10 years ago[0] that you could do to get similar behavior but now it's much easier and much more maintainable with Hotwire. In your original Rails apps you could make a request, render a template that has 0 ore more partials and the HTTP response from Rails by default would be all of the HTML, from <html> to </html>. Your browser would parse all of that and produce the page. Then Turbolinks came into play around 2016 and it's a 1 line of JS drop-in solution so the above still happens, except now instead of <html> to </html> being rendered by your browser, only the <body> to </body> gets rendered. This is a massive improvement for page load speeds because now all of your JS / CSS in your <head> doesn't get parsed on every page load. Even with caching this is a big win since your browser still needed to parse it. It intercepts your links and makes them ajax calls transparently. It worked for form submissions too but you had to do a little bit of work on the back-end to make this work (Rails did it by default). This works with any tech stack tho. Then Hotwire came along: - Now you can swap the whole body with Turbo Drive in the same way as Turbolinks did in the past except it also works for form submissions now too with no backend modifications. It's IMO the single biggest bang for your buck that you can do on a site to make it feel fast with no effort at all. - You can also use Turbo Frames to only swap a portion of the page instead of the whole <body>. It's 1 new HTML tag, you just wrap your content into a frame tag and you're done. Everything "just works". Only that frame's HTML gets sent over the wire, the other content on the page remains untouched. For example if you had a main content area and a sidebar you could have the main content be in its own frame and as you click links and do things in that area the sidebar will never get re-rendered unless you purposely break out of the frame by setting a target on the link. - Then there's Turbo Streams which works for non-GET requests by default. So if you posted a new comment on the bottom of a blog post you can tell the stream to append it to a div (or prepend, update, delete, etc.) so you end up only sending a tiny bit of HTML over the wire for that single comment's markup. Optionally you can also instruct that to be broadcast over a websockets channel. In Rails this is seamless, it's 1 extra line of code and now you have live updates broadcast to anyone connected to that channel. You can also use streams to update multiple areas of a page if you wanted to, such as append the comment and add a (1) notification to your nav bar or page's title. You as an end user don't need to write much JS to do all of the above. Then there's the Stimulus part of Hotwire for when you do need to write JS for more client side interactivity. All of this works with any back-end tech stack. [0]: https://signalvnoise.com/posts/3697-server-generated-javascript-responses https://signalvnoise.com/posts/3697-server-generated-javascr...

AlchemistCamp 4y ago
And here I thought you spent most your time on Flask!
- nickjj 4y ago
  I do a mix of Flask and Rails personally. Hotwire Turbo works with Flask out of the box minus the websockets bits which you could make work but you'd need to handle the broadcasting server side bits since Turbo is a client side library. With contract work I get exposed to a number of different tech stacks too.