[The validity of complaints after the jump.]
Alex, to his credit, later corrected the post when he was informed that DDJ has enormous lead times on their stories. I’m not here to fault him for his post, because I guarantee if it were my stuff that DDJ was pissing on, I’d give them some of that “vintage tychay” with a few choice ad hominems I’ve been saving up for just such an occasion.
Instead, I’m here to criticize the belief that “magazine lead time” makes for a valid defense. This is a poor idea because it leads to conclusions like the “whole article is somewhat futile” since all the versions are outdated from the ones reviewed.
I am reminded by what a former U.S. Secretary of Defense observed about frameworks:
“As you know, you launch a website with the framework you have. It’s not the framework you might have want or wish to have at a later time.”
Okay, he didn’t actually say that. And, in fact, the real quote is generally used to show great insensitivity when what I’m going to advocate is the opposite: being sensitive to the “facts on the ground.” (I’m just going to do this in an insensitive manner.)
What I got
Doesn’t that mean I should still ignore the DDJ article?
If the only thing you drew from the DDJ article is “YUI good. All other frameworks bad.” Then, Thag, I would say it’d be best to ignore DDJ article. Stick to reinventing the wheel (or just venting).
The article is actually excellent. Here is what I got from the article:
- DWR and Google WebToolkit were eliminated because of the tight binding with custom Java APIs would require a re-architecture.
- Dojo was easily the most fully featured, most customizable, and had a built-in UI solution to their problem.
- Prototype had to be compressed (not a big deal because these are Java guys who know how to use Rhino).
- The Dojo footprint was huge. (I’m a little surprised that they couldn’t custom build Dojo to get it much smaller.)
- YUI was completely documented. Prototype and Dojo were not.
So, instead of marking the whole thing as worthless because new versions are out. If they had to do the same problem now, they’d simply just update their matrix and choose the highest rated one.
(BTW, I found that part of the article a tad… weird. I wonder if this is how they pick out who they’re going to date.)
The reality is, they won’t. Why? Because it’s a framework and once you choose it, you eat it—all of it. That’s why good software engineers like them spends all this time up-front trying to making these decisions, because they pay for that decision down-the-road for the rest of the application lifecycle.
(Yes, I’m calling you out all my buddies at Plaxo who overrode me. 🙂 Cassandra-Polyanna and all that. Now is the time in sprockets when I gloat. j/k.)
A mind blowing concept
Here is a quote a want front-end developers to live by:
When I first skimmed the article a couple days ago, I thought, Wow, given their background as Java devs for a Fortune 500, I’d have thought they’d have cummed all over Dojo.
(A bit crude, I know. But in my defense I had accidentally clicked on a Something Awful link earlier that day and……well let’s just say I’m telling you not to click on that link; they’re going to say not to click on the link; you’re still going to click on the link.)
Back to the point. Why didn’t they use Dojo?
(Because I missed the fact that apparently “thousands of users an hour” can cause a severe performance bottleneck in their application server? 😀 Okay, I know, I can’t help myself. I can’t pass up an opportunity to make fun of a Java Developer. It’s all in good fun.)
Truth be told, it’s because their development team was segmented in a manner that made Dojo particularly hard to work with.
(And also, apparently, T. Rowe Price, a financial services firm, doesn’t save people enough to afford themselves some broadband. Yeah, I’m still debating whether this is a bad thing (can’t get their finances in order enough to spend $30/month) or a good thing (frugal with their money, these millionaires-next-door will own my ass when they retire).)
That’s what I meant when I said the tongue-in-cheek “facts on the ground.” Each situation is different and what will cause you to choose one framework for one situation might cause a different framework choice for another…or maybe even no framework at all.
Nobody is holding a gun to your head saying you have to use any of these things.
(But I pretty much guarantee that if you are a front-end web developer, living in ignorance of these things is going to make your life miserable.)