3 ms·

I'm pretty experienced in Node and React, and discovering Rails recently has been an absolute joy. I feel like I've made the opposite journey from everyone else

I'm pretty experienced in Node and React, and discovering Rails recently has been an absolute joy. I feel like I've made the opposite journey from everyone else on HN, because I joined the programming community _after_ the big RoR hype and during the Node/React hype. Trying out rails, I understand how much magic is involved here. Because I've had to build all this crap myself - many, many times over. Complicated things become simple, and tasks that usually make me sigh (add a new data point and add it right through Knex, Hapi models, routes, redux actions, redux store, dispatch/selector and template) turns into a SINGLE COMMAND. Sold :) Very excited about this new release! Edit: I wrote a blog about this a while ago btw, but there are many others pieces out there like it: https://nikodunk.com/a-node-js-developer-discovers-rails/ https://nikodunk.com/a-node-js-developer-discovers-rails/ - using it to create https://electrade.app https://electrade.app currently.

nunez 5y ago
I’m with you. Writing and testing Ruby is a blast, and it’s so easy to write clean, readable code with it. Performance isn’t great, but it’s just so nice. Rails adds a lot of nice magic on top that makes it even better. JavaScript (even with TypeScript) and frontend frameworks are…quite a journey by comparison.
- baash05 5y ago
  I love the lang.. TBH though performance has never been something I see as a fault in the language. I've almost always found (for my apps) that it's data access that's the hold up. Like if I map the issues, n+1 or bad indexing have almost always taken the lions share of slower code bits. It irks me when people sight the lang or ruby as having bad memory or being slow. I've seen a tweak of the indexing cut response time to 25%. I even managed a 10x gain off of one index adjustment.
- CraigJPerry 5y ago
  >> Performance isn’t great I see so much focus on this on web frameworks generally and it strikes me as almost always the wrong thing to optimise for. I don’t know rails, the last time i tried it was circa 2007 and yet I’d confidently adopt it given the right situation. If i had a choice between shipping features 2% sooner or saving $10k / year on server costs, I’d almost always choose sooner. Let’s be honest, a rails dev team is moving more than 2% faster than a java/c# web dev team. If i have 5 devs and they’re all 2% more productive, that could be around $10k of free developer output but it’s more than that, developer productivity compounds. 75% off my server costs doesn’t.
  - brigandish 5y ago
    The problem with this comparison is that a language like Crystal shows that you don't have to give up the expressiveness for performance.
- montblanc 5y ago
  Stay tuned about performance, the Ruby JIT being built by Shopify is gonna narrow the gap. It's now 25-30% faster than CRuby , we'll see in a year how faster it gets. Source: https://speed.yjit.org/ https://speed.yjit.org/
- ydnaclementine 5y ago
  > Perfomance isn't great I would argue that the performance hit isn't from ruby or the framework, but from people abusing the database with lazy loading in active record. Force people to fetch all the data they need in one query (similar to Ecto), and your performance will improve. There's some config value that disables lazy loading too
  - projct 5y ago
    This is the most common slowdown I've seen in rails before. strict_loading mode can help, as can the bullet gem. That said, it is also quite slow when you actually do need requests per second or rows per second, but the usual thing is to throw more machines at it,reduce the amount of magic in the hot path (like activerecord-import for bulk data if that's still maintained,) or use something else for the hot path.
  - nunez 5y ago
    To clarify, performance isn't "great" (i.e. Ruby tends to be slower than writing the same code in, say, Go), but it's good enough for most things.
scottc 5y ago
Interesting read. Do you recommend a resource to learn rails for the reactjs developer? Seems like only the opposite exist nowadays. As someone who created their app in Next.js this year, I can tell you the Node.js ecosystem is in absolute shambles. We are making a WYSIWYG / ecommerce platform for authors, so we need the ability to make and preview live changes. After finishing our MVP with a no-code solution, we decided to move to a custom Next.js app in as little time as possible. Big mistake. I had the urge to dig into Rails but I was much more comfortable in React. That being said, it's been a nightmare dealing with package upgrades, ESM vs CJS, running tests, adding Typescript, etc. I believe, for example, creating the preview component would have been significantly faster in Rails than Next.js. Recently we migrated to Next.js v12 for speed improvements. So many roadblocks. It took forever to debug. Again, mostly due to dependency resolution issues. Blitz.js is supposedly going to be the Rails of JS but there is no way they'll ever have the support that either Next or Rails will receive.
- logankeenan 5y ago
  The Ruby on Rails Guides are fantastic starting place https://guides.rubyonrails.org/ https://guides.rubyonrails.org/.
jarek83 5y ago
Nice to see that front-end people find it so good to change to Rails. Have you discovered Hotwire already? It helps get JS to the minimum, just like it was the early days - only use it to add interactions.
midrus 5y ago
I'm having the same experience you're mentioning with Laravel and Livewire. It's an amazing and simple way to ship really robust and reliable web apps in a fraction of the time.

nunez 5y ago

I’m with you. Writing and testing Ruby is a blast, and it’s so easy to write clean, readable code with it. Performance isn’t great, but it’s just so nice. Rails adds a lot of nice magic on top that makes it even better. JavaScript (even with TypeScript) and frontend frameworks are…quite a journey by comparison.

baash05 5y ago
I love the lang.. TBH though performance has never been something I see as a fault in the language. I've almost always found (for my apps) that it's data access that's the hold up. Like if I map the issues, n+1 or bad indexing have almost always taken the lions share of slower code bits. It irks me when people sight the lang or ruby as having bad memory or being slow. I've seen a tweak of the indexing cut response time to 25%. I even managed a 10x gain off of one index adjustment.
CraigJPerry 5y ago
>> Performance isn’t great I see so much focus on this on web frameworks generally and it strikes me as almost always the wrong thing to optimise for. I don’t know rails, the last time i tried it was circa 2007 and yet I’d confidently adopt it given the right situation. If i had a choice between shipping features 2% sooner or saving $10k / year on server costs, I’d almost always choose sooner. Let’s be honest, a rails dev team is moving more than 2% faster than a java/c# web dev team. If i have 5 devs and they’re all 2% more productive, that could be around $10k of free developer output but it’s more than that, developer productivity compounds. 75% off my server costs doesn’t.
- brigandish 5y ago
  The problem with this comparison is that a language like Crystal shows that you don't have to give up the expressiveness for performance.
montblanc 5y ago
Stay tuned about performance, the Ruby JIT being built by Shopify is gonna narrow the gap. It's now 25-30% faster than CRuby , we'll see in a year how faster it gets. Source: https://speed.yjit.org/ https://speed.yjit.org/
ydnaclementine 5y ago
> Perfomance isn't great I would argue that the performance hit isn't from ruby or the framework, but from people abusing the database with lazy loading in active record. Force people to fetch all the data they need in one query (similar to Ecto), and your performance will improve. There's some config value that disables lazy loading too
- projct 5y ago
  This is the most common slowdown I've seen in rails before. strict_loading mode can help, as can the bullet gem. That said, it is also quite slow when you actually do need requests per second or rows per second, but the usual thing is to throw more machines at it,reduce the amount of magic in the hot path (like activerecord-import for bulk data if that's still maintained,) or use something else for the hot path.
- nunez 5y ago
  To clarify, performance isn't "great" (i.e. Ruby tends to be slower than writing the same code in, say, Go), but it's good enough for most things.

scottc 5y ago

Interesting read. Do you recommend a resource to learn rails for the reactjs developer? Seems like only the opposite exist nowadays. As someone who created their app in Next.js this year, I can tell you the Node.js ecosystem is in absolute shambles. We are making a WYSIWYG / ecommerce platform for authors, so we need the ability to make and preview live changes. After finishing our MVP with a no-code solution, we decided to move to a custom Next.js app in as little time as possible. Big mistake. I had the urge to dig into Rails but I was much more comfortable in React. That being said, it's been a nightmare dealing with package upgrades, ESM vs CJS, running tests, adding Typescript, etc. I believe, for example, creating the preview component would have been significantly faster in Rails than Next.js. Recently we migrated to Next.js v12 for speed improvements. So many roadblocks. It took forever to debug. Again, mostly due to dependency resolution issues. Blitz.js is supposedly going to be the Rails of JS but there is no way they'll ever have the support that either Next or Rails will receive.

logankeenan 5y ago
The Ruby on Rails Guides are fantastic starting place https://guides.rubyonrails.org/ https://guides.rubyonrails.org/.

jarek83 5y ago

Nice to see that front-end people find it so good to change to Rails. Have you discovered Hotwire already? It helps get JS to the minimum, just like it was the early days - only use it to add interactions.

midrus 5y ago

I'm having the same experience you're mentioning with Laravel and Livewire. It's an amazing and simple way to ship really robust and reliable web apps in a fraction of the time.