It’s 2010. You want to build an web application. PHP is dead. Java is dead.
Use Rails
If you’ve got a blank slate, use Rails. If you’ve only built a prototype, switch to Rails as soon as possible. If you decide to ignore Rails you’re one of two things:
- Much smarter than me. You’ve won several awards for your coding chops and you’re building a new Erlang framework that will replace Rails in 6 months
- A complete buffoon who knows nothing
So, before you start hurling tomatoes at me, here are five reasons you should use rails:
1. Intelligent Defaults
The Rails team has some of the smartest technologists working to improve the standard behaviors in the framework. One example of this is error validation and the flash message. The flash message is used to provide feedback to the user after an action has been taken. Things like “Thanks for signing up” or “You need to fill in an email address”. Rails defaults are more intelligent. The default flash message behaves in the way users expect. Other frameworks I’ve seen used on software projects like Seam and Zend have extremely awkward standard behaviors that cause user confusion. Every default you need to correct sucks time away from doing cool things. There are hundreds of examples of intelligent defaults within Rails.
Don’t believe me yet? Pluralize is another. Rails can automagically pluralize words like “user” or “person”. 1 person, 2 people. Rails gives this to you for free too. Think about the sites you know out there built on crappy frameworks that do things like 100 user(s). Why be one of them? Why build it yourself?
2. Super-fast Deployment
Im going to highlight heroku here because this is the way deployment should be:
git push heroku master
That’s it. If your deploy process takes more than 1 – 5 minutes, consider switching to Rails. (Also see Capistrano for deployment)
3. Gems
If you don’t get something for free in core rails, the next place to try to find it is in a Gem. Gems allow you to do harder things really easily – like connecting to twitter, or facebook, or processing images. The same intelligent people working on rails extend it with gems. As of this writing there are over 11,000 gems that a developer can install to make life easier.
As one example, I had a side project where I wanted to make pretty urls – like my.com/people/colin rather than my.com/users?id=23. On a java project I worked on, it took a developer a day of work to get Pretty URLs working for me. It took me 20 minutes using friendly_id, a rails gem.
There are great rails gems for almost EVERYTHING. That’s part of what you get with a solid community.
4. Community
The last thing you want to do is build your application on a framework with a dead community. The community improves the framework, provides support, and shares knowledge about the best way to do things. The rails community is the most intelligent and active developer community on the web right now. That’s why you have a gem for almost everything – and sometimes more than one. The rails community is innovating and other people are borrowing ideas from them. But if you’re anywhere else, you’re already behind the curve.
5. Synergy
Put all of this together and you get every business douchebag’s favorite buzz word: Synergy. You can build better web applications faster. My friend Euwyn thinks you can build a basic version of any application in rails in a weekend. I agree. When everything else feels like an uphill battle, ride the rails and get more done in less time.
What about Django?
This article could have been written about Django too. I like and recommend Django as an alternative to Rails, but it really depends on what your developers prefer. If you have a developer trying to convince you to use something other than Rails or Django, find a different developer.
Convince me I’m wrong
Please, convince me. Show me some alternatives that allow you to develop better applications faster than Rails. I don’t think they are out there right now.
12 Comments
I'll play devil's advocate (however, I do prefer working with Rails vs other options, so we'll see how convincing I am).
PHP and Java aren't dead. Java is probably a case of different tool for a different job. PHP, on the other hand, is quite widespread in the web development world. Startups like Facebook, Digg, Flickr, etc all use PHP. I'm sure there are quite a few smart developers at those startups/companies who would convince you to try something other than Rails or Django.
You should also take into account “rails”-like frameworks that exist for PHP, such as CakePHP.
Every reason you list is in someway related to rapid development gains you receive in the beginning due to using a framework (niceties built in or leveraging the community to solve a specific need for your application). This really is outstanding and a vast improvement over, say, 5-6 years ago when these frameworks really didn't exist.
However, most successful applications will eventually run into limitations as a result. These limitations usually revolve around scaling and/or maintenance, and can sometimes erase all gains from using the framework in the first place.
Why is scaling an issue for Rails? 1) The framework makes it easy to forget about performance bottlenecks, such as database load and query performance. This can be alleviated with a few course corrections early on. 2) Ruby, the language behind Rails, has some issues to take into account as well.
Why would maintenance be an issue? Focusing solely on speed of development generally means less focus on test driven development. If your goal is to reproduce the functionality of a site in a weekend (most likely sacrificing adequate test coverage) and use it as a foundation for a long-term project, you'll hit a wall of technical debt where you have to take a step back and spend time cleaning up the mess you've made (while producing 0 business value).
In conclusion, if you're building a throwaway project, then Rails or another rapid development framework is a no-brainer. You'll realize almost all of the positives that come along with such frameworks without any of the long-term challenges.
If, on the other hand, you're setting the groundwork for a successful business, taking a little bit of extra time in the beginning (to create automated test suites, think about performance, etc) will continue to pay off for the life of the company.
The only issue I have with Rails is that it uses Ruby, which I dislike as a language. I think it's cryptic and appeals to bad traits in programmers, namely that of creating personal dialects and simply getting too damned cute. Maybe we need python on rails.
There's always Django I guess. I rather like Ruby, but I can see how things are a bit confusing. Instead of attaching some sort of character to things to signify what it is, we end up using a lot of semi-weird naming patterns to signify things. Post, Posts, :post, post, @post. All gets a little confusing, and even worse you might be using them all together. @post = Posts(:post) or something silly like that.
Rails sometimes gives you too much however. For smaller things I like Sinatra (for simply Restful applications) or Padrino (build on top of Sinatra) for web apps.
I should hasten to add that Rails has a very large developer community and gems to do just about anything, which is a huge positive.
I should hasten to add that Rails has a very large developer community and gems to do just about anything, which is a huge positive.
I've certainly seen people write some pretty horrid Rails code that took months of revision to get up to scale.
A few points:
1) Scaling is a database issue: While Ruby isn't the fastest language out there, scaling issues generally come from database problems. You can certainly get into a mess with ActiveRecord and not writing your own queries, or at least not thinking about what is happening. I saw one page that had in excess of 10,000 queries run per page load because someone wasn't thinking.
Should you run into an issue that is a speed bottleneck (such as parsing a large amount of JSON or something) then you just use C to build that part of a gem.
2) Good Rails programmers write tests- Lots of them. It is certainly possible to build a lot without ever writing a test, but that is true with any language. I don't remember my CS101 class in C/Java talking about testing upfront as much as any decent Rails/Ruby book will.
3) Rails for Rapid Prototyping- Rails is absolutely killer for rapid prototyping. It gets the idea done; quickly. Yea, that can hit scaling issues but I'd rather have a startup with scaling issues than nothing done at all or find that I'm 6 months behind the competition. Fixing scaling issues can cost money, but hopefully by the time you're at that point you're making money (or have at least obtained investment). When you do reach Twitter or Facebook size then you can take your millions of dollars, write your own custom NoSQL datastores and switch to Scala, or just write the entire thing in C. More startups die from the idea never happening than from scaling issues and I'd much rather have the latter.
I've certainly seen people write some pretty horrid Rails code that took months of revision to get up to scale.
A few points:
1) Scaling is a database issue: While Ruby isn't the fastest language out there, scaling issues generally come from database problems. You can certainly get into a mess with ActiveRecord and not writing your own queries, or at least not thinking about what is happening. I saw one page that had in excess of 10,000 queries run per page load because someone wasn't thinking.
Should you run into an issue that is a speed bottleneck (such as parsing a large amount of JSON or something) then you just use C to build that part of a gem.
2) Good Rails programmers write tests- Lots of them. It is certainly possible to build a lot without ever writing a test, but that is true with any language. I don't remember my CS101 class in C/Java talking about testing upfront as much as any decent Rails/Ruby book will.
3) Rails for Rapid Prototyping- Rails is absolutely killer for rapid prototyping. It gets the idea done; quickly. Yea, that can hit scaling issues but I'd rather have a startup with scaling issues than nothing done at all or find that I'm 6 months behind the competition. Fixing scaling issues can cost money, but hopefully by the time you're at that point you're making money (or have at least obtained investment). When you do reach Twitter or Facebook size then you can take your millions of dollars, write your own custom NoSQL datastores and switch to Scala, or just write the entire thing in C. More startups die from the idea never happening than from scaling issues and I'd much rather have the latter.
Padrino looks cool http://www.padrinorb.com/ . Django admin with Sinatra simplicity. I'd imagine people on the core team at these smaller frameworks get fatigued supporting a small community. Building and maintaining these things require a lot of time and effort. I wonder How many niche frameworks will be actively supported in a year?
Oh, definitely agree. There's a balance between not worrying about scaling issues at all and spending all your time optimizing and getting nothing done.
As part of the padrino core team, I can say that you are right that maintaining our framework requires a lot of time and effort. What helps us stay active is that all three of us do our own contract work / professional development in Padrino. I have several client projects in Padrino myself and Davide (italian core developer) has over 15 sites developed in Padrino. We have a vested interest in keeping Padrino rock-solid and its continued development. I suspect anybody not 'eating their own dog food' in the case of a framework will not last long keeping it actively maintained.
That being said, I am glad to hear tibbon that you are using Sinatra / Padrino for your development. And thankfully Padrino doesn't force you to sacrifice any speed as shown in our benchmarks here: http://www.padrinorb.com/blog/padrino-0-9-10-re...
I personally use Grails, as I'm more accustomed to Java.
I personally use Grails, as I'm more accustomed to Java.