Phatj 's Profile

The paper points out that Rails makes using AJAX easier with RJS and the integrated JavaScript libraries, while Django includes JSON functions, but leaves all JavaScript coding and even the choice of client-side libraries to the developer. JavaScript wizards may prefer Django's hands-off approach, but everybody else benefits from the built-in AJAX support in Rails.

On the other hand, they note the Python framework offers better infrastructure for internationalization thanks to native unicode support and gettext message substitution, allowing for multi-lingual sites with localised responses to individual HTTP requests.

A major advantage for Rails is the migrations mechanism which facilitates experimentation and evolution of the data model, even for apps already in production. Django has nothing of the sort. If Alan and Ben had omitted the migrations from the line count, their own numbers show that the Ruby and Python code would be about the same size and, after adding the templates, the Rails solution would have 15% less lines of code than the Django one, even while providing custom admin pages. So here the authors compared apples to (non-existent) oranges, with a bias which favored Django.

he next step up was the Model 1 architecture,
which had developers pushing most backend code into JavaBeans components and then
importing the JavaBeans components into Web pages with the <jsp:useBean> tag. This worked well for simple Web
apps, but many Java developers disliked JSP technology's incorporation of C++ features
such as static includes. So the Model 2 architecture was introduced.

Essentially, the Model 2 architecture is a watered-down version of
MVC for Web applications (see "About MVC"). In
the Model 2 architecture the controller is represented by Servlets and display
is delegated to JSP pages. Struts is a simplified Model 2 implementation
wherein Actions take the place of Servlets. In Struts the application's
controller logic is separated from its data (represented by ActionForms).
The main complaint against Struts is that it can feel more procedural than
object-oriented. WebWork and Spring MVC are two other Model 2 architectures
that improve on Struts by being less procedural, but neither is as
widely accepted (nor as mature, some would argue) as Struts. Plus
neither offers a component model like JSF does.

The real issue with most Model 2 frameworks is that the event
model is too simplistic (essentially a very scaled down MVC), which
leaves too much of the work to the developer. A richer event model makes
it easier to create the kind of interactions most users expect. Like JSP technology,
most Model 2s also make it too easy to mix HTML layout and formatting
with GUI custom tags, which act loosely like components. And some Model
2 architectures (like Struts) make the mistake of separating
behavior and state, which leaves many Java developers feeling like
they're programming COBOL.

Of course there are some exceptions (compilers). But most of the time I've seen code generated, it's because a person really didn't know how to solve it in any other way.

For example, generating getters and setters in Java vs. "free" getters and setters you get in Ruby. Or generating code for OR mapping, again, junk, in my opinion.

The only time it makes sense to generate code is when:

1. You are jumping a huge level of 10 of abstraction higher. For example, C generates ASM. I've used both, and C is miles and miles easier and higher level to write than ASM.

2. You will NEVER *return* back to the level of generated code abstraction. This means, once I use C, I pretty much never ever touch ASM again. In fact, many many people don't even know ASM, don't need to know it, and actually, could even *hurt* their ability to program effectively in higher level languages by knowing it.

This is never the case in web frameworks. For example, no matter how OO you get in your web framework, HTML+Javascript+CSS is not the same nice set of primitives as is ASM. You always have to go back to the level of HTML and CSS and Javascript, no matter what you say, no matter who you are.

Also, there is no significant jump in level of abstraction either. So the jump in level of abstraction is low, and the return back to the original level is pretty much guaranteed.

That means generation is flat out a *wrong* way to solve any problem in web development *right now*.

So, to all you generating fools, take this warning. :) And don't take it too seriously either. Don't burst a vein. It's just my 2c.