From: Lennon Day-Reynolds <rcoder@...>
Date: 2004-07-27T02:00:42+09:00
Subject: Re: rubyonrails and cgikit comparison

I've been working on some DHTML-based application prototypes recently,
and have thought about exactly these issues, as someone else (read: a
non-programmer) will likely be responsible for some layout and
content-editing work.

In effect, the big question is how many domain-specific languages you
need for web application development, and who should be responsible
for learning and using each of them. In most any modern project,
you're going to have at least three in the web tier alone: HTML,
JavaScript, and CSS. Your backend will then included some core
implementation language, (preferably Ruby, of course) and usually SQL.

If you're using a templating language as well, (as opposed to the
ASP/JSP/PHP style) that brings the language count up to six. Even if
your designers can handle the four front-end languages, you're going
to need programmers who handle the context switches between all six
without too much difficulty, as even minor bugs may result from issues
that cross boundaries between many different tiers: i.e., a
badly-formatted string in a SQL field gets mangled somehow in the
backend, after which the template dumps bad HTML that your CSS and
Javascript can't format or control properly.

(Those frameworks that try to use XML for everything don't really help
much, either: they just tend to end up with another three or four XML
grammars to work with, and often throw some embedded DSL in for things
like conditional expressions in attributes.)

Anything you can do to reduce this language count is worthwhile, IMHO.
That's why I prefer the "server pages" model (which Rails basically
uses) to specialized template langauges -- your designers may not be
able to do more than the most basic, idiomatic work with the
templates, but at least your programmers won't have to page out one
language for another just to check a change in the display logic. With
a framework life Active Record, you can also mostly eliminate SQL from
your backend programming, which further reduces the DSL count, for
common tasks at least.

The other option which seems to work well is using Javascript as a
display logic language.  It would be interesting to see more
Javascript libraries designed for use by designers that either
"compiled" into some sort of backend code, or masked RPC-based calls
to your app server, so that the calls could even be intermixed with
client-side DOM processing.

My slightly-more-than-$0.02,

Lennon