5 ms·

I did so last year, and I cannot be happier. My only regret is that I wasn't aware of htmx/hotwire at the time. I went with Vue, and I regret it immensely. Rai

by lta 4y ago

I did so last year, and I cannot be happier. My only regret is that I wasn't aware of htmx/hotwire at the time. I went with Vue, and I regret it immensely. Rails is the fastest development platform I've tried so far, it is predictable, well crafted, structured yet flexible. You can't go wrong with it. Every now and then I try something new on a side project or I have to work on some other codebase for my customers, and nothing so far has tempted me to move out of rails for my serious projects

mindcrime 4y ago
I'm vaguely aware of htmx, but have never used it. Had not heard of hotwire until just now, but that looks really interesting. Thanks for the pointer! Would you care to say any more about your experience with Vue? I've heard a lot of good things about Vue and had it on my mental "things to learn one day" list for a while. Would be really interested in hearing any counter-points from somebody who hasn't enjoyed working with it.
- moxplod 4y ago
  First I heard of HOTWIRE. I have been using PJAX for a decade now, which is a similar concept. I use .net mvc with a razor templating engine. But this can be used with any backend. It makes it super easy for me to maintain all my UX in server-rendered HTML templates. I get a clean SPA with super high development efficiency with MINIMAL javascript. The best part was I could hire any developer and they know how to work in basic HTML/JS/CSS. Edit: Reading more, I might need to spend time looking into HTMX/Hotwire as a replacement for PJAX at some point.
  - 0xblinq 4y ago
    Check out also Unpoly. It’s probably the most “batteries included” of this kind of tools, although not as popular.
    - evolve2k 4y ago
      Can you expand further? What has you bother to introduce unpoly when Hotwire is included by default? Aka, what are the main things missing/better that drive you to use unpoly.
      - 0xblinq 4y ago
        I was replying to @moxplod because it seems they didn't know about these alternatives to pjax. They're mentioning HTMX, etc so I've added Unpoly to the list of similar things. I'm not saying you should replace Hotwire with anything else - I wouldn't do it given it's the default or defacto solution. But all of these tools (pjax, htmx, unpoly and hotwire) work perfectly well outside of Rails too. So if you're not using Rails and you're, for example, using Django which doesn't have a default solution then you can pick one of them, and I think Unpoly is a very nice one.
  - rahoulb 4y ago
    I love Hotwire and it's reinvigorated my love of Rails.
  - kcartlidge 4y ago
    Worth looking into Hotwire. It works well with .NET MVC.
- jmuguy 4y ago
  I'm not sure what their particular beef with Vue is but I've been using it for several years now with Rails and its mostly been great. They had a similar issue as Python, albeit not nearly as bad, with their upgrade from version 2 to 3. It required some rewriting. They also introduced a new core concept with the "composition" API, which completely changes the way Vue apps are written. Luckily once you made a few required changes you could continue writing apps like you used to, ignoring the new composition API. I'm assuming at some point we'll be forced to change, which will suck. One thing we do, which I don't think is as common when using Rails with a heavy frontend like Vue or React, is that Rails is not in API mode. That is Rails still handles routing, pages are still rendered in ERB, and then each page is its own little Vue app. So we can use Rails, Ruby, etc to initially hydrate the pages and inject stuff by calling to_json on it. This also means we can let Rails and Devise handle login and session, which I absolutely hate doing with a pure JS frontend. Routing and session management are something I think Rails is extremely good with. This also means that if a section or sections of the site are pretty simple (password reset for instance) we can just render the page in ERB, no JS required. Regardless, I still like Vue and it has a pretty decent ecosystem. If I had to go back and start again I'd probably just go with React. It clearly has the most support (and most jobs) on the front end.
treis 4y ago
IMHO, part of this is that people have accepted the poor experience of non-realtime applications. But there's a huge UX improvement if the application responds faster than users can input actions. Doesn't matter for all applications but if your users are going to spend significant time inputting data it makes a huge difference. Also IMHO, a flexible type system like Typescript makes development faster than without it. You can refactor faster, it catches silly mistakes, and you don't have to write as many tests. Rails does a lot of great things for you, but IMHO ultimately it's stuff you don't really need. If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps.
- weaksauce 4y ago
  with hotwire you get the benefit of having that SPA with quick responsiveness but with the much, much reduced complexity in stack with all the jankiness that that brings with it.
- aantix 4y ago
  >If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps. Simply not true. I've consulted on multiple teams across products built with Rails. Products that supported hundreds of millions of requests and generated a similar levels of revenue. Rails scales - programmer productivity, traffic. It scales.
  - treis 4y ago
    >Simply not true. It's not true that I think it hurts more than it helps?
  - RangerScience 4y ago
    One thing I've taken to pointing out, and it seems like you have way more experience with which to back it up - is that it's not just about scaling to millions, it's also about scaling from zero. Thoughts? :)
- boredtofears 4y ago
sureglymop 4y ago
I used svelte and it's been super simple and efficient.
0xblinq 4y ago
I'm using Laravel with Hotwire and it's fantastic. Now I want to cry every time I see the mess of overengineering I have to deal with in other projects when they're built with Redux, React, etc, etc.
- omnimus 4y ago
  Why Hotwire instead of Livewire if i may ask?
  - 0xblinq 4y ago
    Mostly due to Turbo transitions between pages and being able to persist elements across pages. I know Livewire V3 will solve this but at the time we took the decision it wasn't available. Also something brought up was a conversation regarding Alpine vs Stimulus. At first sight Alpine looked a lot easier, but Stimulus seemed it would scale better and be easier to maintain at the end, plus we expected it to have less problems with Turbo than Alpine given those were made to work together. An important difference we found, is that Stimulus can "react" to value changes (https://stimulus.hotwired.dev/reference/values https://stimulus.hotwired.dev/reference/values) while with Alpine it was not clear how a component, or some external code would trigger an update by changing a "prop" or an "attribute" of the element. We know we could use stores and events, etc but that's what I meant with stimulus being easier to scale long term.
    - omnimus 4y ago
      Interesting. I had the feeling that framework like that has to be so tied to the backend framework that Hotwire has to have lots of troubles outside Rails. I would have never even thought of trying Hotwire with Laravel. Will try. Thanks
      - 0xblinq 4y ago
        Yes, that was my initial impression years ago too. But it's very progressive. For example, you can just use Turbo to get the "SPA like" navigation between pages (no full page reloads) and that's for free, just including it will bring in that behaviour, plus caching when navigating back, link preloading (so when you click the content it's already there), etc. All of this very easy to control/configure via html data attributes. Integrating the "Turbo frames" feature is also pretty easy, just wrap content in <turbo-frame> custom tags and the library will do the replacement without page reloads when you submit a form. Similar situation with "Turbo stream", etc. This is an excerpt from the main documentation site at https://turbo.hotwired.dev/handbook/introduction https://turbo.hotwired.dev/handbook/introduction : "...You don’t need any backend framework to use Turbo. All the features are built to be used directly, without further abstractions. But if you have the opportunity to use a backend framework that’s integrated with Turbo, you’ll find life a lot simpler. We’ve created a reference implementation for such an integration for Ruby on Rails...." Same story with Stimulus. You can add it to any framework, it's just a frontend library. Having said that, there are some "helpers" that you can have in the backend that will make things more idiomatic and avoid some boilerplate, etc. And Laravel being such an amazing framework with such a great community, has a great integration library here: https://github.com/tonysm/turbo-laravel https://github.com/tonysm/turbo-laravel I couldn't be happier with this stack. With Laravel + Hotwire + Tailwind + Laracasts I feel I'm unstoppable.

by lta 4y ago

mindcrime 4y ago

I'm vaguely aware of htmx, but have never used it. Had not heard of hotwire until just now, but that looks really interesting. Thanks for the pointer! Would you care to say any more about your experience with Vue? I've heard a lot of good things about Vue and had it on my mental "things to learn one day" list for a while. Would be really interested in hearing any counter-points from somebody who hasn't enjoyed working with it.

moxplod 4y ago
First I heard of HOTWIRE. I have been using PJAX for a decade now, which is a similar concept. I use .net mvc with a razor templating engine. But this can be used with any backend. It makes it super easy for me to maintain all my UX in server-rendered HTML templates. I get a clean SPA with super high development efficiency with MINIMAL javascript. The best part was I could hire any developer and they know how to work in basic HTML/JS/CSS. Edit: Reading more, I might need to spend time looking into HTMX/Hotwire as a replacement for PJAX at some point.
- 0xblinq 4y ago
  Check out also Unpoly. It’s probably the most “batteries included” of this kind of tools, although not as popular.
  - evolve2k 4y ago
    Can you expand further? What has you bother to introduce unpoly when Hotwire is included by default? Aka, what are the main things missing/better that drive you to use unpoly.
    - 0xblinq 4y ago
      I was replying to @moxplod because it seems they didn't know about these alternatives to pjax. They're mentioning HTMX, etc so I've added Unpoly to the list of similar things. I'm not saying you should replace Hotwire with anything else - I wouldn't do it given it's the default or defacto solution. But all of these tools (pjax, htmx, unpoly and hotwire) work perfectly well outside of Rails too. So if you're not using Rails and you're, for example, using Django which doesn't have a default solution then you can pick one of them, and I think Unpoly is a very nice one.
- rahoulb 4y ago
  I love Hotwire and it's reinvigorated my love of Rails.
- kcartlidge 4y ago
  Worth looking into Hotwire. It works well with .NET MVC.
jmuguy 4y ago
I'm not sure what their particular beef with Vue is but I've been using it for several years now with Rails and its mostly been great. They had a similar issue as Python, albeit not nearly as bad, with their upgrade from version 2 to 3. It required some rewriting. They also introduced a new core concept with the "composition" API, which completely changes the way Vue apps are written. Luckily once you made a few required changes you could continue writing apps like you used to, ignoring the new composition API. I'm assuming at some point we'll be forced to change, which will suck. One thing we do, which I don't think is as common when using Rails with a heavy frontend like Vue or React, is that Rails is not in API mode. That is Rails still handles routing, pages are still rendered in ERB, and then each page is its own little Vue app. So we can use Rails, Ruby, etc to initially hydrate the pages and inject stuff by calling to_json on it. This also means we can let Rails and Devise handle login and session, which I absolutely hate doing with a pure JS frontend. Routing and session management are something I think Rails is extremely good with. This also means that if a section or sections of the site are pretty simple (password reset for instance) we can just render the page in ERB, no JS required. Regardless, I still like Vue and it has a pretty decent ecosystem. If I had to go back and start again I'd probably just go with React. It clearly has the most support (and most jobs) on the front end.

treis 4y ago

IMHO, part of this is that people have accepted the poor experience of non-realtime applications. But there's a huge UX improvement if the application responds faster than users can input actions. Doesn't matter for all applications but if your users are going to spend significant time inputting data it makes a huge difference. Also IMHO, a flexible type system like Typescript makes development faster than without it. You can refactor faster, it catches silly mistakes, and you don't have to write as many tests. Rails does a lot of great things for you, but IMHO ultimately it's stuff you don't really need. If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps.

weaksauce 4y ago
with hotwire you get the benefit of having that SPA with quick responsiveness but with the much, much reduced complexity in stack with all the jankiness that that brings with it.
aantix 4y ago
>If there's any chance that the application will grow beyond a few developers I think it hurts more than it helps. Simply not true. I've consulted on multiple teams across products built with Rails. Products that supported hundreds of millions of requests and generated a similar levels of revenue. Rails scales - programmer productivity, traffic. It scales.
- treis 4y ago
  >Simply not true. It's not true that I think it hurts more than it helps?
- RangerScience 4y ago
  One thing I've taken to pointing out, and it seems like you have way more experience with which to back it up - is that it's not just about scaling to millions, it's also about scaling from zero. Thoughts? :)
boredtofears 4y ago

sureglymop 4y ago

I used svelte and it's been super simple and efficient.

0xblinq 4y ago

I'm using Laravel with Hotwire and it's fantastic. Now I want to cry every time I see the mess of overengineering I have to deal with in other projects when they're built with Redux, React, etc, etc.

omnimus 4y ago
Why Hotwire instead of Livewire if i may ask?
- 0xblinq 4y ago
  Mostly due to Turbo transitions between pages and being able to persist elements across pages. I know Livewire V3 will solve this but at the time we took the decision it wasn't available. Also something brought up was a conversation regarding Alpine vs Stimulus. At first sight Alpine looked a lot easier, but Stimulus seemed it would scale better and be easier to maintain at the end, plus we expected it to have less problems with Turbo than Alpine given those were made to work together. An important difference we found, is that Stimulus can "react" to value changes (https://stimulus.hotwired.dev/reference/values https://stimulus.hotwired.dev/reference/values) while with Alpine it was not clear how a component, or some external code would trigger an update by changing a "prop" or an "attribute" of the element. We know we could use stores and events, etc but that's what I meant with stimulus being easier to scale long term.
  - omnimus 4y ago
    Interesting. I had the feeling that framework like that has to be so tied to the backend framework that Hotwire has to have lots of troubles outside Rails. I would have never even thought of trying Hotwire with Laravel. Will try. Thanks
    - 0xblinq 4y ago
      Yes, that was my initial impression years ago too. But it's very progressive. For example, you can just use Turbo to get the "SPA like" navigation between pages (no full page reloads) and that's for free, just including it will bring in that behaviour, plus caching when navigating back, link preloading (so when you click the content it's already there), etc. All of this very easy to control/configure via html data attributes. Integrating the "Turbo frames" feature is also pretty easy, just wrap content in <turbo-frame> custom tags and the library will do the replacement without page reloads when you submit a form. Similar situation with "Turbo stream", etc. This is an excerpt from the main documentation site at https://turbo.hotwired.dev/handbook/introduction https://turbo.hotwired.dev/handbook/introduction : "...You don’t need any backend framework to use Turbo. All the features are built to be used directly, without further abstractions. But if you have the opportunity to use a backend framework that’s integrated with Turbo, you’ll find life a lot simpler. We’ve created a reference implementation for such an integration for Ruby on Rails...." Same story with Stimulus. You can add it to any framework, it's just a frontend library. Having said that, there are some "helpers" that you can have in the backend that will make things more idiomatic and avoid some boilerplate, etc. And Laravel being such an amazing framework with such a great community, has a great integration library here: https://github.com/tonysm/turbo-laravel https://github.com/tonysm/turbo-laravel I couldn't be happier with this stack. With Laravel + Hotwire + Tailwind + Laracasts I feel I'm unstoppable.