John Wang
Posts: 1
Nickname: mazr
Registered: Feb, 2006
|
|
Re: Web Framework Redux
|
Posted: Feb 21, 2006 9:58 PM
|
|
Thanks for your blog Guido. It confirms a lot of what I've read and suspected about Ruby and Python frameworks, namely that they are great if you wish to build a certain type of application but perhaps not flexible enough to build something unique. I've been interested in trying out TurboGears and Ruby on Rails, however, my current project has specific and custom requirements. These requirements have led me to use the Catalyst framework which is written in Perl. I'm not going to try and convince anyone to use Perl or Catalyst but explain why it's different and why it's approach maybe one that fits your needs better. It's more a difference in philosophy than anything else. Perhaps it can shed a different light on the situation.
Ruby on Rails and similar frameworks offer a "full-stack" approach. They tend to have a solution for everything but only one solution. If you want something else you may be on your own. I've often hear the phrase "The Ruby Way" which tends to discount differing real-world requirements. If your requirements happen to be different, the framework may not be usable at all. Catalyst offers a modular approach to framework building. At it's core there is a flexible url dispatcher and support for multiple HTTP engines (mod_perl, FastCGI, etc.), but it's attractiveness is that it gives you a choice for the items you mentioned: templates, persistence, authentication, sessions, forms, etc. There are many templating systems supported including 3 popular HTML options, XML/XSLT and even PHP. There are several caching options including local memory cache, local file cache, and memcached servers. I recently moved from a local memory cache to memcached servers simply by switching plugins. Session management has the same options including using a database-backed system. There are also multiple ORM choices including 3 popular ones but if a raw database connection is what you need for raw SQL, that's available as well. Perl ORMs can load existing database schemas, handle multiple joins and recognize foreign keys. Some Perl ORMs also include a raw SQL passthrough as an option for occasional use. As much as some would like to think otherwise, there are some SQL queries that cannot be easily abstracted via an ORM. For my current project I need the flexibility of having a choice of pre-built components but creating my own as well. For example, I have use a custom authentication framework.
The difference between Catalyst and other frameworks is, in part, based on the difference between and age of the language communities. Without getting into a debate about which is better or worse, let's just say they are different. In Perl, there is a recommended way but it's not the only way. Without discipline, this can cause issues issues but it has also led to to multiple mature ways of doing things. Before Catalyst, there were already multiple mature Perl templating systems, ORMs, etc., each with their own community joined via CPAN. To support the existing Perl community, Catalyst has to be flexible and modular. I have the impression that other languages don't have as large an existing library with mature competing solutions so it's easier for a framework to be a full-stack.
Sometimes a full-stack is better and other times a more flexible approach is better. It depends on the project requirements. I've recommended full-stack Python and Ruby frameworks when the project fits but when it comes to custom projects, Catalyst lives up to the Perl slogan "making easy things easy and hard things possible." For a creative, custom project, I don't want to take any options/capabilities off the table. As much as I'm interested in the language elegance of Python and Ruby, when it comes to frameworks, Catalyst gives me the flexibility I need. I'm not yet convinced the full-stack frameworks can but perhaps, with this discussion, Python frameworks will become more flexible and a viable option.
|
|
Previous Topic
