What do you want in a new web framework?

[Paul Boddie]

Cliff Wells wrote:
> On Thu, 2006-08-24 at 04:04 +0000, Tim Roberts wrote:
> > Cliff Wells <cliff at develix.com> wrote:
> > >
> > >But there are interesting things in Ruby (and Ruby 2 should take care of
> > >lots of warts Ruby 1.8 has) that Python could learn from.  All-in-all,
> > >Ruby is mostly as good as Python in most ways and better than Python in
> > >a couple key ways.

The big difference between Ruby and Python is the lifecycle phase that
the languages/systems are in: Ruby arguably has room for a lot of basic
improvements in the architecture of the virtual machine and presumably
has a list of "must add" features that cover gaping holes with respect
to certain audiences [1], whereas Python has been around for ages and
has covered most of the critical gaps in the feature list (although we
can always suggest things which bother our own part of the community).
Whereas the Ruby people merely have to agree on how critical their
missing features are and to move in one widely agreed direction, the
Python people face a tougher choice as to what should be done next;
strategies include a tidying-up exercise to make the language more
coherent, a complete reimplementation, deep modifications to the
runtime, the introduction of radical new semantics.

The fewer obvious issues that a language has, the less energy there is
in the community to deal with those issues thoroughly, I think. I guess
the Perl community chose a bold new direction in line with the
observation that a big vision can inspire much more in people than lots
of incremental changes to an existing vision, but the energy required
to follow through on such a vision can be immense. In addition to all
this, a large existing community is more likely to want larger benefits
for smaller levels of disruption because of the amount of existing
code. Thus, the available energy for change is less in a mature project
than in a growing project because people have to constantly monitor the
breakage in their existing investments in the language.

> > ...but you can't READ Ruby code.
>
> Yeah, that's one of the big reasons I haven't seriously considered
> trying it.  It's expressive, got interesting features... and appears
> unreadable to me.  I'm usually pretty good at deciphering most
> languages, even if I haven't used them before, but Ruby is one of the
> exceptions.

My feeling is that I'd rather learn more about Lisp or Scheme than Ruby
- the benefits are greater and for me Lisp and Scheme increasingly have
the edge on readability. Perhaps I'm just not "tuned in" to
Smalltalk-style syntaxes.

> This brings us back around to the web framework debates.  For many
> people Ruby "fits" their brains and for others Python does.  I think
> frameworks are similar.  I tried Django and while I thought it was a
> great product, it simply didn't "fit" how I think about that problem
> domain.

I thought that the most interesting thing about Django was the URL
mapping strategy it employs, although you have to be fond of regular
expressions to really appreciate it, I think. The template and
persistence mechanisms used have the principal advantage of just being
there in the same package when compared with other solutions, and I
don't think they'd have many fans if they were just some random
projects available from the Python Package Index.

> TurboGears on the other hand did, and really, it helped clarify
> a few things I had vague notions about.  I think we'll do better not
> trying to shoehorn people into one or the other.

The goal is to provide appropriate solutions for particular problem
cases, especially common cases like database-backed Web sites, rather
than choosing something which only does a particular flavour of
database-backed site and then claiming that it's a silver bullet. I've
written a number of Web applications for my own use, and many such
applications either don't use a relational database or use it in a way
that is completely orthogonal to some relatively simple
object-relational scheme. Some of these applications are admittedly
simple, but having to create various tables in relational databases as
an offering to some framework deity is pure unnecessary overhead that
should suggest, at least to the more objective among us, that any
solution requiring such baggage is perhaps not always the most optimal.

Paul

[1]
http://headius.blogspot.com/2006/06/unicode-in-ruby-unicode-in-jruby.html