
Magic sucks, Django Rocks     - vthakr
http://christopherroach.com/archives/44
======
carbon8
How did this completely content-free post get so many votes so quickly?
Really, the world could do with a few thousand fewer blog posts and comments
about how someone decided to learn web development and chose a python
framework (usually django) over "Rails" (apparently unaware of the other
awesome ruby web frameworks, or even frameworks in other languages) for
reasons they can't articulate.

~~~
dougp
Because this gives people that have dismissed rails outright a reason to feel
good about themselves.

------
blogimus
"I can’t seem to get anything done in Rails because before I can work with it
I have to understand it."

That's about how I feel now. I'm a relative newbie to Ruby and really like the
language, even while aware of its warts and headaches as recent posts here
illustrate.

I'm trying out Rails so that I understand it better from my own experience,
rather than relying on other opinions. It is really quick to get from point 0
to point 1, but then after that, I find I have to dig in to the various parts
because my intuition does not lead me to how Rails works, so I have to first
understand the "Rails way" of a particular aspect, and then start digging into
the source code to see how it works.

But one thing I'm really happy about with my experience learning Rails is
getting a much better understanding of Representational State Transfer (REST).
I ran into some roadblocks in figuring out routes, which led me to realize I
didn't understand REST well enough, so I've been reading Roy Fielding's
dissertation (focusing on the REST parts, but more I read, the more I'm
inclined to consider it essential reading for web developers, or at least for
me).

So I still want to get proficient at Rails and use it for my current web
project, but I'm now more interested in trying out Django too, even if just
for perspective.

~~~
dasil003
My 4th year anniversary of using Rails is coming up. I have to say I remember
those days of hitting the wall with Rails, where the learning curve goes
vertical as you dig deep into the source to debug some extremely esoteric name
collision or some other bug _that should have had a warning_.

In retrospect, it was a wall worth scaling. I have no fear of Rails meta-
programming bugs, and I've developed strategies for dealing with the thorny
issues that pop up every few months. All in all the FUD from the Java
advocates has proven to be unfounded (the FUD from Haskell camp, not so much).
The effort saved by eliminating reams of boilerplate and heavy IDEs is well
worth a few less-obvious exceptions.

As Rails has matured I think the core team has exercised restraint, and the
magic situation, while an integral part of the "Rails Way" is at least not
getting too much worse. Plus work on Rails 3.0 is bringing real improvement to
plugin-compatibility and modularity issues. That said, I'm glad I got in on
Rails early and I'm looking forward to the next big thing already. When Rails
came out it refreshingly plucked the best of 10 years of web development. Over
time, as with all technologies it is getting bloated and ultimately will gain
complexity as the developer base gains experience and needs to solve a greater
and greater set of problems. Eventually someone will come along and distill
all that experience into a much-simpler new framework (maybe ajax-based? maybe
continuations-based ala Seaside?) that dumps the cruft of the current "best
practices."

~~~
blogimus
Thanks for the comments. One of the things that I find a pain about Rails but
also an opportunity is that the framework is such a fast moving target that
documentation grows stale quickly, presenting an opportunity to write newer
fresher instructional material.

------
brendano
The Obie Fernandez book, "The Rails Way", helps make the magic make more
sense. Unlike most Rails books, which are intro-level and full of the sort of
marketing crap that makes Rails infamous, this one actually explains their
design decisions in a sensible manner.

Unfortunately it seems the author has a crazy annoying blog like other Rails
people. Oh well, at least he wrote a good book.

------
mariorz
really not a fan of these 'rails is like a ferrari, django is like an aston
martin' type of similes, they mean nothing to me. the article itself is pretty
light on content; not much here except a baitish title.

~~~
pie
I agree with you that this post does not come to much of a point. However, in
my own experience, I had the same sense that Django was more straightforward,
simple, and transparent than Rails - just look at the file structure of an
empty project, or the baseline implementation of models.

I now work with both professionally, and Django still feels a little more
straightforward. The other side of this is that I occasionally find myself
wishing for some aspect of Rails "magic" in Django projects.

I also think that the way Rails is implemented (and to a lesser degree, the
Ruby language) takes a little more experience and learning to understand in a
meaningful way.

~~~
jshen
"I also think that the way Rails is implemented (and to a lesser degree, the
Ruby language) takes a little more experience and learning to understand in a
meaningful way."

I think this has a lot to do with the person. Ruby and Python are almost
identical technically (relative to other popular languages). I personally
found ruby a lot more intuitive, and I used python for a year or two before I
tried ruby. I'm sure this is a statement about me, not ruby or python.

------
nir
A lot of what people call "magic" in Rails are just conventions (as in
"convention over configuration"). Rails expects to find certain things in
certain places named in a certain way and works with them automatically, which
might seem like magic if you're new to it.

Seems to me the article can be summed up as "So, I tried Rails for a while but
found I prefer Django's approach". Cool, and totally legitimate, but 39 votes?
I mean, he doesn't even mention Twitter in the title! ;)

~~~
scorpion032
> he doesn't even mention Twitter in the title

Nor Apple!

------
cubicle67
All these Ruby vs Python type posts are pointless, in my opinion, because they
all overlook the same thing:

Whilst the languages are similar and fit almost the same problem domain, the
philosophies behind them are almost opposite. People end up using the one that
fits the way they think, because the language feels more intuitive/natural to
you when it works the way your brain does.

If you like order, knowing exactly what's going on and knowing you're doing
things the right way, you'll find yourself using Python. I think this is why
it's gained such traction in the scientific community.

If you're happy with chaos, like to bend the rules and probably like to draw,
you'll fall for Ruby.

It's not a zero sum game people. You can praise the things you like without
having to deride the alternatives.

~~~
jshen
nice way to push your agenda in sheep's clothing.

python = order and rightness

ruby = chaos

"It's not a zero sum game people. You can praise the things you like without
having to deride the alternatives."

you seem to be contradicting your own argument.

~~~
cubicle67
for the record, I'm a Ruby guy

~~~
jshen
Who views the word chaos in a positive light unlike the vast majority of
people?

What you are doesn't change the tone of the metaphor you used.

------
jshen
The idea that one must completely understand the implementation details of
something they use before they use it seems silly to me. To be more specific,
it seems to destroy the primary benefit of abstractions.

I wonder if this person knows the implementation details of the language he
uses? Or the RDBMS he uses? What about the OS he uses? Text editor?

~~~
scorpion032
Or all the way from Assembly level languages to Ruby and Rails.

Heck even the transistors and Micro electronics concepts,

oh then Quantum Physics and Solid State Devices...

To understand anything completely, you need to understand, everything
completely.

------
sachmanb
my strategy would have to been to highlight the rows in excel and then do
"insert bar chart"

~~~
83457
too magical

~~~
whatusername
You could program something in VBA to do it for you.. I don't think I've heard
anyone on HN refer to VBA as "magical".

(It does definately have a deficiency of ponies)

~~~
scorpion032
There is no need to use VBE for Barcharts when values are in Excel rows.

Just type f12, after highlighting the content; or insert chart from contextual
menu (right click)

------
rbanffy
"it never takes long before I reach a point where I feel like I’m no longer
programming in Ruby."

This echoes perfectly my feelings about Rails. I have tried, several times, to
do something with it, but I always hit some magical wall or mythical creature
that demands something from me I really don't know what it is.

If I have to define the main difference between Rails and Django is that Rails
is a DSL for building websites on RDBMSs. Django is a web framework for
building web sites with RDBMSs. Django stuff is Python. Rails stuff is almost,
but not quite, entirely unlike Ruby.

~~~
mhartl
_Rails is a DSL for building websites on RDBMSs. Django is a web framework for
building web sites with RDBMSs._

Interesting. I would consider this an argument in favor of Rails.

~~~
jermy
It's only being suggested that Rails ties your website structure to your
internal database model more than Django does, and that might be less ideal
for your users.

~~~
rbranson
Only by convention and common practice though. You can easily mix and match
any part of the MVC as you see fit. This is where the "magic" comes in. Rails
gives you a set of very sane, most-common-scenario conventions that are the
basis for it's huge upfront productivity. Obviously once you step out of this
convention zone you're going to hit a wall, because you'll actually have to
write code. It just feels like a wall because everything that led up to it was
so damn quick.

------
jpcx01
Merb solves this problem nicely. You can easily trace every request from
Request to HTML easily, and understand the entire framework at any point by
popping open the component. Extremely clean, and obvious code.

Rails is a bad example of a Ruby project. It'll get much much better once Merb
core is merged in and replaces the existing Rails 2 internals.

------
mbleigh
Whether I'm driving a Ferrari or an Aston Martin, I still have no idea what
goes on under the hood. If you have to understand every aspect of every
library you use to code you will never get anything done. Instead, learn
enough to attack your core competencies and trust that the rest of it works as
expected, since someone else has chosen that as their core competency.

Libraries and frameworks are all about not knowing how they work behind the
scenes. That's kind of the point.

~~~
callahad
But with Django, I can fake it.

I can look at most of the code in a Django project and imagine a basic
implementation sitting behind it. And I can work off of those generalizations.
I can't do that for Rails.

That's the point about DSLs and Magic -- you have no idea what _could_ be
going on behind the scenes, and it's harder to make a guess about why it might
be going wrong.

~~~
jeremymcanally
At the risk of sounding harsh, it sounds like maybe you and the OP are just
not interested in bucking down and learning more about the language. I tried
to learn "Rails" by itself, but decided that learning Ruby (and I mean _all_
of it, not just learning how to write an if statement) is the only way to
really be able to use Rails. I can now (a) understand what's going on and (b)
!!bonus!! I can write better code in Rails because I can bend Ruby to my will.

And it's not really bias; I come from a generalist perspective. I worked in
Python for about two years, and it's the same way as Ruby. _Any_ library or
language is going to require a lot of learning to really master. I floundered
in Python until I broke down and basically read through the API reference
front to back. And with regards to what's going on behind the scenes, I found
Django no different than Rails. Perhaps a little more obfuscated with the way
templates and the auto-admin work, but I didn't have as much interest in
investigating it at the time.

But, whatever. YMMV, obviously. :)

~~~
jamongkad
I feel the exact same with the aforementioned frameworks. I too am learning
Python and decided to learn it whilst hacking away with web.py. When I found
myself building yet another MVC framework with web.py as its core. I moved on
to Pylons as it presents a nice middle ground between web.py and Django. Its a
framework with a bit more bent on web.py's spartanism. So far its been a nice
journey and loving the language more and more.

------
sandGorgon
I like pylons and I cant understand why everyone is trying to scare off
everyone else by calling it “glue”, “a hackers framework”, “it doesnt give you
anything, allows you to choose everything”

People would almost think it is the Lisp of frameworks (which it is).

Pylons comes with “batteries included”. Its default setup with Mako,
SqlAlchemy, Routes is quite good and I would say a Ruby-on-Rails for
Pythoners.

And like RoR, you can fire up “paster shell” to get a nice console. But my
best part - how you can set “import pdb;pdb.set_trace()” to start a debug
session in a console.

I can wrap my fingers around pylons very nicely - and I like the fact that I
can “hack” it if I ever wanted to.

~~~
pie
I love the _idea_ of Pylons, if for nothing other than its inclusion of
SqlAlchemy, which I respect hugely.

However, after working on a medium-sized Pylons project for a few months, I
found that there was quite a bit of "glue" that I had to implement myself, the
type of thing that's typically handled under the hood by other frameworks like
Django.

Perhaps it was my own ignorance or drive for simplicity/elegance, but I wound
up getting nervous about the lack of these standards, and I got pretty
frustrated about constantly rolling my own architectural solutions with little
more guidance than comments in bug reports and scattered blog posts.

That's not to bash on Pylons - I think it's incredibly powerful, and in
comparison Django (or Rails) feels a little like moving from power tools to a
Fisher Price toy. Regardless I think it's the established standards that make
these more mainstream frameworks better choices (in a business sense) for
banging out working products.

~~~
sandGorgon
it would be interesting to know what problems you faced. If you could
elaborate on the roadblocks you hit - and how other frameworks solved it for
you, that would be great.

~~~
pie
Looking back, I think I struggled with Pylons' lack of convention (or perhaps
flexibility) more than anything else. There seemed to be a lack of consensus
(or as I saw it, no established "best" solution) for handling common
middleware tasks such as user authentication. It seemed like I was spending
more time on application architecture than fleshing out a working system.

This was over a year ago, and I'm sure some things have improved, but looking
back into that Pylons Cookbook still gives me the willies.

