3 ms·

For those who have used tools like Hotwire, what has your experience been like? How does it compare to something like Vue or React?

cageface 5y ago
I've just started using it on a fairly simple project so I only have first impressions. But it seems like for a UI that's not too complex it could be a big timesaver. I need to spend more time with it before I can decide where I'd draw the line and switch to a full blown SPA but it definitely expands the class of apps you can build without much JS.
- DanielKehoe 5y ago
  State management on the front end? Is that the differentiator that forces the need for a full SPA framework? Anything else that can't be done purely with web components?
  - cageface 5y ago
    I'm sure there are people much better qualified to answer this than me but it feels like there would be a point at which trying to manage a very complex UI with all these little HTML fragments over the wire would get unmanageable. I'm just guessing though. So far I haven't done anything that complex with it. I guess I'd also miss having Typescript for a UI with a lot of components. You can do some client-side state management with Stimulus though.
  - bryanrasmussen 5y ago
    I think the only state management that really requires SPA is of course the state between pages. But why actually have pages - I actually think this is a good differentiator of if your site is naturally an SPA or not - if you really need pages, perhaps because people need to be able to bookmark a specific part of your site that is more important to them than other parts - your site as a whole might not actually need to be an SPA although it might have parts of it that function as SPAs.
joelbluminator 5y ago
They aren't really comparable I think, you should compare Hotwire to old Turbolinks + Rails/ujs. Hotwire will make it feel like a SPA but it is not a SPA. Probably for many websites this is enough, but I wouldn't write a computer game with Hotwire.
danjac 5y ago
I've used it (as side project) for a fairly interactive application (https://audiotrails.io https://audiotrails.io). I'm also in the middle of rewriting it with htmx, which offers more features & a larger mindshare/future outside of the Rails community. In addition, I used Stimulus (with turbo) and Alpine (with htmx) where more intricate JS actions where needed, for example the audio player, with Tailwind for the CSS, and Django backend. I can offer some comparisons with Vue which I have more experience with. I'd describe myself primarily as a backend developer with some frontend experience. In both cases I found it much more productive than building the traditional SPA. Building an SPA feels very much like building two applications: your backend API and the frontend app. This might make sense where you have a team of specialists, or multiple frontends (i.e. IOS+Android+web). If you're a sole developer it's important to acquire "superpowers" that give you a productivity boost to compensate for your limited time and expertise, and Hotwire and htmx feel very much like superpowers. Combined with a compatible JS library like Stimulus or Alpine I didn't feel like I hit too many walls compared to Vue. This made it easier to focus on the UI and backend logic and kept maintenance to a minimum. That said, the more interactive parts did require some lateral thinking where Vue would have likely been easier in terms of the mental model, for example keeping an audio player open during page navigations and maintaining state without full page refreshes (i.e. to prevent the player restarting). Another thing I missed where the sheer ease of building and re-using components in Vue, and Django templates and tags feel quite clunky in comparison (some other frameworks like Laravel have perhaps a better template component model). Overall though it was so much easier to build a traditional web application compared to the complexity of an SPA. Comparing Hotwire to htmx: Hotwire required more server work when doing atomic changes (HTML fragments returned from AJAX requests). There's an existing Rails gem which does most of this, I had to write my own Django package. There's an expectation that it should be used with websockets, but really that's optional. In most cases though Turbo Drive works pretty much like Turbolinks: once you install it, it will provide SPA-like page transitions for free. Htmx feels a bit less polished, and the learning curve is a bit steeper, but has much more in the way of features and extensions and doesn't require as much rework in the backend. There's an hx-boost feature that works similar to turbo drive but I found it's easier to use htmx' low-level options to manage different sections of the site as appropriate.

cageface 5y ago

I've just started using it on a fairly simple project so I only have first impressions. But it seems like for a UI that's not too complex it could be a big timesaver. I need to spend more time with it before I can decide where I'd draw the line and switch to a full blown SPA but it definitely expands the class of apps you can build without much JS.

DanielKehoe 5y ago
State management on the front end? Is that the differentiator that forces the need for a full SPA framework? Anything else that can't be done purely with web components?
- cageface 5y ago
  I'm sure there are people much better qualified to answer this than me but it feels like there would be a point at which trying to manage a very complex UI with all these little HTML fragments over the wire would get unmanageable. I'm just guessing though. So far I haven't done anything that complex with it. I guess I'd also miss having Typescript for a UI with a lot of components. You can do some client-side state management with Stimulus though.
- bryanrasmussen 5y ago
  I think the only state management that really requires SPA is of course the state between pages. But why actually have pages - I actually think this is a good differentiator of if your site is naturally an SPA or not - if you really need pages, perhaps because people need to be able to bookmark a specific part of your site that is more important to them than other parts - your site as a whole might not actually need to be an SPA although it might have parts of it that function as SPAs.

joelbluminator 5y ago

They aren't really comparable I think, you should compare Hotwire to old Turbolinks + Rails/ujs. Hotwire will make it feel like a SPA but it is not a SPA. Probably for many websites this is enough, but I wouldn't write a computer game with Hotwire.

danjac 5y ago

I've used it (as side project) for a fairly interactive application (https://audiotrails.io https://audiotrails.io). I'm also in the middle of rewriting it with htmx, which offers more features & a larger mindshare/future outside of the Rails community. In addition, I used Stimulus (with turbo) and Alpine (with htmx) where more intricate JS actions where needed, for example the audio player, with Tailwind for the CSS, and Django backend. I can offer some comparisons with Vue which I have more experience with. I'd describe myself primarily as a backend developer with some frontend experience. In both cases I found it much more productive than building the traditional SPA. Building an SPA feels very much like building two applications: your backend API and the frontend app. This might make sense where you have a team of specialists, or multiple frontends (i.e. IOS+Android+web). If you're a sole developer it's important to acquire "superpowers" that give you a productivity boost to compensate for your limited time and expertise, and Hotwire and htmx feel very much like superpowers. Combined with a compatible JS library like Stimulus or Alpine I didn't feel like I hit too many walls compared to Vue. This made it easier to focus on the UI and backend logic and kept maintenance to a minimum. That said, the more interactive parts did require some lateral thinking where Vue would have likely been easier in terms of the mental model, for example keeping an audio player open during page navigations and maintaining state without full page refreshes (i.e. to prevent the player restarting). Another thing I missed where the sheer ease of building and re-using components in Vue, and Django templates and tags feel quite clunky in comparison (some other frameworks like Laravel have perhaps a better template component model). Overall though it was so much easier to build a traditional web application compared to the complexity of an SPA. Comparing Hotwire to htmx: Hotwire required more server work when doing atomic changes (HTML fragments returned from AJAX requests). There's an existing Rails gem which does most of this, I had to write my own Django package. There's an expectation that it should be used with websockets, but really that's optional. In most cases though Turbo Drive works pretty much like Turbolinks: once you install it, it will provide SPA-like page transitions for free. Htmx feels a bit less polished, and the learning curve is a bit steeper, but has much more in the way of features and extensions and doesn't require as much rework in the backend. There's an hx-boost feature that works similar to turbo drive but I found it's easier to use htmx' low-level options to manage different sections of the site as appropriate.