More Thoughts on Rails
Here's some more thoughts on Rails.
Carlos Ribeiro: Reinventing the wheel:
A few people don't like to rely on code written by someone else, independent of anything else. But many programmers are quite reasonable in this respect, but even so end up rewriting stuff. I believe that the main problem is a mismatch in the mental model, worsened by the lack of documentation.
In Python land, there are several competing Web frameworks. It's interesting to see how many of them are badly documented, or not documented at all. But even projects that have a good volume of documentation still fail to address the mental model problem. A manual that touches only on practical issues -- mainly, API specs -- is close to useless in this regard.
I would like to see more effort spent on documenting the architectural issues of a framework. Not only 'how do I call this method', but 'how do I structure my app'. That's the really difficult question, and the lack of a satisfactory answer to it is often a good reason to write yet another framework.
I believe Carlos has identified a big problem with trying new things. When there are several competing alternatives (and the ever-present possibility of "roll your own"), there is a great cost involved in figuring out what to use and how to use it. That's what I was trying to get at last night when I wrote:
I still haven't found "the one" Python web framework. Do I use mod_python or FastCGI? Which Object-Relational mapper is the best? What templating language should I use? Which view framework will give me beautiful, search engine friendly, professional-looking URLs? Finally, of these miriad frameworks, which of them can I count on an active and outward-facing developer community for good documentation and support?
With Java, if you want to use Servlets for web development, you don't have a choice about how to structure your app. It goes in a WAR file that is laid out in a certain way: the libraries go here, the class files go there, your JSPs go here, and there's a web.xml file there that defines how it all works together. It can be a bitch to get this all set up, but at least I know how to do it.
Ian Bicking expands on Carlos's post in "Tell me what to do, please":
I agree with Carlos that 'how do I structure my app' is the biggest missing piece of most (Python) web frameworks' documentation. The lack is just as true for big ones like Zope as it is for all the small players....
Since the Python community (or at least the bloggers) are going through a little what's-Rails-got-that-we-don't phase, this is another point we can put on that. Rails has strong conventions about application layout, and it isn't afraid to tell you about it. There's no shy well, this is how I do it, but whatever works for you stuff -- people usually come in happily willing to accept the most draconian and inflexible of standards, because at least it gives them a starting point and an opportunity to avoid gratuitous differences in code.
Ryan Tomakyo also hits on this in No Rails for Python?:
Actually, there's a lot of Python on ??? type questions with the same answer every time: "Python has many web frameworks that provide Ruby on Rails like functionality."
Perhaps this is the real problem Rails solves. When you want to build a web application in Python, there's quite a bit of web framework research and evaluation required before you can start thinking about your real problem. Once you feel comfortable with a web framework, the ramp up time for new projects decreases a bit but the first step is a big one. This seems to be keeping people away from Python for web related work. The feeling I'm getting around Rails is that it let's you skip the tool selection phase and dive right into problem domain.
I haven't tried Rails yet, but so far, I've seen two downsides:
- Learning Ruby
- The lead author's Rails fanaticism.
David Heinemeier Hanson actively discourages people from attempting to replicate Rails's integration in other languages, and essentially says that anyone who uses Java for web development is engaged in "fear-driven" programming. I dislike his (and the larger Rails community's) need to bash Java at every turn.