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.
"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.
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."
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.
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.
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.
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.
"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.
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! ;)
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.
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?
"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.
> Rails stuff is almost, but not quite, entirely unlike Ruby.
I really like Python and have the exact opposite opinion as you. That is, to me, Rails is very like Ruby and Django is unlike anything else done in Python. Django has hindered me every time I've tried to use it. By comparison, Cherrypy, storm-orm, SQLAlchemey, Mako, etc are all pretty straight forward. Django is out in left field for me.
I've never done anything more than "Hello World" with Rails, but interestingly, I am increasingly getting exactly this feeling with the framework I am using - Grails (groovy based). There are so many syntactic games played to make things look minimalist and cool that it is barely possible to understand anything it does from first principles. The problem with that is that throughout my career I have continually found that to be successful I have to understand things several layers below where I am operating at. There are always unexpected behaviors, bugs, features you don't understand properly that bite you in the process of development. Time and time again it's been the fact that I can dig right into what's going on several layers below that has saved me. I don't really believe that any of these frameworks is so wonderful that this won't be the case in the future, so it makes me very uneasy about this kind of thing.
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.
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.
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.
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.
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.
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.
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.
> Whether I'm driving a Ferrari or an Aston Martin, I still have no idea what goes on under the hood
Maybe if you're just a casual driver that's fine. What if you happen to be a race driver? What if you need to drive in snow, on ice, on sand, at high altitude? It's suddenly a good idea if you have some idea how the car actually works. What if your boss says to you, "We need you to drive 15% faster with 10% less gas", and you open the hood and there's just a big box there labelled "magic" that can't be opened?
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.
I get the impression Pylons tries to be the "anti-Django" inverting the NIH attitude of Django and trying to be all things to all developers. The end result however is a huge number of dependencies and options that make installation and setup harder than it should be. Turbogears 2, which is based on Pylons, has an even greater number of dependencies - such that I needed to install virtualenv to get going with it.
For example, in order to support a large number of template engines, Pylons uses Buffet, another library which provides a common interface for these engines. Typically, however, you will only use a single template engine in your project and it only needs a few lines of code to set an engine up.
Although I do most of my web development in Django, when I do need more control or something a bit simpler I go with a Werkzeug + SQLAlchemy + Jinja stack (plus WTForms, similar to Django forms but in a standalone package). The code needed to get up and running isn't that much more than Pylons (and paster generates a whole lot of code anyway) and I can count the dependencies on one hand. That makes deployment a lot faster and easier, and it's just as easy to swap out these dependencies as with Pylons.
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.
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.
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.
