Recently I've been messing around with what I see as the 4 main frameworks, and I was wondering what other people think of them.

Rails
===

Not a big fan, I prefer the Modelling approach instead of the `write SQL for a table` approach. Nice functionality in the background, and pleasantly written in ruby :)

Turbogears
=======

Seems the easiest MVC framework to use, everything goes logically, although in places it is a bit verbose (the decorators above controller functions). What I don't like, is there isn't a lot built in to do things quickly (a django-style built in admin module would be delicious). Catwalk might make up partically for that, but it's only really for during development more than something sustained.

Django
====

Sort of like turbogears, Seems to use SQLObject too, but a different version (???). I love the admin module you can quickly whip in, but it seems more terse than Turbogears, and I don't like having to export variables in bash just to use it.

Catalyst
=====

Mildly impressed with the videos, but I have yet to get it to work (everytime i try and compile it with the perl CPAN module, it buggers up somewhere)

Anyone else?

Frameworks for what? If you're talking about frameworks for webdev then there are many other very nice frameworks just for Python; do you mean those that have some resemblance to Rails?

Zope for instance has been around for years and is very well developed :) -- I'm not a fan of it because of how steap the learning curve is* but it's worthy of consideration I think.

There was a time that Devshed was built on top of Zope and it's certainly got a large share of users :cool:.

Anyway Rails looks very sexy and it's written in a language that I'm very fond of but I'm not much into web development anymore :). It seems to be cleaner than Turbogears but that's just my personal opinion.

I think that it comes down to the language being used rather than any major differences between the systems.

For that reason I don't see Catalyst catching on as well as the others because Perl doesn't naturally lend itself to the MVC paradigm as well as other languages :confused:.

I haven't tried the others at all so I can't comment on them.

Mark.

* It takes quite a while just to learn the basics.

Anything MVC is really what I'm on about.

Zope is reasonably popular, but like you say, the learning curve... You couldn't exactly jump into the plone code and know what it does... I might take another look at it...

Rails would be nice if it had a modelling counterpart and was more customisable. It enforces templates for one thing, so if you just want to output a flash without reloading the page, you're buggered. I'm liking turbogears a lot like i said, it has potential, and of the three, it's my personal favourite. Django has some neat features i'd like to see go into turbogears. One thing I do notice is that django attracts a lot more attention than TG if you go by number of people in the IRC room. Rails' strengths are that it's great for beginners (if they happen to have a mysql GUI on hand) and that it's written in ruby (you have got to love that). Rails is just way less inflexible, and while scaffolding is nice, it's not the be-all and end-all, it just wouldn't suit larger apps, whereas turbogears seems to be the most flexible (it just doesn't write as much code for you ;)). Django and Turbogears both have a modelling stage too, which I'm definitely a fan of. No more SQL, no need for a database GUI, just pure programming in the language of the framework. Much easier to update the layout as well ;) I suppose they aim for different things, because TG and Dj just don't lend themselves to super-fast RAD. But it comes back to the adage of taking time in things that matter.

Catalyst looks to be on a sound foundation, actually. There are some screencasts if you're interested in looking at them. You might not associate perl with the MVC concept, but it doesn't do badly at all.

I'm surprised you didn't mention SLIME, after having introduced me to it. I personally can't imagine anything more inefficient to do with my time, with the exception of trying to learn a dvorak keyboard layout again. The screencast took 10 minutes just to set something up, and then it didn't seem to provide much you couldn't get from lisp itself. I'd like to see a decent lisp web framework though.

I haven't done much with Rails but I've read a lot about it and tinkered with it a little. What I like about it is that you can get a lot done really quickly � you can do some very impressive things without typing much at all.

This speed is a major advantage, especially if all your creating is a GUI to a larger system and you don't want to spend double the time on this task.

That's an achievement in itself. Another thing I like about it is that Rails will create pretty much everything you need, and I'm pretty sure you can add to this and generate other things. (From what I've read it's built around Rake and that is very flexible.)

Scaffold can do a lot but it does work with SQL, thats it's what it's about. Scaffold without SQL serves little purpose in my eyes. It would be nice to be able to have the same development speed without database backing though :).

I think I'll look at Catalyst, I'm not a fan of Perl but I'd be interested to see how well it handles MVC :cool:.

I'm not sure why SLIME comes into this Penguin. SLIME is the Superior Lisp Interaction Mode for Emacs and in my experience it can speed up development time considerably.

Even if you only use the it for editing you'll still gain a lot of power and flexibility from treating code as more than text i.e. you can move though the code very quickly, you can move or delete parts of expressions, preform all sorts of actions on s-expressions etc.

Code completion and frame inspection is also a big win :).

None of these seem like they would be a waste of time to me. But then I spend a lot of time in emacs with Lisp, maybe you don't :). What's your point?

I'd love a good Lisp framework and there's talk of Lisp On Lines :). Don't know how well that will go but its an interesting idea. If Lisps power could be fully leveraged on the web I'm sure it would succeed.

The first webapp was written in Lisp and it was an amazing piece of work :D.

Later,

Mark.

Hi LP,

I really like Django and Turbogears - been using Django more, since TG was pretty underdeveloped when I was looking into these things. Another thing I didn't like about TG was that it had to run via CherryPy, and I prefer Apache ( I know there are ways you can get Apache to front CherryPy, but it's a hassle ).

I have to say that the database API is critical - your DATA is the most important thing, and is far more likely to outlive this years web app you've wrapped around it. I REALLY do not like apps guessing at my db design, it's just wrong ( I know this is a weird argument :) ). I preferred the Django-style API to the others I looked at e.g. foo.get_list( fieldnamecontains = 'some text', otherfieldequals = 'bar', order_by =[ 'field1', 'field2' ] )

One of the best tests of a DB API is trying to write a complex query with multitable joins and a few GROUP BYs - none of the ones I looked at in detail really do this ( the problem is mainly due to the fact that SQL is more syntactical, and doesn't work very well in an OO framework ). In practice you can probably get around this - Django for ex. you can just add a new method to the model and hand code the SQL directly in there.

What else? I've heard good things about Struts, but I have never liked java. Haven't tried Catalyst, again, not a perl fan ( I don't hate it, like I hate java, I just prefer others :) ).

The Zend people are working on one for PHP, the Zend Application Framework, which looks to be interesting, even if it looks like it's a while off. The PHP people are also placing a lot of emphasis on PEAR and PECL, which are archives of download-able extensions similar to Perl's wonderful CPAN. Hopefully for them, the horse hasn't bolted yet, and PHP can drag back some converts to RoR/etc. If they can get a decent framework built-in to PHP, and a sizable CPAN-like archive soon, then things will get very interesting.

Personally - at the moment, I'd use Django when I want an admin section, TG/RoR (maybe) when it's a simple app, and PHP for brute speed. Note that the Django team are heavily working on their "magic removal" branch, which is designed to clean things up a bit, will break some older apps. The official release of this is "soon", so it might be worth waiting for this to go through before starting anything major.

--Simon

PS: exporting bash vars with Django - yeah, this is crappy. There's been some talk on fixing this in their mailing lists, but I haven't seen anything concrete.

Hi Simon,

Yeah, the tg/cherrypy thing has been a real hassle for me, since i've been trying to run my apps locally under apache. That's one thing that needs to be fixed.

TG looks the most promising apart from the cherrypy server crap, but until they remove that, it's effectively useless in my eyes. I don't see it being removed, so I think i'm going to go down the Django path.

DB APIs, I quite liked the turbogears one, the linking of tables was stupidly easy. for those who haven't used it, here's a sample

class User:
name = StringCol(length=200)
password = StringCol(length=32)
posts = relatedjoin("Post")

I'll be upfront, I'm not a database expert, and while I can so joining and things just fine, indexing and joining on more than 3 tables is pretty much beyond me, and for that reason, it's fantastic having an easy abstraction like that. There seems to be a reasonable method for sorting data in TG too, which is nice.

Struts seems to be quite popular, but I'm not big on java. I got a book on java so I can at least say I've tried it before I condemn it (and from what i've seen so far, that's the way it's going). It's infinitely cleaner than C or C++, but right now i'm trying to avoid programming in those too. What is reasonably nice is that to get a partially compiled language, it's much quicker to develop a GUI app with Swing than it would be wrapping the windows and gtk APIs in a crossplatform wrapper. Swing is pretty simple to start with, although that's not really for web development, but hey, I wandered off topic. Java is too verbose for my taste, but I might give struts a look over. I believe there's another java framework that's quite popular as well, i need to look that up.

RoR i'd use if it was a really simple app and I had the database sat in front of me, i don't like writing SQL... I think i'm going to look more at django, because between python and ruby, i'd prefer ruby, but since RoR doesn't support database modelling, i'd much rather use Django.

I did put together a mini Controller library of my own in ruby, that i'm itching to try out. The code is tiny, even with error checking. The database wrapper code is probably going to be the hardest AFAICT. Rails is nice for a little speed, but it's only useful for really simple apps IMO. It would be impossible to write the site I'm working on in RoR, and that's why i've lost interest.

On another note, after finishing my copy of Programming Ruby (well worth it's cost, FYI), I just can't go back to programming a static language like C, it's just so inflexible in comparison, and flexibility is power. Between Ruby, Python and GCL, I think i've found what i'm looking for.

I don't understand why RoR is being reputed here as only being useful for simple apps; people are doing some very interesting things with it.

I can accept that different people will prefer different frameworks for different reasons but none really seem to be better than the other :).

Django looks interesting. I like that they've put a lot of emphasis on automation; this is a major win. What you want from a framework like this is RAD, otherwise I suspect you'd just write your apps from scratch yourself :cool:.

It seems to me that simplicity and ease of use is being mistaken; that these qualities mean the framework is lacking in power and flexibility. I'm sure that any application written in any of these frameworks could be produced in any other (with varying amounts of work.)

Each of these implementation languages can interface with the outside world, and applications written in other languages if needed. I'd certainly dispute that anything is "impossible" in any one of these.

RoR can be extended with plug-ins easily enough. Why not make db interaction work how you want.

Like a lot of things I think it comes down to the language being used. Ruby's use of high-order functions makes code very expressive and reusable � I love it. Pythons overall simplicity makes it even easier to follow and generally pleasant to read :D.

I quite like CherryPy :). But it would be nice if you didn�t have to run the server if continually. I think it gives you some advantages. Being able to deploy CherryPy apps in places without a web server could be very useful in some situations.

The only concern that I can see is performance and I don't think that�s as much an issue as it might be. All but the very largest websites should be fine IMO. All of these systems are more than capable :).

Java doesn't strike me as especially beautiful. Theses still a lot of inflexibility built in, IMO too much. Static typing is the worst.

From what I've heard about Java webdev it seems to be especially confusing: you have to make decision after decision before you even get started learning because there are so many libraries and systems for the same thing, all with there own implications.

That doesn't really make me thing about fast turn around but I could be wrong.

:) Later guys,

Mark.

Once you start plugging things into RoR, you lose so much of the goodies that people love about it (scaffold, anyone?). The issues are of complex database designs (at which it's pretty much guessing how it works). Let's take an example.

I'm developing a development site, nothing on the scale of sourceforge, but with the scale of features it has. Now I've worked out a database schema that makes good sense and it's quite complex. From what I've seen with RoR, it's going to be REALLY HARD, if not impossible to achieve it with ActiveRecord and all that crap. Roll on Django, where the entire thing can be specified with perfect ease. Rereading the simple tutorial, i'm really loving it. Yes, I love ruby more than python, but you've got to make SOME compromises, and IMO, it's not a major compromise. Besides, i prefer indentation to a stream of `end`s.

Of course, Scaffold is dependent on things being done as it expects. But this is the same with everything. If you give functions the wrong arguments for instance you can't expect it to work.

What I was suggesting is that you write a plug-in that lets you use Rails the way you want to use it � to express these relationships in your db. If you can do it in a way that's compatible with Scaffold then even better. I'm sure that something like this could be added to the system � it's open source :).

The point was that RoR could be used for more complex things. I don't ever intend to use it but the system has its merits; and a lot of potential.

Mark.

I don't understand why RoR is being reputed here as only being useful for simple appsHere are some issues I've come across with RoR that take it out of the running for me: ActiveRecord does not support multi-column primary keys (http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/140320):

> Is there a way to set an ActiveRecord object to point to a table
> with a multi-column primary key?

Not really, no. Active Record was designed for a single column
primary key and that assumption runs pretty deep. AR is not a Data
Mapper, so you have to be within a reasonable vicinity of its
assumptions to enjoy it. ActiveRecord does not support character-based primary keys. This is mentioned at http://discuss.joelonsoftware.com/default.asp?joel.3.309321.3 along with many other AR short comings, some of which have been addressed recently. Ruby and RoR do not support Unicode. http://wiki.rubyonrails.org/rails/pages/HowToUseUnicodeStrings says "Rails basically knows nothing about Unicode [...] This is being looked at, but in the meantime you use UTF8 encoded strings at your own risk and you can expect (and wil get) bugs and problems :-)". http://www.fngtps.com/2006/01/encoding-in-rails talks about some hacks.
I can accept that different people will prefer different frameworks for different reasons but none really seem to be better than the otherCatalyst (http://www.catalystframework.org) and DBIx::Class (http://search.cpan.org/~elliott/DBIx-Class-0.06002/lib/DBIx/Class.pm) support multi-col PKs, character-based PKs and Unicode. From my perspective, the fact that RoR/AR don't makes Catalyst/DBIC clearly better because these three issues are show stoppers for me. I'll consider RoR again when it gets these capabilites.

I stand corrected :). I have to say that I didn't even consider Unicode.

That aside I still think that any application that could be written under one could me written in another. Obviously these limitations are going to be a real annoyance under certain circumstances but I'm sure they could accommodated for at the design stage. Not that you should have too!

To be honest I'm a little bias :). I like the Ruby language. RoR doesn't mean anything to me at all but I like the use of automation to improve RAD. That's something I haven't seen effectively elsewhere.

Catalysts use of Perl is enough to make me want to stay away from it and Pythons just on my "uninteresting" list right now. Not for any particular reason, just stalled on it.

Ah well, live and learn. Thanks for the info :),

Mark.

You said it netytan living and learning is always the key to life :)