The beauty of rails is how simple and quick it is to get a robust (if bare) application up and running.
Even if you use sinatra or padrino instead, the wealth of the web community built around ruby still makes it rather easy.
If I were a tech lead and had to make a choice now, in 2019, I would still (probably) choose rails-api for a backend with some separate frontend.
I've been slowly working on a backend for a web app in Rust, and it's really made me realize the sheer amount of things rails provides for you. It has its problems, of course, but so does everything else.
Devise[1] alone makes it worth using rails for many webapps. Throw in things like simple form[2] and will paginate[3] and it's incredible how much you can get done cleanly and quickly. Using something like intercooler.js, you can build a solid modern web app in a fraction of the complexity of most systems today.
1 - https://github.com/plataformatec/devise
> Great for CPU-intensive tasks.
Ruby is among the slowest languages out there. Which is fine for most webapps, but calling it great for CPU intensive tasks... I don't understand what logic is being used to come to this conclusion.
I love Ruby/Rails and owe my career to it, but I don't see the advantage of choosing this stack in 2019 over Elixir/Phoenix for greenfield projects. Elixir tooling and libraries are now up to par and I'd argue have surpassed RoR.
At this point, it's just as productive (perhaps even more as you don't have to glue on a bunch of additional components) and joyful to work with like RoR but massively scalable out of the box thanks to the Erlang VM.
Among my peers (undergrads in college) Rails has largely lost mindshare to python and Node (and even PHP!). At the 3 hackathons I went to this semester I could not find a single other person who knew Rails (so I always have to switch to node or python). If you take a look at devpost, Rails is increasingly losing popularity: https://devpost.com/software/built-with/ruby-on-rails
My plea to the Rails community and Rails senior devs:
1) Fully embrace SPAs as an option, React and Vue are ubiquitous among my peers. I've seriously seen people who have difficulty understanding a for loop that know how to use react at a basic level.
2) Increase your outreach to hackathons and universities, I'd love to see more Rails companies coming out to the big hackathons and mentoring students. At the biggest hackathon in MLH (Bitcamp 2019) I couldn't find a Rails or Ember mentor. I'd also love to see more courses on coursera and other places that teach Rails, in my search for Rails courses on Coursera I only found 1 course (although Traversy media has been making some great content on youtube)!
Rails is ideal for the "Get Shit Done" approach to development. However, Ruby's type system does not provide many assurances, making mature codebases harder to maintain, refactor, and extend (as compared to codebases in, say, well-written Java). I am surprised this was not listed as one of the criticisms. Sorbet, a type checker for Ruby, stands to make this criticism less valid: https://sorbet.org/
I run engineering at Calendly - We are on Rails and it's been great for us for multiple reasons.
1: There's a large ecosystem or gems to do almost anything you need for basic SaaS apps
2: We are based in Atlanta, and there aren't too many Rails developers here compared to out west. However, the language of Ruby itself is easy to learn - we have hired engineers with backgrounds in PHP, Scala, JavaScript, Python, etc.. and they were all able to pick up Rails within 30 days.
3: The framework (in general) encourages good practices. Easier to avoid terrible database schema naming and structure.
The downsides for rails which we experience is in our builds - takes a long time to run tests and precompile assets, and it hasn't been straightforward thing to solve.
Whenever I read about Rails it makes me want to try it again and "understand" it this time... But it always ends up feeling wrong, and I go back to old reliable Django.
I can't put my finger on it, but Django just feels intuitive to me and Rails just feels strange. Maybe it is the convention over configuration mindset which results in lots of magic, but I just can't get comfortable using Rails.
I love the idea of Rails and it's community, but I don't think it will ever be the tool for me.
And as a Django + Python lover, I feel the need to refute the idea (not just in this article) that it is mainly for academic/scientific purposes. Python is a great general purpose language which can do just about anything. It's not the best tool for every job, but for the generalist, it is wonderful. And Django is incredibly solid and can build an MVP in no time. And maybe I'm just a bad developer, but I don't see how the extra configuration necessary when using Django vs Rails is going to add up to much time at all when building your MVP. Is a couple of extra hours really going to make a difference?
Ruby code is like poetry. Rails code is like a song.
Working with RoR always made you feel being like an artist, instead of being only a software developer.
RoR is always my inspiration on how to design a software from start to finish.
Frameworks like Rails/Django are still an extremely viable way to go; even just for an API. I've seen so many cases of early microservices adoption when something like RoR would have saved them a ton of headache. If you need that kind of scale then great, but it's more likely that "you ain't gonna need it".
> What is special about Ruby? Blocks
As far as I can tell, blocks are just some sort of hack to get around the performance overhead of using lambdas. They feel like more of a bug than a feature. Why, otherwise, would it be sane to have an ubiquitous feature that is almost a lambda, but less flexible, while also having lambdas that no one uses.
Ruby was my first programming language. I would agree that it's natural feeling, but it is the opposite of simple.
Threads like these are really interesting to me.
Our fascination with which language /framework is the best, most performant, whilst understandable (we are all attracted to shiny technology) misses an important point.
Engineering is all about trade offs and there are plenty of technologies that are comparable nowadays.
I think it's more a matter of picking something that makes sense for you and your team as well as the particular problem you are tackling and sticking with it than engaging in a holy war.
For example if you need great concurrency support.. perhaps you are better off with elixir if you need heavy computations.. go for python if you need safety, then perhaps look at go or rust
Rails really optimizes for developer happiness, comes with a huge ecosystem and is mature enough that can be called a boring, stable technology to build on. That being said, it certainly isn't the right choice for everything.
Disclaimer: I mainly use ruby on a day to day basis but also love elixir, python and even go.
Fun story from Gitlab:
When our Co-founder and Engineering Fellow Dmitriy Zaporozhets decided to build GitLab, he chose to do it with Ruby on Rails, despite working primarily in PHP at the time
GitLab CEO Sid Sijbrandij thinks his co-founder made a good choice:
"It's worked out really well because the Ruby on Rails ecosystem allows you to shape a lot of functionality at a high quality," he explained. "If you look at GitLab, it has an enormous amount of functionality. Software development is very complex and to help with that, we need a lot of functionality and Ruby on Rails is a way to do it. Because there's all these best practices that are on your happy path, it’s also a way to keep the code consistent when you ship something like GitLab. You're kind of guided into doing the right thing."
Can anyone else find a source about Etsy being based on Rails? I thought they were primarily a PHP/Node shop.
I stopped reading at "Python, the language used in Django, is a language very commonly used for academic purposes, whereas the Ruby community — thanks to Rails — is more business-oriented."...
Rails doesn't scale, or more accurately described as Rails does not scale easily or cheaply. A lot of people doing consultation may have heard their client ask if they should switch to something else because Rails does not X, or Y or Z. ( Normally the standard reply is But GitHub and Shopify is using Rails as well, which should settle the argument )
Rails, by default is still viewed as a Server Rendered Only Framework. Although its API Mode could be used with any front end such as Vue.js, it doesn't seems to be well known or gaining any momentum.
I am wondering if Ruby Rails will ever pick up something similar to liveView [1], instead of sprinkle of Javascript, LiveView could get rid of it. It fits the narrative of Ruby Rails, and for those that don't like it could still use it as Rails-API and some other front end.
Edit: Turns out there is something similar on Rails called Fie. [2]
[1] https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera...
I think I'd only ever choose RoR for a throwaway project, in 2019. I do love RoR and the development experience but Elixir and Phoenix give me almost exactly the same feeling but with WAY better performance and an Immutable/Functional language that results in much cleaner and better code. It's an investment to learn Elixir but it's 100% worth it and honestly I'd choose Phoenix over Rails almost every time.
> Rails is for CPU intensive operations WHILE NodeJS is for IO intensive operations.
The whole comparison they did on this link is flawed. https://thebittheories.com/rails-vs-nodejs-the-comparison-fe...
AFAIK, from v0.12 NodeJS was always faster than Ruby runtime. Although author might be referring to some c-extension hacks which Rails framework uses.
Ruby Vs NodeJS computation benchmark: https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
> Ruby is multi-threaded in its operations in contrast to NodeJS which makes it much better for CPU intensive operations.
>NodeJS is single threaded and was designed for heavy I/O bound applications and is great in this domain. BUT when it comes to heavy computing requirements, NodeJS is terrible.
OMG people still don't understand concurrency and parallelism and how to reap out maximum throughput out of CPU bound an IO bound tasks.
I had the opportunity to run some hackatons / startup coaching last year with some CS student at University of Wisconsin- Madison. I spoke in front of some large lectures and asked students what languages they were learning.
Literally no one out of a few hundred students was learning ruby. Go/nodejs/etherium is what people were putting their energy into.
I used to do a lot of work in Rails in around 2012-2014. Around 2015 or so I sort of pivoted out of web development and more into data engineering, so I took a bit of a hiatus from making side projects/web apps. When I revisited Rails years later, it seemed like so much had changed with all of the new versions and updates that it seemed like overkill, I just shrugged and ended up using Sinatra instead.
Is there a good resource out there for someone who used Rails 2.x / 3 a lot years ago to get caught up to speed on what they need to know to get up and running with the new(er) versions?
maybe consider https://amberframework.org/ it's fast. type-safe, and imitates scaffolding and other rails features...
I don't really enjoy writing Ruby, but rails is the most productive framework I've ever had the pleasure of working with.
I recommend it without hesitation for startups all the time.
This looks like an SEO grab.
Lots of key words all over the page.
Did anyone find anything useful? Some basic programming language advice... Is this an HN Affiliate?
Ruby/Rails backend with a React FE seems to be pretty popular these days, and is where I spend most of my time, but honestly I'd rather go back to Rails views with Stimulus for some of the components that need it.
3 years ago we were breaking monoliths into microservices, now it seems that we overshot that, and I'm much more likely to see people sticking with one main monolith, and maybe one or two other services. Similarly, I'm much more likely to see people choosing NOT to use JS frameworks these days than use them.