Rails is Still Cool But...

A recent confession by Piotr Solnica started another bit of drama in the Ruby world. I started writing this post just after reading Fabio Akita's response to Piotr's post - for me it shows all the problems with Rails' defensive mindset, but it also reminded me that Rails is still a pretty cool framework. Feel confused? Let's solve that.

The reality is that 80% of the web applications are Basecamp-like (disclosure: my feelings for years of experience in consulting).

That statement amuses me because my experience is completely different. I just started working on an application which really fits into the Rails Way - but it's the first time that I've felt this after four years with Rails and Monterail. On the other hand, maybe it's just a sign that there is huge market for both - Basecamp-like and non-Basecamp-like applications and you can find customers looking for each.

Active Record's architecture will indeed hurt hard maybe 10% of the cases out there.

Rails is a really sharp knife for prototyping. For such (and simple CRUD applications), the quoted statement is true - ActiveRecord could be a problem for just a few prototyping cases.

The reality is that, well, a lot of customers don't understand that a prototype is not an MVP. After all the years with Rails, we all have some experience working with legacy Rails applications. Some agencies even specialize in fixing your legacy code, because it's really hard to deal with a framework that is designed to encourage a monolith which can make things more difficult in the long run.

If you are happy to make your business as successful as GitHub or Twitter, you can invest into hacking around the framework or rewrite some parts into a different technology. But in most cases, you would only suffer to introduce new features, maintain existing ones and fight with the temptation to rewrite everything from scratch.

That's why so many long timers have switched somewhere else. Most of them silently or without loud complaints of Rails. Others have tried to hack around or have started creating an alternative.

Experienced people often forget the learning curve when they were themselves beginners, and at that time Rails was so attractive, so sexy.

That is true but we often forget the price - that Rails teaches us a lot of bad practices. It can harm newbie developers, they will get quick results, but it's hard to fix the damage made to developers that won't have had the luck to be protected by a good mentor.

Everything is so much easier when you have a small community that even if you break things it won't be too bad.

This is a very true statement. Last year during Elixir Conf, Joe Armstrong had a keynote where he said something like beware of growing too early because you can easily change things only if you're small and unknown to a larger audience. That's why you have two options when new issues arise - feel the gut and risk investing time in something that may simply fail before getting any market traction (but you can be the expert when its popularity rises), or jump on the wagon when it becomes more stable and gains more traction.

But it does not change the fact that world currently moves faster than Rails can evolve. The foundation for web development known today was built by Rails (assets compilation, coffee and sass, MVC, and much, much more) but the world is constanly changing and Rails is not able to change fast enough in its current shape.

Why? Maybe because it's a big ball of mud that it's hard to introduce new features? For many previous major releases it was common to push a lot of bug fix releases for regressions or security bugs. Or maybe it's no longer innovative? E.g. the biggest innovation in Rails 5 will be ActionCable. Nothing but integrated interface for Faye, software introduced in June 2009!!

It's not about today. It's about the future. Like with Wordpress in Akita's post, I will probably always choose Rails when I need to create a prototype since it will allow me to do it fast and ignore all the things that don't matter when you are creating short-lived software. But for every other use case, I will be looking for a different technology.

TL;DR

Use the proper tool for the proper case.