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