Why is Ruby on Rails more popular than Django?

[Jason Hsu]

I'm currently in the process of learning Ruby on Rails. I'm going through the Rails for Zombies tutorial, and I'm seeing the power of Rails.

I still need to get a Ruby on Rails site up and running for the world to see. (My first serious RoR site will profile mutual funds from a value investor's point of view.)

I have an existing web site and project called Doppler Value Investing (dopplervalueinvesting.com) that uses Drupal to display the web pages and Python web-scraping scripts to create *.csv and *.html files showing informationon individual stocks. My site has a tacked-on feel to it, and I definitely want to change the setup.

At a future time, I will rebuild my Doppler Value Investing web site in either Ruby on Rails or Django. The Ruby on Rails route will require rewriting my Python script in Ruby. The Django route will require learning Django.(I'm not sure which one will be easier.)

My questions:
1. Why is Ruby on Rails much more popular than Django?
2. Why is there a much stronger demand for Ruby on Rails developers than Django/Python developers?
3. If Doppler Value Investing were your project instead of mine, would yourecommend the Ruby on Rails route or the Django route?

 

[marduk]

My questions:
1. Why is Ruby on Rails much more popular than Django?

AFAIK Rails got a slightly longer head start than Django. And it has
been said that RoR's first killer app was a screencast. A little
marketing can go a long way. Since then Django has caught up a bit with
RoR in terms of maturity and adoption (I think this is in part because
of RoR's adoption slowing due to it not being the NKOTB anymore (not to
mention a few security embarrassments))
..

2. Why is there a much stronger demand for Ruby on Rails developers than
Django/Python developers?

I'm not sure how big the difference is, but it's probably related to its
early(er) adoption. Same reason that there is a stronger demand for PHP
coders. PHP hit it big first, so there is a lot more PHP code to
maintain.

3. If Doppler Value Investing were your project instead of mine, would
you recommend the Ruby on Rails route or the Django route?

If you already know/work with Python than I would go the Django route.
RoR and Django are not that much different nowadays as far as
methodologies. The main differences I think between RoR and Django are
that one is Ruby-based and one is Python-based. Other than that, if you
can get used to one you can get used to the other.

 

[Tim Johnson]

If you already know/work with Python than I would go the Django route.
RoR and Django are not that much different nowadays as far as
methodologies. The main differences I think between RoR and Django are
that one is Ruby-based and one is Python-based. Other than that, if you
can get used to one you can get used to the other.

I had problems getting django to work on my hostmonster account
which is shared hosting and supports fast_cgi but not wsgi. I put
that effort on hold for now, as it was just R&D for me, but
I would welcome you to take a look at this link where I opened a
ticket.
https://code.djangoproject.com/ticket/19970
From what I inferred there and from the django ML, the django
"community" is indifferent to fastcgi and the shared hosting
environment. As someone is new to shared hosting environments (I
would mostly on dedicated servers) I get the impression that
django is cutting itself out of some (if not a lot) of the market.
I don't know about RoR tho....

 

[Steven D'Aprano]

My questions:
1. Why is Ruby on Rails much more popular than Django? 2. Why is there
a much stronger demand for Ruby on Rails developers than Django/Python
developers?

Fashion.

Demand for technology is usually driven more by copying what everyone
else does than by merit.

Consider: Fred is a busy manager who has to start a new website and is
dissatisfied with the technology he's previously been using. Does he have
time to learn Ruby on Rails, Django, CherryPy, Drupal, and thirty other
web technologies, to systematically and objectively decide on the best
language for the website? Of course not. Even evaluating *two*
technologies is probably beyond his time or budget constraints. So he
does a search on the Internet, or reads trade magazines, or asks his
peers, to find out what everyone else is doing, then copies them.

"Oh, they're using Ruby on Rails, it must be good." So now he decides to
use Ruby on Rails, advertises for RoR developers, and the cycle continues.

But is RoR actually better for his specific situation? Doubtful.
Presumably RoR is better for *some* specific jobs. At some point, early
in RoR's history, it must have been a *good* solution. But unlikely to be
the *best* solution, just better than whatever people were using before.

And so RoR will be the easy choice, not the best choice, until such time
as RoR is no longer satisfying developers. And then there will be a
sudden, and random, phase-change to some other tool, which will become
the next easy choice.

3. If Doppler Value Investing were your project instead of
mine, would you recommend the Ruby on Rails route or the Django route?

Neither. I'd be rather tempted to try doing it in CherryPy. But then,
what do I know, I'm just as much a follow of fashion as the next guy.

 

[alex23]

Neither. I'd be rather tempted to try doing it in CherryPy. But then,
what do I know, I'm just as much a follow of fashion as the next guy.

All of the cool kids are using Pyramid these days.

 

[Albert Hopkins]

I had problems getting django to work on my hostmonster account
which is shared hosting and supports fast_cgi but not wsgi. I put
that effort on hold for now, as it was just R&D for me, but
I would welcome you to take a look at this link where I opened a
ticket.
https://code.djangoproject.com/ticket/19970
From what I inferred there and from the django ML, the django
"community" is indifferent to fastcgi and the shared hosting
environment. As someone is new to shared hosting environments (I
would mostly on dedicated servers) I get the impression that
django is cutting itself out of some (if not a lot) of the market.
I don't know about RoR tho....

I haven't any experience with shared hosting, so can't help you there.
I did do some work with lighttpd and fast_cgi and the Django docs worked
fine for that. But you're right. wsgi is pretty much the standard for
web services in Python, like DB API is to relational database access.
Ruby has Rack. Python has WSGI.

 

[Tim Johnson]

I haven't any experience with shared hosting, so can't help you there.
I did do some work with lighttpd and fast_cgi and the Django docs worked
fine for that. But you're right. wsgi is pretty much the standard for
web services in Python, like DB API is to relational database access.
Ruby has Rack. Python has WSGI.

I believe that indifference on the part of Python to fastcgi is a
self-inflicted wound. I don't believe that there is any good
excuse for such indifference, except for a sort of bureaucratic
inertia. It's sad, when you consider how well python is designed
and how crappily PHP is designed and how easy it is to set up and
deploy drupal in the same environment. I speak from my own
experience.

respectfully :

 

[rusi]

I'm currently in the process of learning Ruby on Rails.  I'm going through the Rails for Zombies tutorial, and I'm seeing the power of Rails.

I still need to get a Ruby on Rails site up and running for the world to see.  (My first serious RoR site will profile mutual funds from a value investor's point of view.)

I have an existing web site and project called Doppler Value Investing (dopplervalueinvesting.com) that uses Drupal to display the web pages and Python web-scraping scripts to create *.csv and *.html files showing information on individual stocks.  My site has a tacked-on feel to it, and I definitely want to change the setup.

At a future time, I will rebuild my Doppler Value Investing web site in either Ruby on Rails or Django.  The Ruby on Rails route will require rewriting my Python script in Ruby.  The Django route will require learning Django.  (I'm not sure which one will be easier.)

My questions:
1.  Why is Ruby on Rails much more popular than Django?

"Where there is choice there is no freedom"
http://www.jiddu-krishnamurti.net/en/1954/1954-03-03-jiddu-krishnamurti-8th-public-talk

Python-for-web offered so much choice -- zope, django, turbogears,
cherrypy, web.py etc etc -- that the newbie was completely drowned.
With Ruby there is only one choice to make -- choose Ruby and rails
follows.

Anyone who's used emacs will know this as the bane of FLOSS software
-- 100 ways of doing something and none perfect -- IOW too much
spurious choice.

GvR understood and rigorously implemented a dictum that Nicklaus Wirth
formulated decades ago -- "The most important thing about language
design is what to leave out." Therefore Python is a beautiful
language. Unfortunately the same leadership did not carry over to web
frameworks and so we have a mess.

I guess the situation is being corrected with google putting its
artillery behind django.

 

[rusi]

I'm currently in the process of learning Ruby on Rails.  I'm going through the Rails for Zombies tutorial, and I'm seeing the power of Rails.

I still need to get a Ruby on Rails site up and running for the world to see.  (My first serious RoR site will profile mutual funds from a value investor's point of view.)

I have an existing web site and project called Doppler Value Investing (dopplervalueinvesting.com) that uses Drupal to display the web pages and Python web-scraping scripts to create *.csv and *.html files showing information on individual stocks.  My site has a tacked-on feel to it, and I definitely want to change the setup.

At a future time, I will rebuild my Doppler Value Investing web site in either Ruby on Rails or Django.  The Ruby on Rails route will require rewriting my Python script in Ruby.  The Django route will require learning Django.  (I'm not sure which one will be easier.)

It is a natural programmer instinct that a uni-language solution is
felt cleaner than a multi-language one. This feeling is valid under
the following assumptions:
- You are starting from ground up
- The investment in learning something new is not considered
significant

In your case, with a site already up (maybe with a tacked on feel) and
learning django a significant effort compared to directly coding in
RoR, you should look at polyglot solutions more carefully (eg not
directly relevant ... something like
http://www.igvita.com/2009/03/20/ruby-polyglot-talking-with-erlang/ )

IOW code your site in RoR and call out to your python scraper-scripts
may be an option to consider.

 

[Rick Johnson]

"Where there is choice there is no freedom"
[snip link]

Python-for-web offered so much choice -- zope, django, turbogears,
cherrypy, web.py etc etc -- that the newbie was completely drowned.
With Ruby there is only one choice to make -- choose Ruby and rails
follows.

Indeed!

"Costco", a wholesale grocery chain, realized the same issue of consumers being drowned by multiplicity, and have been very successful by intelligently narrowing those choices for it's customer base.

 

[Rui Maciel]

Anyone who's used emacs will know this as the bane of FLOSS software
-- 100 ways of doing something and none perfect -- IOW too much
spurious choice.

This is a fallacy. Just because someone claims that "there are 100 ways of
doing something and none perfect", it doesn't mean that restricting choice
leads to perfection. It doesn't. It only leads to getting stuck with a
poor solution with no possibility of improving your life by switching to a
better alternative.

Worse, a complete lack of alternatives leads to a complete lack of
competition, and therefore the absense of incentives to work on
improvements. You know, progress.

Choice is good. Don't pretend it isn't. It's one of the reasons we have
stuff like Python or Ruby nowadays, for example.


Rui Maciel

 

[Sven]

This is a fallacy. Just because someone claims that "there are 100 ways of
doing something and none perfect", it doesn't mean that restricting choice
leads to perfection. It doesn't. It only leads to getting stuck with a
poor solution with no possibility of improving your life by switching to a
better alternative.

This thread reminds me of an article I read recently:

http://rubiken.com/blog/2013/02/11/web-dev-a-crazy-world.html

It's mostly a matter of having enough time to evaluate what's best for you.
In the case of RoR vs Django, you will (assuming zero knowledge) need to
learn a language, then a framework. That's quite a time consuming task.
Personally I've opted for Django because I've used Python for years. I've
written some Ruby in the past, but I not enough to make me choose RoR over
Django to get stuff done.

 

[Rick Johnson]

This is a fallacy. Just because someone claims that "there are 100 ways of
doing something and none perfect", it doesn't mean that restricting choice
leads to perfection. It doesn't. It only leads to getting stuck with a
poor solution with no possibility of improving your life by switching to a
better alternative.

Not true. The "one solution" is only poor when the dev team of that "one solution" become resistant to change. But i don't think anybody would agree that a *single* solution could exist for ALL problems (at least not in the early stages of defining a "problem domain'), although a *single* solution could exist for MOST problems.

Worse, a complete lack of alternatives leads to a complete lack of
competition, and therefore the absense of incentives to work on
improvements. You know, progress.

Wrong again. You don't need 10 versions of the same software to maintain evolution. Your premise is that competition between multiple versions of, what is basically the same exact software with TINY difference, creates evolution; WRONG!; competition cannot exist without IDEAS, and it is the presenceof conflicting IDEAS that create evolution in software development, NOT fragmentation.

Fragmenting the pool of great software developers into "zeoltry sects" is slowing evolution. What you do need is a bare minimum of projects that are perpetually open to outside ideas and constant evolution. You goal should beto work towards a single monolithic solution. But you must also keep in mind that the single solution must continue to evolve.

Choice is good. Don't pretend it isn't. It's one of the reasons we have
stuff like Python or Ruby nowadays, for example.

Python and Ruby should both be superseded by a language that takes the bestfrom both languages. Python and Ruby are so much alike in so many ways it's really silly. I think the main split point at this time is the "PythonZenvs TIMTOWDI".

Sure there are some glaring differences in Ruby vs Python methodology, but at the end of the day, An iterator is an iterator, a class is a class, a sequence is a sequence, a mapping is a mapping, a conditional is a conditional, a variable is a variable. Python has list comprehensions and Ruby has Array.[select|collect].

But let's investigate a much better example where multiplicity has fragmented a problem domain into OBLIVION, and that domain is Graphical User Interfaces!

Python has tons of them available. How many different versions of a GUI window do we REALLY need. People, a StaticText is a StaticText, a Dialog is a Dialog, a ProgressBar is a ProgressBar, an EditText is an EditText, a Canvas is a Canvas, a NoteBook is a NoteBook, a ListControl is a ListControl; BLAH!

If we are going to split into "sects", then we should at least abstract away the parts that we agree on, and then collectively EXTEND our selfish versions from that single abstraction.

Do you people realize how far we could have evolved a single GUI library bynow if we were not wasting our time re-inventing the same old widgets again and again just because we cannot agree on minutiae! You would rather fragment the community and slow evolution than to make compromises and produce something greater than the combination of ALL the multiple projects out there? Fragmentation is foolish. We need to focus or energies wisely and work towards a common goal. This is the path of intelligent evolution, not a billion years of naive "dice rolling".

 

[Chris Angelico]

If we are going to split into "sects", then we should at least abstract away the parts that we agree on, and then collectively EXTEND our selfish versions from that single abstraction.

We've already done that. We've agreed that a program is stored in zero
or more files. Everything after that is an extension from that basic
abstraction.

ChrisA

 

[rusi]

This thread reminds me of an article I read recently:

http://rubiken.com/blog/2013/02/11/web-dev-a-crazy-world.html

Ha Ha! Thanks for that.
Of course its exaggerated. But then hyperbole can tell a story that
logic cannot.

 

[rusi]

I strongly agree. The fact that there is no de-facto standard web system
for Python is a major problem. Consider:
- With too many choice one has no idea which projects will be maintained
and which will be abandoned.
- Expert knowledge among users is spread more thinly.
- The effort of contributors is diluted.

Years ago when I had some simple web programming to do I looked at the
choices, gave up and used PHP (which I hated, but got the job done). If
RoR had been available I would have been much happier using that.

In my opinion the plethora of Python web frameworks is a serious
detriment to trust and wider acceptance of Python for this use. If
Django is becoming this standard, that is excellent news.

Some choice is good, but in my opinion too much choice and lack of a
de-facto standard are very detrimental.

-- Russell

Hmm… I am not sure I agree with your agreement
Its not so much "some choice" vs "too much choice" as "real choice" vs
"spurious choice".
Python or C or Haskell is a real choice.
Python or Ruby is a spurious choice.

 

[rh]

I believe that indifference on the part of Python to fastcgi is a
self-inflicted wound. I don't believe that there is any good
excuse for such indifference, except for a sort of bureaucratic
inertia. It's sad, when you consider how well python is designed

Python is not indifferent to fastcgi, django is indifferent to fastcgi.

 

[rh]

"Where there is choice there is no freedom"
http://www.jiddu-krishnamurti.net/en/1954/1954-03-03-jiddu-krishnamurti-8th-public-talk

And where there is no competition there is no choice. So?

Python-for-web offered so much choice -- zope, django, turbogears,
cherrypy, web.py etc etc -- that the newbie was completely drowned.
With Ruby there is only one choice to make -- choose Ruby and rails
follows.

Anyone who's used emacs will know this as the bane of FLOSS software
-- 100 ways of doing something and none perfect -- IOW too much
spurious choice.

Choices are good.

GvR understood and rigorously implemented a dictum that Nicklaus Wirth
formulated decades ago -- "The most important thing about language
design is what to leave out." Therefore Python is a beautiful
language. Unfortunately the same leadership did not carry over to web
frameworks and so we have a mess.

Having one choice is a mess. And look back at history and current events
if you don't see that.

I guess the situation is being corrected with google putting its
artillery behind django.

What does that mean? For many it means don't use django.

 

[Rick Johnson]

Choices are good. [...] Having one choice is a mess. And
look back at history and current events

Sometimes "choices" are forced upon you without your consent or even without regard for the end users' well-being. In this case "choices" are no longer "choices", they become unnecessary dead weight on the backs of users, they become malevolent multiplicities.

============================================================
Take cell phones for example.
============================================================

Nobody would argue that having many different cell phones available in the marketplace, each with different capabilities, is a good thing; however, one of the downsides is that the manufactures refuse to comply with universalstandards for things like "charger receptacles" and so you end up needing to buy a new charger for every new phone.

I have a box in one of my closets with probably 20 of them, and they're alldifferent! Some have the same receptacle, but different output. Many are even from the same damn manufacturers and not transferable between differentmodels of the same manufacture!!!

*Wise observer blubbered:* "Rick, what you describe is more a result of corporate greed than a good analogy for the ills of web programming, this is open source software, nobody is being paid. The developers are not intendingto extort the lemmings under the guise of a self-induced hardware incompatibility ."

Yes you are correct, the motivation to fragment is not due to greedy wishesto become rich, no, the motivation is one of these two:

* Selfishness: (They want to create something is "new", but
really just the same old $hit with a different name)

* Static stubbornness of current module developers does
not allow for change, so they are forced to start a
new project.

Either excuse causes damaging fragmentation of the community and the problem. It injects multiplicity and asininity. The so called "choices" (which are really the same thing with a a shiny new name tag) then become an obstacle for new users. The whole system slows to crawl, stagnates, and inevitablybecomes extinct.

This is the future of Python web programming (and the language itself) if we keep refusing to change from within. Fragmentation WILL destroy us.

 

[Tim Johnson]

Python is not indifferent to fastcgi, django is indifferent to fastcgi.

I stand corrected, that was a typo.
thanks