Javascript framework pile on

Dr Dobbs has a review of Javascript frameworks, which they call “AJAX frameworks”, that’s an interesting read in my opinion.

I’m not going to write about Javascript frameworks in this article (one huge article a week is draining enough and writing and responding to the fallout would take forever to write). Instead I’m going to single out Alex’s complaint: the article used an ancient version of Dojo Toolkit.

[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).

I believe this even though I’ve gone on record of saying that YUI is my favorite javascript framework. Must…resist…urge…must…remain…calm.

(Wheew!. I almost had a “Hulk smash!” Javascript framework digression.)

The article is actually excellent. Here is what I got from the article:

  • There are a lot of javascript frameworks out there.
  • 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.)
  • Due to segmentation of talents (in particular graphic designers/css dude, and Javascript/Java developers), they found the Dojo structure harder to work with than Prototype or YUI.
  • 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:

Perhaps there isn’t one true Javascript framework—one framework to rule them all. (Though if there was, it’d probably be Dojo.)

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.)

3 thoughts on “Javascript framework pile on

  1. I think the article was a bit mis-marketed as a review of the frameworks. It was really more of a case study in tool evaluation, and was quite good in that regard.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.