10 reasons not to use rails

Well I posted this before, but it disappeared . Here are 10 reasons you may not want to use rails

1) The learning curve is huge. Just the other day I wrote my own version of cycle I also learned how to inject javascript from a controller.
2) SDLC is broken for teams. Yes Rails is great for a team of one, but version control and deployment is monolithic. For example if two developers independently work on two different controllers with two different views there is no way to version and deploy these components separately.
3) Yet another deployment system. Rails has gems and plugins. The rest of the world uses rpms, debs, wars, and whatever windows uses.
4) Ruby is green threaded. One server is slow you’ll need many-many servers to handle the load. Good thing virtulization is taking off.
5) ActiveRecord breaks down when you want to pivot rows into columns. This use case comes up with catalogs with many topics, each topic containing its own fields. Luckily there is RBatis.
6) The code base is unstable. The main code line and the gems are constantly evolving with little consideration for backwards compatibility. Combine this with poor deployment managment
7) Multi-lingual support is broken. Multi-byte characters aren’t supported, so stick to one language!
8) Rails web containers are unstable. There are many choices for a web container webbrick, mongrel, and lighthttp to name a few. None of them work as well as Apache. The servers get wedged. Apache with Fast CGI doens’t seem to work and those who start using it move on to something else.
9) The code is obtuse and you’ll need to read it. If you want to understands how to do things you’ll need to read the code.
10) The conceptual documentation is missing. Its a framework, yet the concepts go unanswered. For example, what exactly are restfully resources for and why isn’t there a client library?

Leave a Reply