Thursday, July 22nd, 2010

Dojo 1.5 is Out and it’s Feature Packed!

Category: Dojo

The Dojo project continues to pump out goodness announcing version 1.5 of the Dojo Toolkit with a number of new and exciting features.

Dylan Schiemann had this to say about the release:

The JavaScript world is evolving at an intense pace. We’re very pleased with this release of Dojo, which offers the stability needed for existing apps and browsers, while introducing some of the capabilities of building great apps of the future.

Some of the biggest updates came to the Dijit UI library with the addition of the new Claro theme which helps provide a nice desktop look-and-feel to web applications as well as improvements to the charting and drawing components of the library.

And Dojo team lead Pete Higgins added:

If you haven’t seen the new theme Claro, you should. Julie Santilli and her awesome design team at IBM put some incredible design and style on top of an already stable and accessible UI library

The theme is incredibly clean. Check out some of the controls styled using Claro:




Other important updates include:

In addition, new initiatives are underway to provide solutions for the ever-growing and important mobile space:

This release continues the project’s philosophy of modularity allowing developers to leverage the library for anything from simple DOM manipulation to full-blown RIA development. Dojo 1.5 is immediately available for download and sports impressive, updated documentation to get you started quickly.

Posted by Rey Bango at 1:06 pm
60 Comments

+++--
3 rating from 6 votes

60 Comments

TrackBack URI

@Joeri

chill, it’s just javascript

Well, JS has the unique ability to make or break a Web presence, particularly these days with all of the new mobile users. And it’s not just for Websites these days either. You could argue it’s the most important programming language in use today. If only it wasn’t also the most misunderstood language as well.


Personally, I don’t get the knee-jerk outrage at any and all criticism of JS-based software (particularly open source efforts). I mean, did drivers of 70’s model Pintos rail against Mother Jones for warning about the potential of fiery explosions? Was Nader’s “Unsafe at any Speed” met with disapproval by anyone but automobile industry executives? It’s not that all of these juvenile responses were posted by would-be shills, but certainly those responsible are not thinking clearly.


And am I the only one who sees the irony in Dojo promoting a new “Promises-based” API? :)

Comment by DavidMark — July 25, 2010

@DavidMark

I’ll tell you what that quote says: “you are an imbecile”. You linked to a lone user submission instead of the Examples page

LOL, imbecile! Lets back track shall we. The link to the shoddy tabbed pane is actually on your examples page, on your site – where I took it from! That tells me your a cretin for not even knowing the content on your own site. But I forgive you your cretinous mistake, you must be in pain seeing the other js frameworks rolling out fully fledged ui libs when yours is floundering so bad.

Comment by SteveFDotNet — July 25, 2010

@SteveFDotNet

LOL, imbecile! Lets back track shall we.

Sigh, if we must. :)

The link to the shoddy tabbed pane is actually on your examples page, on your site – where I took it from!

First off, it’s not shoddy. I think the user did a good job on his example. Second, it is not on my Examples page, but linked from it. The Examples page has lots of examples of add-on widgets, including a tabstrip, but not that one as it is a user submission (which is clearly stated above the link to it).

That tells me your a cretin for not even knowing the content on your own site.

You have clearly misread something.

But I forgive you your cretinous mistake, you must be in pain seeing the other js frameworks rolling out fully fledged ui libs when yours is floundering so bad.

You are certainly full of misconceptions (among other things).

Comment by DavidMark — July 25, 2010

Sorry people I’ve got to agree with David Mark – this is not about who we like or don’t like, but about writing “Good Code” – solid, reliable code that doesn’t need constant maintenance when new browsers are released. If you read his comments (I mean really read them and study and understand the examples) – you’ll see he has multiple/valid points.

And I second his point on not using JS Toolkits/GUI libs – they’re a crutch – and eventually this crutch will break and you will fall. They lock you in to what they support and how they work.

We use JQuery on our website (against my recommendation) for fading three images in/out… so thats 80k of js lib + another network request… just for one effect, which could have been written in a few lines of code (and I did).

Comment by wukfit — July 26, 2010

Sorry people I’ve got to agree with David Mark – this is not about who we like or don’t like, but about writing “Good Code” – solid, reliable code that doesn’t need constant maintenance when new browsers are released. If you read his comments (I mean really read them and study and understand the examples) – you’ll see he has multiple/valid points.

And I second his point on not using JS Toolkits/GUI libs – they’re a crutch – and eventually this crutch will break and you will fall. They lock you in to what they support and how they work.

We use JQuery on our website (against my recommendation) for fading three images in/out… so thats 80k of js lib + another network request… just for one effect, which could have been written in a few lines of code (and I did).

Comment by wukfit — July 26, 2010

…and you might want to fix being able to click the submit button multiple times – hence I’ve managed to double post.

Comment by wukfit — July 26, 2010

Those of you dismissing David Mark out of distaste for his style are being foolish: read his technical points, do a little research to see if he’s correct. You don’t have to like him.

Is anyone going to tell me what exactly is wrong with the tabbed pane example linked to earlier in the thread?

Comment by timdown — July 26, 2010

Appallingly, this is from the Dojo trunk:-

dojo["eval"] = function(/*String*/ scriptFragment){
// summary:
// A legacy method created for use exclusively by internal Dojo methods. Do not use
// this method directly, the behavior of this eval will differ from the normal
// browser eval.
// description:
// Placed in a separate function to minimize size of trapped
// exceptions. Calling eval() directly from some other scope may
// complicate tracebacks on some platforms.
// returns:
// The result of the evaluation. Often `undefined`
return d.global.eval ? d.global.eval(scriptFragment) : eval(scriptFragment); // Object
}


First of all, that warning about being a “legacy method” and “exclusively for use by internal Dojo methods” is new and apparently the “solution” that was arrived at in light of my criticism (and subsequent rewrite) of this method last Fall. Of course, it’s no solution at all as the problem is with the logic (which no comment will fix) and the critical bits of the low-level Dojo code that call this method.

Furthermore, the comment that the behavior will differ from the normal “browser eval” is false (in more ways than one). What they meant to say was that the eval function that is built in to the language by specification and provided to all host environments (including browsers) may differ from that of this method. That distinction, in and of itself, is a serious problem for an ostensibly cross-browser script that also claims to work in environments other than browsers.

And, last but not least, they removed the description of what this function is expected to do (to avoid future embarrassment I suppose). Since the beginning, this method has been advertised to evaluate a script fragment in the global scope. But one look at that ternary operation should make it clear that it does nothing of the sort.

And, of course, like many other “major” libraries, Dojo conflates the term “scope” to refer to the – this – keyword, so it’s hard to say whether the original developers (and all who have come after) were trying to limit the scope chain, set the this keyword or both. In any event, the single line of code reveals that they failed to do that in any sort of consistent fashion.


The dojo.global property is typically set to reference a window object. In some environments, calling eval as a method of the window object will indeed evaluate the passed script in the global scope and set the this keyword to the Global Object. But clearly at some point in the development of Dojo, its authors observed a deviation from this non-standard behavior (which would certainly be something to expect from a method with no formal specification). The “solution” was to add a fallback to call the “browser eval” directly. The implications of such a hasty patch-by-observation should be clear: in some environments the method would work as “expected” and in others it would not as a direct call to eval uses the scope and this object associated with the current execution context. In this case, the scope chain would include all of the Dojo bootstrap, which includes hundreds of identifiers and the this object would reference the dojo object.

So, as context is always the key to these problems, and as with the type-checking methods, I looked at what the higher-level code was trying to do with this method. It turned out that 99% of the time the caller discarded the result of the evaluation, which allowed for the use of the Function constructor. Combined with moving the declaration of the method to the global scope (outside of the anonymous one-off function found in the bootstrap module) and eliminating named arguments solved the problem:-



dojo['eval'] = function() {
return (new Function(arguments[0]))();
};

It’s mot quite global scope as there is still a local activation object with an – arguments – identifier, but it was close enough for the context in which it was used.

To cover the remaining 1% of cases where the method needed to return the result of the evaluation, I recommended adding a second function. However, to preserve backward compatibility, I simply specified an optional second argument:-



dojo['eval'] = function() {
if (arguments[1]) {
return eval(arguments[0]);
}
return (new Function(arguments[0]))();
};

And in these handful of other cases, I changed the calls to look like this:-



var dojoEval = dojo['eval'];

dojoEval(scriptFragment, true);


…hence setting the this object to reference the Global Object.

That was that (or so I thought). As this one-liner is one of the first methods created by Dojo, I decided to open my discussions with the secondary contributors (I already had the blessings of the primaries) with this method. What could be simpler? As an omen of things to come, and as preserved in the Dojo developer mailing list archive, my assertion that the original dojo.eval was faulty was met with howls of derision and calls of “show me where it fails” (as if logic must demonstrably fail to be incorrect). Furthermore, one major contributor opined that he couldn’t imagine that Dojo used eval for anything “important”.

Long story short (too late), I pointed out that the much-ballyhooed loader used this method to evaluate Dojo modules (as well as the very obviously fractured logic). Nearly a year later, you can see the result (a few modifications to the comments, which still don’t make any real sense). Why wouldn’t they have changed this criticial one-liner? Apathy? Spite? Who knows, but their inaction speaks volumes.

So it doesn’t really matter how many widgets or themes they cram into the archive. The bottom line for those choosing a framework to alleviate the rigors of cross-browser scripting is that the authors of this thing do not understand the language they are using and apparently have a hard time grasping very basic logic. The idea that such authors would be capable of writing a “full-fledged” application framework in anything but an incompetent manner is beyond ludicrous and abdicating responsibility to such authors can only be considered career suicide.


Furthermore, despite various odd remarks here to the contrary, I don’t issue such warnings out of “jealousy” (there’s nothing to be jealous of). On the contrary, the more people who use such scripts the better for me. After all, I’m in the business of bailing people out of jams that often result in the use of such dubious front-end software. Dojo has been a specialty ever since I rewrote the silly thing (I still have the branch and refer to it almost daily). If you have inherited a Dojo project or are otherwise stuck with it, drop me a line. If not, I truly hope you have paid attention here and I won’t be seeing you as a client in the future (at least not related to Dojo). :)

Comment by DavidMark — July 26, 2010

@timdown

Those of you dismissing David Mark out of distaste for his style are being foolish: read his technical points, do a little research to see if he’s correct. You don’t have to like him.


Thanks Tim. Though it would be nice to be liked. :) Of course, if you ask anyone who has actually worked with (or for) me, clients, etc. you will find I am almost universally well-liked. The typical exceptions are groups of open source developers with ego and/or confidence issues. They don’t seem to respond to my brand of motivation (much to their detriment as evidenced here).

Is anyone going to tell me what exactly is wrong with the tabbed pane example linked to earlier in the thread?


Not a damned thing. Ethan did a great job, writing the entire widget from “scratch” (using the My Library API of course). It looks nice and works well (or degrades gracefully) in virtually every environment (and I helped him test a lot of them).


Like the article it was based on, it is an outstanding example of cross-browser progressive enhancement, which is completely impossible to do with multi-browser sniffing frameworks like Dojo (because there is no way to know in advance which methods will work in the current environment).


I think he made one very minor adjustment to the CSS after I copied it to my server though (single-pixel Opera issue IIRC). I’ll see about grabbing his latest version later today…

Comment by DavidMark — July 26, 2010

This particular discussion is closed.

Comment by jvaughan — July 26, 2010

Sorry, the comment form is closed at this time.