Ask HN: Updated recommendation on Rails versus Django?
38 comments
You're thinking of putting aside 3 years of experience in Rails and Ruby in order to learn a new language + framework. On a project that you're taking friends and family funding for.
While it's easy to pick up a language or framework, you only pick up best practices by constant usage and community involvement. How are you going to assess the Python and Django competency of your hires if you're that new to a language? How will you make competent estimates for a technology unfamiliar to you?
Both frameworks have been successfully used to rapidly prototype web apps. When you say "make the right technology decision", that is always defined by context. And in your context you have 3 years of experience in one, and 0 in the other. Unless the new technology is demonstrably far superior to the incumbent one, you'll probably be better served by going with what you know.
Note that my answer would be the same if Rails and Django were reversed in your post.
While it's easy to pick up a language or framework, you only pick up best practices by constant usage and community involvement. How are you going to assess the Python and Django competency of your hires if you're that new to a language? How will you make competent estimates for a technology unfamiliar to you?
Both frameworks have been successfully used to rapidly prototype web apps. When you say "make the right technology decision", that is always defined by context. And in your context you have 3 years of experience in one, and 0 in the other. Unless the new technology is demonstrably far superior to the incumbent one, you'll probably be better served by going with what you know.
Note that my answer would be the same if Rails and Django were reversed in your post.
I am obviously biased, as I run a django development company. That said, Ill start with answering the drawbacks of Django,
1. Learning curve.
Not more than any other framework. Plus the Documentation is top notch. (The documentation was what sold me when I was evaluating.)
2. Smaller community
Definately true. But beyond a critical size, size of community does not matter. Django is well above that size. (Irc: any given time ~200 Devs. Google group: 14000+ Users )
3. Slower development cycle of the project itself?
Why? If you give more details, I can answer that.
4. (un)Availability of offshore resources
Definately less than Rails, but still not as bad as you would have thought. A very small list, http://uswaretech.com/blog/2009/03/web-development-companies...
Thats said, given the information you have, I your case I would choose Rails. Even if most of the work you are looking to offshore, your existing Rails experience would be a huge plus, helping you evaluate vendors, keep track.
1. Learning curve.
Not more than any other framework. Plus the Documentation is top notch. (The documentation was what sold me when I was evaluating.)
2. Smaller community
Definately true. But beyond a critical size, size of community does not matter. Django is well above that size. (Irc: any given time ~200 Devs. Google group: 14000+ Users )
3. Slower development cycle of the project itself?
Why? If you give more details, I can answer that.
4. (un)Availability of offshore resources
Definately less than Rails, but still not as bad as you would have thought. A very small list, http://uswaretech.com/blog/2009/03/web-development-companies...
Thats said, given the information you have, I your case I would choose Rails. Even if most of the work you are looking to offshore, your existing Rails experience would be a huge plus, helping you evaluate vendors, keep track.
If you've borrowed money from family and friends to hire some developers in order to get something working as quickly as possible you should use whatever tools are going to help you make that happen. You probably don't want to be tinkering around with a new language and framework on top of having to work with developers you're unfamiliar with when you're dealing with a project of this importance. Use what you know. If you have reservations about Ruby and Rails start thinking about one of the other languages you've used to get important work done. You can always explore other options once you're making some money and have paid back your initial investors.
Personally, I'd be a little miffed if someone accepted my investment for a specific project and then was using that project as a testbed for some fad web framework for no good reason. These people have placed their trust and money with you. You have a responsibility to deliver now.
Personally, I'd be a little miffed if someone accepted my investment for a specific project and then was using that project as a testbed for some fad web framework for no good reason. These people have placed their trust and money with you. You have a responsibility to deliver now.
At the same time, if I simply had stuck with what I knew over the years I'd still be doing old ASP...i'd be more miffed as an investor if you had a great idea but killed it because you did it in vbscript just because that is what you knew, or if you chose something that would cost a lot more to scale, thus requiring greater investment just to see a return.
That might be relevant if we weren't talking about modern and very actively developed web frameworks on modern and quickly evolving languages.
I've done projects in both Django and Rails. Your list of Rails drawbacks is weak. The magic can bite you but most of the time it doesn't. Documentation on any open source project is usually pretty bad. Both Rails and Django have about the same level of documentation at this point. The API is no more inconsistent than anything else.
The minus I encountered with Django is that it isn't as far along with the nice auxiliary pieces that exist alongside Rails. Gems are much better than easy_install or eggs. Phusion passenger is easier to deal with than... whatever Django is doing these days. Capistrano is better than Fabric. Heroku is better than App Engine.
What I liked about Django is that integrating other Python libs was easy, and some of them are way better than the Ruby equivalents. PIL is way better than any of the Ruby image manipulation libraries. Django also makes it easier to do GIS stuff out of the box.
In my experience the REAL problem with rails is that if you're actually doing high-load transactional sites, like serious e-commerce systems, it is not up for the task. The successful Rails sites I built mostly had few inserts and a lot of reads. Tons of transactions == meltdown in ways neither I nor professional rails consultants understood. Those pieces were ultimately re-architected in Java (with some JRuby to help out). I'm not convinced Django would help with a site like this.
The minus I encountered with Django is that it isn't as far along with the nice auxiliary pieces that exist alongside Rails. Gems are much better than easy_install or eggs. Phusion passenger is easier to deal with than... whatever Django is doing these days. Capistrano is better than Fabric. Heroku is better than App Engine.
What I liked about Django is that integrating other Python libs was easy, and some of them are way better than the Ruby equivalents. PIL is way better than any of the Ruby image manipulation libraries. Django also makes it easier to do GIS stuff out of the box.
In my experience the REAL problem with rails is that if you're actually doing high-load transactional sites, like serious e-commerce systems, it is not up for the task. The successful Rails sites I built mostly had few inserts and a lot of reads. Tons of transactions == meltdown in ways neither I nor professional rails consultants understood. Those pieces were ultimately re-architected in Java (with some JRuby to help out). I'm not convinced Django would help with a site like this.
No offense, but how amazing can your idea be if it allows you to procrastinate on web frameworks?
No offence, but why is evaluating technologies which you are going to be stuck with for a very long time a bad thing?
Because, in all likelihood, worrying that you're going to be stuck with your initial choice of technology for a very long time is premature optimization. You should be so lucky.
I have no idea what the original submitter's idea is, but I'll still predict how it's going to work out: It won't find product-market fit. So it won't need to be maintained for a very long time. So he might as well just build it with the framework he already knows, get it over with, and move on to the next idea.
Anyone want to bet that I'm wrong? If so, please make out your angel checks to the original submitter.
Moreover, while fretting too much about the apparent greenness of the grass on the other side of the fence is always a warning sign of procrastination, doing so when you already have three years of Rails experience and know exactly where its pain points are is really a sign of procrastination. Just build the thing already! You will save time by working in a framework that you already understand. And, if you like, you can use that saved time to improve the bits of the framework that you dislike.
I have no idea what the original submitter's idea is, but I'll still predict how it's going to work out: It won't find product-market fit. So it won't need to be maintained for a very long time. So he might as well just build it with the framework he already knows, get it over with, and move on to the next idea.
Anyone want to bet that I'm wrong? If so, please make out your angel checks to the original submitter.
Moreover, while fretting too much about the apparent greenness of the grass on the other side of the fence is always a warning sign of procrastination, doing so when you already have three years of Rails experience and know exactly where its pain points are is really a sign of procrastination. Just build the thing already! You will save time by working in a framework that you already understand. And, if you like, you can use that saved time to improve the bits of the framework that you dislike.
"fretting too much about the apparent greenness of the grass on the other side of the fence is always a warning sign of procrastination, doing so when you already have three years of Rails experience and know exactly where its pain points are is really a sign of procrastination. Just build the thing already! You will save time by working in a framework that you already understand."
I don't disagree, but I think I should point out the danger -- this is exactly how programmers become dinosaurs in the industry.
Next time you feel the urge to make fun of that guy with 20 years of C++ experience, keep in mind that he was probably just working in a framework that he already understood. One day you look up from your last successful project, and everyone is 22 years old and coding in Blub. Only those old guys are working with Rails....
I don't disagree, but I think I should point out the danger -- this is exactly how programmers become dinosaurs in the industry.
Next time you feel the urge to make fun of that guy with 20 years of C++ experience, keep in mind that he was probably just working in a framework that he already understood. One day you look up from your last successful project, and everyone is 22 years old and coding in Blub. Only those old guys are working with Rails....
I can't argue with this in general, but it hasn't got much to do with the case at hand. Worrying about the day when Rails will be a dinosaur technology is an even more extreme form of premature optimization. And if you are trying to hedge against Rails' obsolescence, why would you pick Django? Shouldn't you pick something sufficiently different that it isn't routinely mentioned in the same sentence?
I'm not worried about it, and I realize it's a digression. I'm just saying that if every time you face one of these decision points you go with the technology that you already know, then you're optimizing for something different than career longevity, and it will come back to bite you. The point is that there's always a tension in this industry between learning new technologies and being maximally productive.
That said, it isn't "premature optimization" to diversify your portfolio of technologies as much as possible. It's premature to try to guess the Next Big Thing and use it for your project, but that isn't what I'm suggesting. And in any case, five(-ish) years ago, you might well have faced the choice between using Perl and using Rails for a similar project. That decision would have proved fateful.
That said, it isn't "premature optimization" to diversify your portfolio of technologies as much as possible. It's premature to try to guess the Next Big Thing and use it for your project, but that isn't what I'm suggesting. And in any case, five(-ish) years ago, you might well have faced the choice between using Perl and using Rails for a similar project. That decision would have proved fateful.
five(-ish) years ago, you might well have faced the choice between using Perl and using Rails for a similar project. That decision would have proved fateful.
Let's keep some perspective here. Rails, Django, and the various Perl frameworks each have their rabid partisans, but they represent fairly tiny variations on a single theme: Client-server web applications. There is very little danger in overspecializing in any one of these. You can move from one to another with ease. They employ similar concepts, by necessity. The HTTP and the SQL and the CSS knowledge all transfer over. The browser is still the browser. My god, I wish the browser was changing fast enough that I risked becoming a dinosaur!
I suspect that there is far more danger of overspecializing in, say, MySQL than of overspecializing in Rails. Databases are huge, complex beasts with real differences in their implementation and operation, and they can have profound impact on the performance of your app. (Just ask an experienced Oracle DBA. He or she will talk your ear off, as happened here on HN the other week.) The difference between the various brands of glue that we use to stick our databases to our web servers? Not as fundamental as we'd all like to think. The stuff I do today is not much different from what I and my colleagues were doing in AolServer Tcl in 1999. (Now that is dinosaur web technology!)
The real danger of becoming a dinosaur happens at a higher level. I'm a professional PHP programmer now, god help me, but I'm not afraid of missing out on the Great Django Revolution: When Django is finally ready to call my colleagues and I, I'll listen, and I'll probably understand what it's saying because it'll still be speaking the language of server-side web apps. The real danger is that one day I'll wake up and realize that the interesting problems have moved off the web server entirely and that all the fun is in standalone Javascript apps, or iPhone apps, or Microsoft Surface 3.x apps, or Scala applications embedded in your shoes, and server-side web app development has become about as exciting as Internal Revenue data processing (which it resembles in many ways).
When I really want to diversify, I'll look at Javascript or Objective C or embedded systems programming. I won't look right next door. That's too easy. Alas, this means that my track record of never getting around to learning Python may continue. :(
Let's keep some perspective here. Rails, Django, and the various Perl frameworks each have their rabid partisans, but they represent fairly tiny variations on a single theme: Client-server web applications. There is very little danger in overspecializing in any one of these. You can move from one to another with ease. They employ similar concepts, by necessity. The HTTP and the SQL and the CSS knowledge all transfer over. The browser is still the browser. My god, I wish the browser was changing fast enough that I risked becoming a dinosaur!
I suspect that there is far more danger of overspecializing in, say, MySQL than of overspecializing in Rails. Databases are huge, complex beasts with real differences in their implementation and operation, and they can have profound impact on the performance of your app. (Just ask an experienced Oracle DBA. He or she will talk your ear off, as happened here on HN the other week.) The difference between the various brands of glue that we use to stick our databases to our web servers? Not as fundamental as we'd all like to think. The stuff I do today is not much different from what I and my colleagues were doing in AolServer Tcl in 1999. (Now that is dinosaur web technology!)
The real danger of becoming a dinosaur happens at a higher level. I'm a professional PHP programmer now, god help me, but I'm not afraid of missing out on the Great Django Revolution: When Django is finally ready to call my colleagues and I, I'll listen, and I'll probably understand what it's saying because it'll still be speaking the language of server-side web apps. The real danger is that one day I'll wake up and realize that the interesting problems have moved off the web server entirely and that all the fun is in standalone Javascript apps, or iPhone apps, or Microsoft Surface 3.x apps, or Scala applications embedded in your shoes, and server-side web app development has become about as exciting as Internal Revenue data processing (which it resembles in many ways).
When I really want to diversify, I'll look at Javascript or Objective C or embedded systems programming. I won't look right next door. That's too easy. Alas, this means that my track record of never getting around to learning Python may continue. :(
That's why you play around with new technologies in your free time. Then, when it's time to build your next big project, it's not "I have three years experience with X and none with Y; which should I use?" but rather "I have three years experience with X, but I've been playing with Y for the past year and I think it's a better fit."
Yes, yes. The problem comes when you don't have much free time. When you're working on a successful project, it will consume every hour that you can devote to it. If you then want to have a life outside of computers, you find yourself having to make a conscious choice between your main project, and learning new technologies.
This problem becomes far more acute as you get older. When I was in college, I had all the time in the world to experiment with things. These days, I don't have much energy for computers when I'm away from work.
This problem becomes far more acute as you get older. When I was in college, I had all the time in the world to experiment with things. These days, I don't have much energy for computers when I'm away from work.
"Only those old guys are working with Rails...."
And django.
And django.
I'll just the change the ending of what mechanical_fish said,
"i have no idea what the original submitter's idea is, but I'll still predict how it's going to work out: It won't find product-market fit. So it won't need to be maintained for a very long time. So he might as well just build it with the framework he "
doesn't know and learn something interesting along the way. It won't take him much time to be fluent in Django if he is as conversant with Rails as he claims.
But yeah it really doesn't matter whether he uses Django or Rails. mechanical_fish's larger point is still very valid.
I agree with "Just build the thing already!"
"i have no idea what the original submitter's idea is, but I'll still predict how it's going to work out: It won't find product-market fit. So it won't need to be maintained for a very long time. So he might as well just build it with the framework he "
doesn't know and learn something interesting along the way. It won't take him much time to be fluent in Django if he is as conversant with Rails as he claims.
But yeah it really doesn't matter whether he uses Django or Rails. mechanical_fish's larger point is still very valid.
I agree with "Just build the thing already!"
Agree totally... it's important to ask these sorts of questions early...
Here's what I've found so far after starting a small Django gig (I already knew a fair bit about Rails):
- Rails has built-in migration support
- Rails has better support for APIs
- Django has some neat stuff in contrib including authentication and an admin interface
- Django has "pluggables" -- downloadable apps that can be snapped in just like the admin interface. Rails has engines, but they're new and not as mature as pluggables.
- Rails has built-in migration support
- Rails has better support for APIs
- Django has some neat stuff in contrib including authentication and an admin interface
- Django has "pluggables" -- downloadable apps that can be snapped in just like the admin interface. Rails has engines, but they're new and not as mature as pluggables.
> Rails has better support for APIs
What does this mean?
What does this mean?
To be specific, Rails has better support for providing XML and JSON APIs. One place where it has better support is serialization. In rails, there is an :include parameter to control whether to include objects from associations (e. g. comments in a post), that is available both on to_xml or to_json. I don't see an option for Django that does the same thing.
http://api.rubyonrails.org/classes/ActiveRecord/Serializatio... http://docs.djangoproject.com/en/dev/topics/serialization/
http://api.rubyonrails.org/classes/ActiveRecord/Serializatio... http://docs.djangoproject.com/en/dev/topics/serialization/
Probably talking about ready-built libraries. Poorly worded though.
You'd be crazy not to use Rails. If your idea is really all that you say it is, chances are good that someone else has thought of it too. Maybe they are building it right now, maybe not. First-to-market is practically a sine qua non these days, and you're talking about spending the next three months getting up to speed on a foreign technology? If I were you I'd start banging that puppy out in Rails starting like, yesterday.
It sounds like you want 2 things.
1: Build out your killer idea 2: Learn Django and use it
I don't think the transition from Ror to Django should be that big of a deal for you. Ruby and Python are similar enough, and the frameworks have enough conceptual overlap that it shouldn't be that big of a deal for you to switch.
The Django community is very responsive and professional with questions. Posts on the newsgroup usually get answered within hours, and IRC channel within minutes.
If you do go Django, may I suggest Practical Django Projects: http://www.amazon.com/Practical-Django-Projects-Second-Benne...
Also, if you're looking for off shore Django developers, look up a few people on djangopeople.net.
1: Build out your killer idea 2: Learn Django and use it
I don't think the transition from Ror to Django should be that big of a deal for you. Ruby and Python are similar enough, and the frameworks have enough conceptual overlap that it shouldn't be that big of a deal for you to switch.
The Django community is very responsive and professional with questions. Posts on the newsgroup usually get answered within hours, and IRC channel within minutes.
If you do go Django, may I suggest Practical Django Projects: http://www.amazon.com/Practical-Django-Projects-Second-Benne...
Also, if you're looking for off shore Django developers, look up a few people on djangopeople.net.
Look it is just a web app framework. If you know Rails well, you should be able to pick up Django fast (and vice versa). Sure you'll get a few surprises in some edge cases, but hey, in the end it is just a framework that mediates between http requests to databases and generates web pages. How difficult would it be to grok either once you know the other?
fwiw, I've built apps with both, I prefer Django, But I wouldn't agonize about switching to Rails for a project or two if required. And no matter how much advice you get only you can decide which one suits you better and you can decide that only afer using both in serious projects.
Just start writing code.
fwiw, I've built apps with both, I prefer Django, But I wouldn't agonize about switching to Rails for a project or two if required. And no matter how much advice you get only you can decide which one suits you better and you can decide that only afer using both in serious projects.
Just start writing code.
You can't go wrong with any of them. I think Django has a slight edge by having a slower release cycle. I find it a desirable quality in a development framework.
While the number of man-months spent developing Rails is an order of magnitude greater than that spent developing Django, is it really that much better for the bottom line?
Most of the early efforts spent on Rails were to make the infrastructure and community more mature. Even the brilliant DHH was a PHP developer before he started Rails.
On the other hand, Django benefited a lot from Python's maturity.
While the number of man-months spent developing Rails is an order of magnitude greater than that spent developing Django, is it really that much better for the bottom line?
Most of the early efforts spent on Rails were to make the infrastructure and community more mature. Even the brilliant DHH was a PHP developer before he started Rails.
On the other hand, Django benefited a lot from Python's maturity.
> While the number of man-months spent developing Rails is an order of magnitude greater than that spent developing Django
Wildly off base figure
1. Years under development. ROR: 5/Django 5
2. Members in largest google group: ROR 18000+/Django 14000+
3. Members in Irc currently: Ror 436/Django 401
4. Commits to repo: Ror ?/Django 11000+
So while Ror has a bigger community, it is not that much bigger.
Wildly off base figure
1. Years under development. ROR: 5/Django 5
2. Members in largest google group: ROR 18000+/Django 14000+
3. Members in Irc currently: Ror 436/Django 401
4. Commits to repo: Ror ?/Django 11000+
So while Ror has a bigger community, it is not that much bigger.
There is no easy way to measure this. But to support my point:
Rails first public release: July 2004 (5 years back)
Django's first public release: July 2005 (4 years back)
Rails Contributors: 1350
Django Contributors: 460
I never said that Django's community was smaller. I just said that it was more mature in their programming language and therefore it was easier for them to get things done right the first time.
Rails first public release: July 2004 (5 years back)
Django's first public release: July 2005 (4 years back)
Rails Contributors: 1350
Django Contributors: 460
I never said that Django's community was smaller. I just said that it was more mature in their programming language and therefore it was easier for them to get things done right the first time.
Desire(learn django) > Value(rails knowledge) ? django : rails
Nobody can tell you what those values are. Both are acceptable frameworks, just pick one and move on.
Nobody can tell you what those values are. Both are acceptable frameworks, just pick one and move on.
Can someone who knows Ruby and Python contrast their metaprogramming capabilities along with how much mileage Django and Rails get from it under the hood?
Without learning a bit more about the nature of your project, I don't think it's possible to give you meaningful advice. Dish!
What about performance and scalability? Doesn't python (with psyco and soon, unladen swallow) win big here? When you choose a platform, it's important to choose one that won't limit you when you start having users on a large scale...
Unless something changed, django doesn't even run on psyco cleanly and the combo is unsuitable for production. Unladen swallow also isn't ready for use in production with django and it's unclear when it will be. But performance from these languages aren't the bottlenecks in web apps, and Ruby 1.9 and Python 3 have similar performance, anyway.
> Ruby 1.9 and Python 3 have similar performance, anyway.
That's immaterial in this debate, isn't it? Django doesn't run on Python 3, and Python 3 is still slower than Python 2 (though they're starting to focus on performance improvements in Python 3 with every new release).
That's immaterial in this debate, isn't it? Django doesn't run on Python 3, and Python 3 is still slower than Python 2 (though they're starting to focus on performance improvements in Python 3 with every new release).
Scribd might have a thing or two to say about that.
Trust me, Django is almost dead. The hype around Django is completely dead and existing developers are using it, but new developers are not jumping on ship. In 6 years there will be a serious Django shortage of maintanance personell.
Stick with rails and don't make the silliest mistake of your life.
Stick with rails and don't make the silliest mistake of your life.
Any statistics you have to back that up?
I realize this post is an infamous "versus" question, and undoubtedly redundant with older posts. However, most of the information I find on Rails versus Django is out of date and based on much older versions of the frameworks, so please forgive me.
First and foremost...I'm a Rails guy. I came to it three years ago and really enjoyed a lot of what it brought to the table. I'm not solely a Ruby guy...I have around 11 years of total experience, including Java, C/C++, Perl, Tcl, (some) Python, and more.
Anyway, I have an idea I believe will take over the world. I've already convinced a few folks it will as well and have friends and family funding to take on some offshore developers and get it in beta as quickly as possible.
Now, however, I am left with the decision of what tech to use. While I've really enjoyed Ruby...I'm growing tired of the magic, and the abuse of open classes. It's very nice when you need to inject some behavior quickly, but it can become a real pain when you have to maintain your project, or any of the plugins it depends on. I personally prefer Ruby over Python (largely because of blocks), but I envy the clarity-first attitude in the Python community. Given this frustration, I'm seriously considering a deep-dive into Django and using it for this project.
The pluses I see on the Rails side are: 1. Size of community (which, given some of this "community" includes PHP refugees, is not necessarily a plus) 2. My familiarity and experience 3. Number of companies using it and striving to improve it 4. Availability of offshore resources
Drawbacks of Rails include: 1. Too much magic 2. Documentation continues to be awful in places 3. Inconsistent API 4. Did I mention magic?
The (perceived) pluses on the Django side: 1. Clarity 2. Performance...I believe Unladen Swallow will really change the Python landscape and give it a competitive advantage 3. Google's support of the language itself (see #2)
Drawbacks of Django: 1. Learning curve 2. Smaller community 3. Slower development cycle of the project itself? 4. (un)Availability of offshore resources
So, this is my thought process so far. I'm pretty comfortable I could come up to speed quickly on Django, and I have the basics of Python still in my memory somewhere. But I wanted to get your opinions as I really respect the vision and experience of a lot of the folks I read on here.
I appreciate your help. I really think this idea will take off, so it's very important to me to make the right technology decision.
And saying to choose Rails simply because I have experience there just doesn't sound right. If that were the case, I'd still be using Perl or C.
Thank you!