Virtually everything on earth that has gorgeous benefits also has one or two disadvantages. With all the benefits you enjoy using Ruby on Rails, there are also some disadvantages that come with it, and it won’t be fair to totally ignore this fact. Below are some disadvantages attached to Ruby on Rails.
Ruby on Rails has a relatively low boot speed.
The major challenge of the Rails framework you often hear from developers working in Ruby on Rails is the boot speed. Taking the number of files and gem independence into consideration, it takes a too much time to start and this can greatly affect the performance of developers. Although the new version of Rails has been improved upon to an extent in this area, we still feel more could be done to make it faster.
Compared to some software, the running time of Ruby on Rails is slow.
Among developers, a common argument that mostly ensue is that Ruby on Rails is slow. This is somewhat true when compared to the runtime speed of other software such as GoLang or NodeJS. Although it is true that the runtime of Ruby on Rails is slow, but in reality it is unlikely that its performance be a snag for a business. If there would be a bottleneck in any case, it is sure going to be elsewhere such as within the IO, engineering team, server architecture or database etc. when you have a reasonable amount of scale to worry about the runtime speed of Ruby on Rails, then it is likely that you get an incredible successful application and will get numerous scaling issues to attend to.
Some of the IO libraries of Ruby on Rails do not support Multithreading.
Although Rails supports multithreading, some of the IO libraries don’t do that, they only keep hold of the Global Interpreter Lock (GIL). This implies that if you are not cautious enough, there will be a queue up of request behind the active request, and this can greatly affect performance. But generally, this should not be a case to worry too much about. If the library you use relies on Global Interpreter Lock, you can simply switch your setup to multiprocess. The only effect is that your application will consume a lot of compute resources than required, which can increase cost of infrastructure.
The issue of Documentation.
It is pretty difficult to find documentation, especially for gems that are less popular and libraries that heavily make use of mixins, and this typical of Ruby on Rails. Most times, what you end up finding is test suite as documentation and you will have to rely on this for proper understanding of behaviour. This does not necessary mean that the whole process is bad, but you have to make sure that the test suite is updated regularly, which could lead to frustration diving into code, when it could have been much quicker with written documentation.
These are some of the challenges in Ruby on Rails, but the good thing is that they do not put a hold in accomplishing task.