Rails vs Pylons - initial thoughts

I know, I know! Comparing two frameworks is bound to be riddled with generalizations that don't help anyone and obvious features that are only "ah ha" moments to the writer of the post. However, I'm going to give you an account of my initial thoughts of Pylons, as compared to ruby on rails, a framework that I've been using for a year and a half.

Comparing Pylons to Ruby on Rails

Initial thoughts are how very similar these two frameworks are. Pylons basically admits that it takes well founded queues from rails. But who wouldn't?

If you were to design a framework today, and you think it through, any MVC framework will smell like rails, which has hundreds of contributors, all tweeking the code base. When a populist approach takes hold, you end up with some "trueisms"

All Pylons has done, from my inspection so for, is taken those trueisms as a starting point for their framework, and now are building off that on their own direction.

Common Features between Pylons and Rails

Here is what I noticed, 24 hours into trying Pylons, as it compares to Rails:

• File structure is similar - Rails and Pylons both create a whole bunch of files to the project folder. Pylons however has more files outside of the project's directory that are used to setup information about the egg file. Think of an egg as a ruby gem, i guess.
  
  Again, notice that inside the QuickWiki root folder, you have a QuickWiki folder where all your code goes into. This to me, looks like what we'd see in rails. Also, notice the models, Views(Templates) and Controller is mingling with the public folders, etc...


• Routes - these seem similar, down to the map.connect. however, i've yet to find out if they implement Restful routing. They do seperate their controller commands by controller and RestfulController, so time will tell. Again, it's just been 24 hours. On first impression, Pylons routing actually can do a lot more, then what i've seen in rails. If this feature exists in rails, i've not seen or read about it in a year and a half. In Pylons, the first routes are the ones handled last, where as in rails, the bottom of the routes file gets executed last. Here is the example from their tutorial:
  
  Notice again, that last line before the return. If you entered a url "/whatever" and it doesn't exist, the last route will create the page for you, based on it being the title. That title variable is passed to the show page and saved in the DB. Perfect for wiki applications. I don't think I've seen that in rails, to date.


• Environments - Both Pylons and Rails have development, test and production environments. In pylons it appears that the environment files are housed in the outer file system, see image above to get what i'm saying. the inner file system appears to be where you'd put most of your code for the MVC part of things. Now in part two of this post, i'm sure to have written about production deployment and the differences there. if not, screw you Lulz.


• Error Pages/ Debugging - Both have a cool stack error printout on your browser, when you fuck up. However, Pylons is interactive and you click on these arrows to get to the right code from within your browser. You can also send Pylons an email right from the error page, if you wanted.

Differences between Rails and Pylons - initial thoughts

I know i added some variances above too, but here is a list of things that is really different between the two frameworks:

• You are making an Egg file, not a web app. - Ok, this is my spin on the whole thing, but technically you are making a python egg that will just happen to be served through the web. In rails, we are creating a web application in ruby. Not a ruby gem, not a ruby script, a full on independent web application whose sole purpose is to be viewed through an internet browser.
  While i may be putting it too simply, it was something to get used to that when you are coding you are technically creating a python egg file that you can either, give to your friends to play around on their computer, or serve it through the web, or what have you. Maybe this has to do with the fact that you are creating a WSGI application. Read Pylons concepts here for more details.


• Pylons needs to be running in a Python virtual environment, in order to work. What that means is you can't just call Pylons create -t MyProject willy nilly. No big deal, just something to get used to.


• Pylons uses something similar to ActiveRecord, but in the python world it's called SQLAlchemy. From the pylons site: SQLAlchemy is a powerful Python SQL toolkit and Object Relational Mapper (ORM) that is widely used by the Python community.


• No Migration files - All migrations are setup in the __init__.py file of the models directory. Personally, rails has it right, with it's easy to understand migration creation, in my opinion. However, Pylons isn't hard, it's just, well, more.


• Templating Engines - Instead of ERB, they use Mako, by default. It's not that strange when learning mako, as some of the nomenclature is similar.

Conclusion

Both have their pros and cons. I don't mind Pylons, and I'm going to try and create a project in Pylons, something other then the wiki from their tutorial. I'll be bloging my way through that project, and giving you the usual uncandidness you've been accustomed to. If you want to expand your web framework knowledge past rails, Pylons is a good choice to start with, without the huge learning curve.