Well, any Ruby on Rails criticism, prejudice, myths or other urban legends will be brought out in the open here. Enjoy!
Let’s look at the top 10 Ruby on Rails criticisms.
1) Ruby on Rails is slow
Not exactly. It’s slower than frameworks of other programming languages, like Node.js or Phoenix. However, it is not fair to compare such different frameworks, ‘cause Rails was created on the basis of Ruby.
Since Ruby is an interpreted programming language, it doesn’t immediately compile into executable code like, for example, C++ does. Ruby is first translated to machine code, and only then is a task carried out by the system. Whereas, C ++ is executed directly in the computer processor.
Rails works slower than any narrowly-targeted framework because Rails is a universal framework that contains many default functionalities that a developer doesn’t have to write from scratch or install.
For example, Rails has a default web server, called Puma. Also, with Rails installation, you will get a few default gems, such as webpacker, bundler, logger and many others, each one with its own functionality.
It must be said that most of the time, developers claim that Ruby on Rails is slow because of the initially incorrect project architecture, data caching or database optimization.
Rails is FAST in terms of the project development speed. That is the main advantage of Ruby on Rails. With Rails, you can kickstart your startup in no time, hence, it is perfect for creating MVPs and prototypes.
Related: Pros and Cons of Ruby on Rails
2) Rails takes up a lot of random access memory (RAM)
True, Rails can sometimes have a high memory usage. In fact, this issue is especially notable with small-sized projects. Rails tends to take up lots of memory there.
Usually, we suggest using other Ruby web frameworks, like Sinatra, Hanami or Padrino for small-sized projects instead of Rails.
The reason why Rails takes up a lot of memory: when there are more objects being used than Rails can fit into the memory, the system requests for additional memory.
However, there may be another reason why there is no memory left in the operating system – a code leaking memory on the project. If that’s the case, then it’s better to test and review the code in order to eliminate the problem altogether.
3) RoR’s syntax is not that simple
Correct, it’s hard for newbies to grasp the complexity of Ruby and Rails, though the syntax looks very simple. Ruby syntax resembles the syntax of English sentences in a way. But there is so much more going out ‘under the hood’.
One line can perform many actions that are hidden under the bonnet. For example, if you write a simple line, like ‘user.create’, the system will create a user. However, you may not even know that there will be several processes going on under the hood, such as data validation, parameters matching and connection with a database.
But the funny thing is, once you catch on to the Rails way of coding, it becomes pretty easy to read the code. Most middle and senior developers usually admire how simple RoR’s syntax is. They say that Rails requires zero documentation – that’s how understandable it is.
4) The gems are buggy
No, a filthy lie. Even though Rails is an open-source framework, its gems are created by RoR contributors.
Thus, Ruby on Rails gems are widely used by the framework community and are constantly being tested and improved. Consequently, under such conditions, it’s hardly possible to have Rails gems with bugs. There might be a few slips once in a blue moon, but who doesn’t have them?
There shouldn’t be any problems with gems that go in Rails dependencies. Although some issues may occur while using third-party gems, this can be avoided by using utilities.
5) There are too many tools and gems
Yes, it can be counted as a disadvantage because an inexperienced developer won’t know which one to use. A variety of choices is not always a good thing.
Ruby on Rails was designed for fast development. That is the reason why Rails has so many tools ‘cause they speed up the development process.
Rails has a tool for every problem: Rake, for assembly automation of program code; Bundler, for tracking and installing the exact gems and versions that are required, and RSpec, for testing. But it’s a pity that Rails doesn’t offer a toolkit that includes all the necessary tools for development like Python does.
As for gems, the issue has to do not so much with the number of gems, but with the process of their creation and the gems concept in general.
On one hand, gems make your software development faster, but on the other hand, there are many similar gems for Rails with some slight differences. So while choosing a gem for a certain issue, keep in mind that you’ll need to do some research before installing a gem.
Moreover, the whole ecosystem of Ruby centers around the Rails framework. Thus, when creating a new gem, a developer should take into account all Rails peculiarities, like ActiveRecord and ActiveSupport. Even though a developer might be working with another Ruby web framework, he/she still has to consider a possible gem usage with Rails.
6) Rails has scalability issues
Not true. Ever heard of Basecamp, Groupon, Airbnb and Shopify?
Well, they are all built with Rails. So, this Ruby on Rails criticism is totally uncalled for.
The first thought of RoR being difficult to scale appeared when Twitter had switched from Rails to Scala. It was thought that if such a big company, like Twitter, abandoned Rails then Rails must be no good. But time has passed and has shown that other corporate giants have stuck to Rails and have had an awesome journey with it.
One of the examples is Shopify that has shared their experience in scaling Rails many times. Up to this day, Shopify uses Ruby on Rails to support over 500,000 businesses.
Usually, junior developers believe that Rails is not scalable because they haven’t REALLY worked with Rails on big projects or they’re simply just starting out on their journey with Rails.
Worth noting, scalability issues often occur when there are database performance dysfunctions. In fact, scalability doesn’t depend on a programming language or even a framework.
Related: Ruby on Rails Scalability Issues
There are a couple of solutions if you have scalability issues: Kubernetes, Docker Swarm and Marathon.
7) ActiveRecord is horrific
Yes, Trouble is the second name for ActiveRecord.
ActiveRecord is an ORM used in Rails; a model of an MVC-principle that is responsible for representing business data and logic. ActiveRecord breaks the Single Responsibility Principle, a principle where each element has only one responsibility in which it fully executes and an Interface Segregation Principle, a principle that divides a large interface into smaller parts.
In essence, ActiveRecord tries to do all sorts of things, starting from interacting with a database and ending with data validation.
ActiveRecord comes with over 200 public methods and encourages the use of callbacks and concerns. This is an ORM that is difficult to cope with its growing complexity. Because of this, large projects can be difficult to maintain.
Luckily, developers have found some workarounds. For example, by using dry-rb, a collection of Ruby libraries, Rubyists are now able to work with different components in a more flexible way, since each element is divided into separate components.
Plus, you can always turn to Trailblazer, Ruby’s business logic framework. Just use it on top of Rails for better support.
8) Rails has high coupling
True, Rails was not built with a focus on the low coupling between modules.
Coupling applies to dependency relationships between modules. With high coupling, all components are connected with each other. It’s very hard to use them separately. If the first component is highly dependent on the second one, and you want to use the first one separately, you’ll have to understand how the second one works.
Even if you succeed, there will be big functionality restrictions. However, low coupling provides easier project support and helps to manage complexity.
9) Hostings for Rails are pricey
In a way, prices for hosting vary in different programming languages indeed.
If you compare a hosting for Ruby with a PHP hosting, then sure, Rails would be more expensive. Meanwhile, Python is somewhere in between.
There are always free hostings… but the issue here is that you’ll have to set it up from scratch which is easier said than done.
The best option is to use a virtual private or virtual dedicated server (VPS/VDS) which is equivalent to a dedicated physical server. The advantage of a VPS is its price: it’s much cheaper, however, the performance might decrease since all virtual private servers depend on the shared underlying physical hardware.
10) Rails isn’t cool anymore
Another Ruby on Rails criticism…
Nowadays, it’s pretty common to say that Rails is not that cool anymore or even that it’s already dying.
Usually, these kinds of arguments are poorly grounded.
Analyzing Ruby on Rails criticism, we can see that it has appeared when new languages like Go, Scala, Rust and Erlang have made their entrance.
It’s true that in 2019 Rails is not on hype anymore, though it’s definitely not equal to being not good anymore.
Nevertheless, it has reached its peak of popularity and has grown into a steady and evolving web framework.
Related: Is Ruby on Rails dying?
Final Words
It is true that Ruby on Rails has some weak spots that developers like to criticise a lot. Nonetheless, Ruby on Rails criticism can be sometimes completely undeserved.
An important thing to keep in mind is that Rails has its own target audience and niche-orientation where it massively shines. Creating MVPs and prototypes for startups, building online marketplaces and web applications – these are RoR’s spheres of use.
Moreover, Ruby 3.0 is going to be launched very soon which will fix some of Ruby’s issues, such as speed, concurrency and static analysis.
We have to admit: Ruby on Rails may be cool for your project but maybe not. Click below to get a free 30-minute tech consultation.
