Jim Roepcke's weblog have browser, will travel (est. 1999)

On 24-Feb-07, at 7:40 PM, Greg Pierce wrote:

> On Feb 24, 2007, at 6:56 PM, Jim Roepcke wrote:
>
>> I want to try out Django <http://www.djangoproject.com/>, a new
>> Python-based web development framework. Unfortunately, getting its
>> dependencies installed on Mac OS X is a massive pain…
>
> Um, not sure about that. I setup and was running Django on my
> MacBook in about 15 minutes. I did already have a current version of
> MacPython installed, but otherwise nothing special. I haven’t pushed
> it though any heavy paces, so maybe I’m missing something, but it’s
> working.

Maybe you didn’t follow the instructions carefully then, or you got
lucky with what you already had installed. I have a suitable Python
installed as well. I also have Postgres 8.x. Their instructions
insist on using psycopg 1.1, not 2.0, which they claim is in beta. I
did some checking and found (early last week) that there were bugs
with Django using psycopg2. So I tried to build 1.1. That required
some other Python stuff first, which built fine. However, psycopg
1.1 wouldn’t build against the Postgres I have installed, IIRC it’s
looking for Postgres 7.x -style headers. You also need mod_python,
which I didn’t have, and I didn’t like the idea of installing that
into Apple’s Apache, so I would have had to install my own Apache 2
and mod_python. I could have used DarwinPorts but then I’d have to
use their python24 package, and basically, I could go on but it was a
total mess. It was very easy to get Rails running (I built
EVERYTHING from source even), and getting Django running on Linux was
also trivial.

I like the Rails installation philosophy better, and it’s cool that
it comes with the MySQL stuff built in. In terms of initial setup
experience, Rails wins big time. Or should I say, O’Reilly wins big
time because getting that far that fast prompted me to spend $100 in
O’Reilly books (Agile Rails 2nd edition and Rails Cookbook).

I have some other good things to say about Rails, later. Obviously,
those things weren’t the deal breaker.

>> From what I can tell, with Rails, once you’ve got your (data) model
>> set up, you might as well be doing PHP development.
>
> Mind you, I do like Rails, but I don’t consider myself a platform
> bigot on any case.

I’m a bigot. I am very picky, and based on experience and study
there are certain styles of development that rub me the wrong way and
I avoid them like the plague. A few years with (97-99) ASP taught me
a very important lesson: web projects are more difficult to read and
write (develop and maintain) when templates mix with code. I am very
religious about this: when I see a platform with a template system
that requires code to mix with templates, I wretch, recoil, and move on.

BTW, I tried to make it clear in my posts but I wasn’t saying I
favour Django to Rails, only that I don’t like Rails based on what
I’ve seen. Django is either my next love or my next victim. I’ve
only just installed it, and have barely started learning it. I’m
working through the (beta) book.

I was complaining to a friend of mine about Rails two nights ago, and
he had the same experience as me. He’s become enamoured with Django,
and suggested I get over my annoyance with installation and give it a
shot. Based on his advice, I think it’s worth giving it a look. At
least it’s in Python, which I’m more familiar with. As I said, if I
don’t like Django, at least my Linux server is updated!

> This is interesting to me because I just spent
> the whole day immersed in Django on Thursday in the lead up tutorial
> day before PyCon. So I’ve been thinking about the pros and cons of
> each.
>
> I think you are not connecting somewhere with Rails if you think that
> way about it, however.

I think that “embedded ruby” HTML templates are a horrible, horrible
idea. They encourage really poor separation of concerns, lots of
sloppy anti-MVC display patterns, they’re hard or impossible to deal
with when you work with an HTML designer and/or work with designers
on a complex, large-scale project, they’re hard to read, hard to
debug, hard to reuse/repurpose, hard to port, and far too accessible
to really bad developers.

If there is a hell, surely it is filled with great programmers forced
to maintain ASP and PHP applications.

The “builder” templates, ugh. Actually, for XML I think they’re
fine, even good, but for HTML, worse than ERB. I knew from day 1
that I wasn’t going to like ERB, so when I found out the alternative
was worse I was not impressed. I spent a whole morning this week
researching templating packages for Rails and was disappointed beyond
description. The only thing that looked half-way decent was
MasterView (I think that’s what it was called). But then I found out
Masterview templates were translated to ERB. Game over. You
loooooooose.

And that’s when it hit me, Rails is so tied to its default style of
front-end development that a templating language like the one I like
just wouldn’t work. Rails templates are full of “tags” (in the ASP/
JSP/PHP sense) that call Rails API functions (with Ruby parameters)
which return strings that are HTML tags. That style just does not
translate to a decent templating environment without reinventing
hundreds of wheels. Those functions are worse than opaque. A
skilled HTML/CSS designer would justly have heartburn when they found
out they had to accept what those functions emit. I don’t care what
they emit, the HTML might even be clean and semantic and accessible,
but it’s unacceptable. Maybe Rails has some templates for what all
those functions (link_to, etc) emit, but I doubt it, and if they do,
they won’t be much better than ERB to begin with. Trying to skin a
Rails app must be torture for a talented designer.

I’m not a designer, I refuse to be a human browser-bug-workaround-in-
JS-and-CSS-and-HTML-encyclopedia, so I rely on skilled HTML/CSS/JS
designers to tell me what to output. I take that and the
requirements to create an application. I would have to spend too
much time rewriting Rails’ hundreds of convenience functions, and
there’s no business value in doing that. If there’s one thing I hate
doing, it’s mundane grunt-work development. That’s why I look for
tools that scale. Rails makes great screencasts for making blogs and
CRUD, but I have *very little faith* that the front end portion of
massive Rails applications would be remotely pleasant.

For little/medium-sized apps, maybe this paradigm hits a sweet spot.
But I don’t think in those terms. I think big, because it’s those
big applications that drive me nearly insane when the tools/
frameworks break down.

>> Rails’ template/component systems are pure torture.
>
> If you’re even looking at “components” in Rails, you shouldn’t. It’s
> a deprecated technology that was a mis-fire to begin with.

I’m not talking about “components”, I’m talking about components, as
in, refer to the last 25 years of software engineering progress
components. From what I’ve seen I don’t think Rails’ developers have
a clue. ActiveRecord is great, and they know their stuff when it
comes to seriously leveraging dynamically typed languages like Ruby,
but the whole equation falls apart at components.

> Django’s templates are really much less powerful than Rails’
> ERB…and other builder options. Particularly plugins like Markaby.

I don’t remember if I saw Markaby, though. Ugh, just googled it,
it’s just a different syntax for builder templates. People at
various jobs over the years have shown me there personal C or PHP
based libraries that look just like that and I’ve never liked it.
Sorry.

Before I read your reply I was reading the documentation about
Django’s templating system. By now it should come as no surprise to
you that I don’t like it either. However, less powerful is actually
an improvement. With one caveat: the “reasons” they give for some of
the limitations in their template language sound like weak excuses to
cover up for them prioritizing performance over expressiveness. I
don’t believe for a second some of these limitations are
“philosophical”. One example: They support array index access like
this: “foo.2″, but I think that’s just to keep their grammar simpler,
not any other reason. It’s horrible syntax, and they don’t even
allow “foo.-1″ which would enable some of Python’s nice list indexing
functionality. In a way, that’s good, because I believe templating
systems should be language-neutral, but then they don’t even define
nice convenience methods on the base classes to make up for it like
ActiveSupport does in Rails. That’s just one example, I could name
several more but I’d be writing all night. If you think foo.-1 is
convenient, and your implementation language happens to support it
natively, just say your template language does too(!), but not
because the implementation language does, just make it part of the
template language spec, define it clearly, and make it clear that
compliant implementations must support it regardless of the
implementation language.

But to get back to “less is more”, I really think code in HTML is a
bad thing, so not being able to put a complete language in a template
is a VERY GOOD THING in my opinion. It forces the developer to do
that logic in the controller where it belongs, which loosens the
coupling between data model and presentation layer, and web framework
language and template language.

> Django’s are also somewhat backwards to me, the the block definition/
> inheritance approach.
>
> That said, you can use other python template engines with Django.

And that’s why Django is currently winning in my book. If I decide
to use Django, I will use TAL with it. TAL/TALES/METAL is the only
decent environment I have ever encountered for HTML/XML/XHTML
templating.

> As far as ASP/JSP/PHP — I’m a little lost. Django and Rails both
> have a template engine that lets you put code in delimited areas like
> ASP/JSP/PHP, but both discourage you from putting functional code
> there. Can you? Yes, but it would be bad design in Rails, which is
> fully MVC — Django isn’t, and doesn’t have a real “controller”
> layer, and embeds more presentation logic in the model layer and
> expects your templates to rely on that.

I’ll believe you there, I haven’t gotten far enough through the docs
yet. So far, I’m not that impressed by Django. Rails and Django
both strut their method dispatch functionality first thing as being
great and powerful, one does it “magically”, the other does it in
excrutiating detail (it would seem), but to me neither is very
interesting. URL translation method dispatch, big fucking deal.
Seriously, yawn. I saw very little in Rails controller layer either,
compared with what I think an MVC web development framework’s
controller layer should be able to do.

I have to reserve judgement on Django at this point because I’ve read
so little about it but I’m not encouraged so far. I will say
however, it doesn’t look like they rely on tightly coupled magic
throughout the framework so it looks like something I can introduce
my own idioms into without a massive rewrite. That’s important to me.

>> I have it on good authority that Django should suit my tastes
>> better, and I hope that’s the case! Worst case, my Linux server is
>> now up to date and I now know how to build deb packages from
>> source.
>
> Django’s big plus is the auto-generated admin interface with built-in
> security, which makes it very well suited to rapid development of CMS
> type applications where you are pushing out public content controlled
> by small number of administrative users.

Yawn. The scaffolding features of Rails and Django don’t interest me
a bit. After Direct To Web in WebObjects, there’s absolutely no
comparison. If I want a customizable admin interface, I’ll fire up
WO and D2W without hesitation.

My first reaction to Rails was, “how hard would it be to port Direct
To Web to Rails?” But then when I realized their component story was
so weak it was basically moot.

> It has less developed
> presentation layer tools — like no integrated AJAX framework or form
> building tools.

It’s newer, younger, I’m not surprised. They don’t seem to be trying
to associate themselves with Web 2.0 like Rails is, I think that’s a
big distinction. Good for Rails being strong with Ajax.

> If you have an application that requires end-users
> do a lot of interaction with the datasets, you’ll have a lot more
> work in Django than you would in Rails.

Could you expand on that? From what side(s) of the equation, the
model layer, the presentation layer, the controller layer? What does
Rails do to simplify interaction with datasets? I’m guessing you
mean that Rails’ API has tons of convenience methods that make take
care of the obvious things. I agree they have encapsulated MANY
common patterns in web application development.

It was that and ActiveRecord that kept me hoping I would find
something in Rails before I finally had to give up on it.

I was disappointed by the 3rd party add-ons… I figured there would
be 5x as much quality code out there.

> Django’s Model layer mixes presentation and data rather broadly.
> This enables the automatic admin features, by allowing you set
> attributes about your fields at that layer.

You could argue Direct To Web mixes presentation and data broadly
too, it lets you write reference your model layer’s configuration/
metadata in “rules” that the templates refer to. But I don’t think
it’s a coupling of presentation and model, because the templates are
written completely generically to support any data model, and the
data model has no idea it’s going to be used by a rule engine.
Totally decoupled.

> Rails is more pure MVC approach.

“Pure” as a classification doesn’t give much wiggle room in
debate. I’ll respectfully disagree, but I am being picky. But
given my experience with MVC, I think I have a leg to stand on.

> ActiveRecord is a well developed
> and flexible ORM layer that encourages good separation of the
> presentation and model data. It’s based more on introspection of
> your database

ActiveRecord is a little too thin for my liking. Just relying on the
schema is asking for trouble, down the road. I prefer EOF’s more
database-agnosotic approach. And EOF provides developers with better
model metadata. From what I’ve read you can’t even properly
introspect a Rails app (out of the box) to get a complete inventory
of its data model. Part of the problem is just how dynamic an
environment it is, but the other part is the philosophy of not
providing any model metadata. Migration code is not reflective at
runtime, and relational schemas are not remotely decoupled from
proper Domain object modelling.

And don’t get me started on transactions. Or undo. I’m spoiled by
EOF, obviously.

> , and has more long term maintainability built in using
> Migrations.

There are plenty of gotchas with Migrations, but I’ll give them props
where its due, they’re on the right track for sure!

> Django doesn’t support these type of features right
> now. If you run “syncdb” in Django, it’s essential a drop the db and
> start over sort of operation.

Any serious project will have someone that can manage this part of
development and make sure that migration is taken care of. It’s nice
that rails does the 80% solution for you, but it’s not the holy grail.

> Rails also has good testing integration at all levels, which there is
> no explicit support for in Django. Rails also has good deployment
> tools, like capistrano.

I’ll believe you, but testing integration is nothing new to Python.
I don’t think there’s any question that Django is less mature than
Rails right now.

> All that said, Django is very cool — if you’re application fits in
> their forte for CMS type sites. If you’re getting out of that realm,
> I think you’d find Rails more flexible and powerful.

The Rails value proposition is in rapid development, they deliver
that with a large API with tons of convenience, and tools like
TextMate that back it up to make it even easier. But those APIs are
tightly coupled with their presentation layer, and fixing that for
large scale development appears to be a task on the order of a
complete rewrite. I’d LOVE to be the guy to do it, to “put my money
where my mouth is”, but I’m not in a position to do that today, and I
really want to support a platform that already “gets it”, I mean, is
aligned with my priorities and tastes.

> If you want a more pluggable, flexible alternative to Rails in the
> Python community, you might look at TurboGears, also.

You’re right, I should look at that too.

> There’s a lot more points that could be made for each, I’m sure. But
> those are my thoughts at the moment.

Thanks for sharing!

Jim

I’m considering attempting to port simpleTAL
(http://www.owlfish.com/software/simpleTAL/) to ruby. Would either of
you be interested in helping? I have already found a rbuy port of
python’s smllib/htmllib, though it’s fairly old (simpleTAL depends on
python’s sgmllib). I likely will not be able to do it myself, but if
it were a group effort it would be easier.

On 2/26/07, Greg Pierce <greg@turtleprod.com> wrote:
>
> On Feb 24, 2007, at 11:27 PM, Jim Roepcke wrote:
>
> >> If you have an application that requires end-users
> >> do a lot of interaction with the datasets, you’ll have a lot more
> >> work in Django than you would in Rails.
> >
> > Could you expand on that?
>
> Well, I think you’ll find on further inspection Django is very good
> at what it does, but is really not that much other than a tools to
> rapidly throw a db on the web. It’s extracted from a publish
> environment and was designed to allow a newspaper to get data on the
> web quickly with an easy to maintain admin interface.
>
> I don’t think you’ll find that it has any special capabilities that
> make it a good tool to build “large” applications.
>
> Mind you, I agree that Rails has issues in these areas, too.
>
> I’m not dogging either environment. They both do what they do very
> well, but are not right for every web application.
>
> I agree with you on TAL templates. I wish that approach would become
> more widespread.
>
> g.
>
> –
> On hbwt at: http://jim.roepcke.com/7644
>
>

–
Steve Ivy
http://redmonk.net