Game over. We lost. Nothing to see here, move along.

Nigel Rantor wiggly at wiggly.org
Fri Nov 18 13:19:11 GMT 2005


Ben Evans wrote:
> In short - nothing that wasn't already part of the dev experience in 2001-2.
> 
> The caveats are pretty obvious: Sybase is nasty, Catalyst is not Maypole, etc.
> 
> But I'm getting pretty close to just jacking it all in and recommending JSP
> for all future web development. The learning curve will be steeper to begin
> with, but in the end, there are more resources, more support and the key 
> risk to projects I'm on will be much less.

Hi all,

*back-ported thought* This is turning into a bit of a rant, oops...

JSP isn't all it's cracked up to be. If that is too blindingly obvious 
and pat an answer then I'm sorry.

It may have something to do with the fact that the reference stack Sun 
touts (because someone took the work off their hands perhaps) isn't 
really very polished, but then, you can only polish a turd so much.

The Apache folk are great, don't get me wrong, the spec is just as much 
of a problem as the fact that they're perfectionists and keep re-writing 
the engines in the vain hope that one day they'll find the right 
combination to make the JSP spec sing and dance at the same time.

I think the JSP model is fundamentally weak, and the only way I can 
manage to explain this to myself is that JSP was a knee-jerk reaction 
from Sun to the success of ASP. Once again, if this is all too obvious I 
apologise. It seems to me though that the JSP spec was never really 
thought through by anyone who had to create _and_ run a website.

I've tried looking into frameworks that sit on top of JSP like Cocoon. 
In fact, cocoon is a great example. It looks great, sounds great but 
when it takes hours (yes, hours) to build on a not-half-decent machine I 
start to get afraid that the amount of framework is less like 
scaffolding a more like a few buildings welded together.

After spending many hours looking at cocoon and playing with it I came 
to the conclusion that it wasn't worth the time and energy. In the same 
way as Rails (I have no experience of Django/Catalyst/Other) enforces a 
certain way of doing things so did cocoon, except there were about 4-7 
different ways, not all orthogonal with each other, not all tested very 
well, not all production ready.

I think they got confused by the flexibility issue. At some point a 
system ceases to be "flexible" and suddenly becomes a programming 
language (TT/Postscript), shell (emacs anyone?) and suddenly you have to 
do a lot more work to point it in the direction you want to go. Rails is 
focused, it knows where it's going, and it pulls you along with it 
rather than making you get out and push.

I decided to get out of the $website gig ages ago for a number of 
reasons. Mainly the interesting programming for me was in the back-end 
rather than either having to learn Vignette or go and build YACMS from 
scratch.

Now that I want to do some more serious things on my own I keep looking 
for something decent to use, as of right now there is nothing. I am 
playing with Rails but I'm not yet ready to say I'm convinced.

I quite agree with a lot of the discussion here, Perl and CPAN are 
double-edged swords. That is one of the main reasons Cocoon left such a 
bad taste in my mouth. At the end of the day it comes down to design and 
architecture, since we are talking about frameworks.

Rails _has_ one.

JSP may as well not.

Cocoon has too many competing ones.

If any framework is going to succeed then it needs a clear architecture. 
If you find yourself spending too long describing it to someone then 
you've lost. At any level of detail people can only deal with so many 
concepts, frameworks shoudl provide stratification that doesn't need to 
be inspected at all unless you *want* to.

I may spend some time looking into Catalyst over the next few days, or I 
might just play with Rails some more now I have a chunk of time.

   n



More information about the london.pm mailing list