Monday, April 30th, 2007

Dojo 0.9: A new, leaner, meaner Dojo

Category: Dojo

<p>There has been a ton of work going on over in Dojo land, and Alex has given his hands a rest from coding, to give us an update on Dojo 0.9 over at SitePen HQ.

It is wrong to think of Dojo as an Ajax toolkit. It is more akin to a stdlib for JavaScript, as it is so many modules that are very broad indeed.

That being said, there has been a push to make Dojo even more pragmatic, lean, and fast. It is great to see the new course of action:

Early this year it became clear that for folks building Dojo apps, the question of “what is Dojo?” was becoming increasingly hard to answer. Each individual user might be working with a different subset and therefore they don’t share a common definition, which makes sharing what you know about the system harder than it needs to be.

In response, we’re in the middle of a huge undertaking: rethink the entire API surface area of Dojo from the ground up and split it up into 3 different top-level projects. With R&D dollars and time coming from all corners of the Dojo universe, 0.9 is shaping up to be smaller, faster, more coherent, and easier to understand.

What this means is:

  • Dojo Base: This new core is aiming at 50k (< 20k gz), and will contain “things like dojo.query(), dojo.connect(), the package system, style and DOM manipulation functions, ajax, and a small-but-flexible animation system.” An important change is that there will be only one dojo.js per version, unlike now, where you can build your own dojo.js files, or choose a set packaged version.
  • Dijit: The new widget system will be its own package. “The Dijit team is working on a set of consistent, themed, localized, and accessible widgets that not only improve on the usability of the existing widget set, but will also provide huge performance improvements in declaring and constructing widgets in a page.”

The Dojo team is already seeing fruits of their labors with performance improvements, even before they have done the final tweaks.

In the future, I hope for a world where a lot of these libraries will Just Be There, so you won’t have to have the same size worries, and instead we will be able to focus on speed, and other issues. When you look at most popular libraries, the reason they are popular is often to do with the libraries that you have access too (e.g. CPAN).

Related Content:

  • EGL Rich UI on IBM i: Do you Dojo?
    Taking advantage of the Rich UI features of EGL architecture on the AS/400 can save you time and complexity. Rich internet applications can be...

Posted by Dion Almaer at 12:29 am
16 Comments

+++--
3.7 rating from 66 votes

16 Comments »

Comments feed TrackBack URI

Nice. Then we can use Dojo to create widgets for http://www.widgetplus.com ..
There’s also a contest on at http://www.xindesk.com/blog and the first prize is a iPod shuffle, suggesting the coolest widget idea..

Comment by mikael bergkvist — April 30, 2007

One thing I’d like to see more of is JS projects hosting their own libraries like what Yahoo has done. If they could host them over SSL that would be a bonus too.

The reason I like this is that if each version of the library has a unique URL the browser can be made to cache a single copy of the file for a long period of time. This means the file is downloaded once and used with multiple sites… the user only has to wait for the download the very first time their browser sees it.

I love that library sizes are being kept to a minimum, but I think if libraries were centralized and reused it might not be as large of a concern.

Comment by Dan — April 30, 2007

While it’d be nice to be able to cache a single copy of a library, that would make each applications uptime dependent on the uptime of the library host. For my own app I’d rather keep fewer links in the chain, after all, what client is going to accept “I’m sorry you can’t use the service you’re paying me for… [Toolkit X]‘s site is down”?

Comment by Richard Marr — April 30, 2007

>>One thing I’d like to see more of is JS projects hosting their own libraries … This means the file is downloaded once and used with multiple sites… the user only has to wait for the download the very first time their browser sees it.

mikael – Dojo itself isn’t hosting their libraries. But AOL is providing it via their CDN…Ajaxian wrote about it back in January and November. Kinda makes more sense since companies like AOL have the high-scale hosting infrastructure and Dojo foundation doesn’t.

http://dojotoolkit.org/dojo-0-4-2
http://ajaxian.com/archives/including-dojo-via-the-aol-cdn
http://ajaxian.com/archives/hosting-javascript-on-cdns-aol-announces-the-hosting-of-dojo
http://dev.aol.com/dojo

In addition to the caching benefits you mentioned…linking to the dojo libraries in this way also saves you from bandwidth costs. One obvious downside – this won’t work if you are using your own Dojo custom-build…

Comment by fwong — April 30, 2007

@Dan:

Actually dojo already a centralized hosting (provided by AOL):
http://dev.aol.com/dojo

But I tend to agree with Richard: I’d hate to rely on some other site.

What would be very cool would be some sort of failover mechanism so if the central site is not available, it gets the libraries locally.

Comment by Patrick Fitzgerald — April 30, 2007

You could just put the library up on your free google pages account. I’m not sure what level of availability they use for those accounts, but it’s an option.

Comment by Gerald Fitzpatrick — April 30, 2007

In my own experience, i have found dojo totaly useless.
Devels are ignoring opera (it has ~2% official market share … imo ~5%), as if it will go away if they dig theit heads in sand.

Comment by mefisto — April 30, 2007

I have to agree with mefisto. Opera is a first-class web browser, and so is Konquerer. The Dojo website says they’re dropping support for both browsers “because they just don’t have a big enough install base to warrant our time supporting (coding and testing) them, nor do we want to increase code size/complexity in order to support those browsers…” That’s a cop-out, entirely. YUI, Prototype, jQuery, Ext, and many other fine JavaScript libraries have no trouble supporting those browsers, and this step forces me to lower my view of Dojo from an “A” in cross-browser, cross-platform support to a “B.” (If I ever find the time to update my Ajax scorecard, that is…) With so many “A” browsers available, I think Dojo is getting ahead of itself to think they can take shortcuts like this.

Further, the same Dojo page, which gives an overview of Dijit, makes a mindbogglingly dumb statement about WebKit, leading me to question Dojo’s commitment to that platform as well:

Before Dijit is released, Webkit will be released and pushed to all macs, or so I am told.

How can someone responsible for a project as important as Dijit not be technically conversant about WebKit? WebKit is already–and has always been–a part of Safari. WebKit is the core of Safari… it’s the HTML and JavaScript rendering/parsing engine for Safari… and new builds of WebKit are “pushed to all macs” regularly with new builds of Mac OS X (I’m talking about the point releases here, not the major ones… and no, 10.4 is not a point release… 10.4.9 is). Further, any Mac user today can download WebKit and run it inside Safari, taking full advantage of the advances in JavaScript and CSS that the newer builds off. They don’t have to wait to have it pushed to them.

One last concern I have with Dojo is that the current rich text editing widget (editor2) has, for about a year, contained a bug that keeps it from working in Safari when instantiated within a field. This bug persists even in the latest builds of WebKit and Safari 3.0 (for Leopard), which now have full, stable support for the contentEditable property. So what gives here? Why hasn’t this bug been fixed by now? In December 2005, I selected the Dojo editor for my organization precisely because it had full cross-browser support when few did. Now I’m probably going to guide us to TinyMCE or some other editor that actually works in Safari.

Alex, where are you? Dojo was so great!

Sadly,
Leland

Comment by Leland Scott — April 30, 2007

@Leland: dropping Opera and Konqueror support in Dijit is still very much being debated, so don’t take that as gospel. Note the emphasis; Dojo itself (Dijit is NOT Dojo) supports both Opera and Konqueror in full. There are a number of bugs in Opera that are causing the Dijit team not only major headaches but also causing an excessive amount of bloat–but that doesn’t mean it will go unsupported. In fact, I’m sure this will be a topic of debate at the upcoming DDD/NY.
Also, I’m pretty sure Bill was referring to the WebKit nightlies when he says “WebKit”; many people tend to think of released versions as Safari and under-dev versions as WebKit, even though you are very much correct in saying they are one and the same.
Lastly, can you file a bug against the Editor? One of the issues with it is that the main developer of it right now does not work or have access to Safari, and probably isn’t aware of the problem.

Comment by Tom Trenka — April 30, 2007

Leland, mefisto:

First, please don’t invent malice where none is intended. It might make for a good story arc, but it doesn’t help any of us get the right answer.

Leland, you and I have discussed Dojo’s Safari support at length in the past and the only thing that has changed to date is that time has passed and that we’re setting the bar higher for ourselves. The current *shipping* version of Safari, for rich text editing, is both so slow as to be unusable and so buggy as to be pointless. The Safari/Webkit devs have spent a great deal of time improving this and it really shows in the webkit nightlies. We added the fixes needed to make our editor work there *last year*, and we’re continuing to track that development and ensure that everything else works as well. For instance, we’re ensuring that dojo.gfx works on Webkit Nightlies despite the fact that there’s no official ship date for that browser. And of course, we support that kind of bleeding-edge feature in Opera already.

Our browser support policy has always been “latest Safari, latest Opera”, and while the widget system hackers are pulling their hair out trying to make accessible widgets in Opera, the system does everything short of that quite well indeed. What the widget team *isn’t* committing to right now (and this is still up for discussion) is saying that we’ll have 100% feature support (mostly a11y related) for Opera. Please note that what we’re saying here is that we’re gunning for something that other toolkits aren’t even promising today and that we’re encountering critical bugs in reaching *that* goal in Opera. Will things work there in general? Of course. I’m still pressing the case with that team that 100% support is an important goal, but we have to ship and our resources are constrained. We’ll be revisiting this discussion SRTL, and you are always invited to get involved in the discussion and help us by submitting patches and test cases. We do everything in the open.

As for Core, we’re testing on Opera and Safari on a daily basis. They are certainly first-class citizens, despite their relatively minor desktop market share. Webkit seems to be winning the marketshare race on smartphone platforms, so we’re actually testing Core there as well.

As for thenote regarding the webkit nightlies (taken out of context and misinterpreted), we’ll be presenting at WWDC on some of the new webkit features that we’re *already* supporting. The discussion about whether or not to try to backport things for Safari 2.0.4 is a calculation that revolves around our anticipated ship dates and when Apple had said their next OS version would be available (which we are anticipating will include an updated webkit). This is a question about what “latest Safari” means given those timelines. Not a question of whether or not features will be supported on Safari.

Choosing to cast our browser support goals in a poor light is clearly your choice, but I suggest that it’s not representative of reality nor does it reflect well on you.

Regards

Comment by Alex Russell — April 30, 2007

Hi guys,

Yup, I meant that Dijit won’t support Safari 2.0.4, but rather we’ll support the Safari that will be released imminently (or so I am told).

About Opera – we can certainly revisit that after the 0.9 release. But I needed the Dijit spec to be clear about what Dijit 0.9 supports (that is the purpose of a spec, after all; it’s like a contract), and for 0.9 we won’t have time to test and fix Opera (on Konqueror) issues.

There’s also a lot of other things we aren’t supporting (or at least not testing), like FF1.5, IE5.5, Mozilla, mobile devices. Just a question of time and resources.

Bill

Comment by Bill Keese — April 30, 2007

Yep. In the handy, small JS libraries category, I think jQuery takes it hands down. (If I want to go fancy, I can use GWT or something.)

Comment by Tom Palmer — April 30, 2007

I think Dojo should concentrate more on their core assets which is their widget library. And I do mean the library, not the framework. The framework is already first class to none, but some of their simpler widgets lack the final polish. After all, their widget library is considered a competitive advantage over jQuery and MochiKit.

Comment by Nathar Leichoz — May 1, 2007

Alex/Tom,
I really didn’t mean to get your back up, but the information on Dojo’s Diji overview (which I did not take out of context, by the way… follow the link and see for yourself) definitely did get my back up. “To every action, there’s an equal and opposite reaction…” a law of nature, I guess, eh?

One of the reasons this bugged me so much this week is that I’ve been patiently waiting for Dojo to fix a persistent bug in the rich text editor (editor 2) for more than a year now. I’m working this week to upgrade the wiki code I had embedded Dojo’s editor into, and finding that for some reason the original version 1 editor no longer works. In fact, it’s also broken in IE and Firefox. I was hoping to build editor2 into it instead, but now… Tom, you suggested I submit a bug report. In fact, there has been one on the Trac there for a full year… See See Ticket #377. Last action was to assign the bug to Alex.

At the very least, if you can’t get editor2 working in Safari, you could code the widget to degrade gracefully to the previous version, since that one did work in a textarea in Safari. And you’re absolutely wrong about Safari 2.0 being slow and buggy… it’s far from that, which you’d know if you used it on a daily basis. (If it slows down, Safari usually just needs to have its cache emptied, which is easy to do: “Safari/Empty Cache”) That characterization is just a way of rationalizing not including it in Dojo’s coverage, which just feeds my suspicion about the direction Dojo has been taking with respect to the dominant Mac OS X browser platform.

Leaving Dijit aside, if you’re not supporting Safari 2.x in the current shipping version of Dojo (as you say you are in your browser support page), you really should change that statement, which would (for what it’s worth) lower Dojo’s cross-browser rating, which I’d previously scored as an “A”. And no, I’m not planning to post any articles about this… but I did want to get your attention.

Unfortunately, as a minority platform, it takes loudmouths like me to ensure support for our favorite browser. Whereas Windows users of the incredibly buggy, slow, and non-standards-compliant IE 6.x (still accounting for an ungodly share of the market) don’t have to worry that developers will bend way over backward to accommodate its quirks. In comparison with the quirks in IE 6 (and probably 7, since I gather its CSS support is still very poor), those in Safari and Opera are quite tame. But they do require that the Dojo team include someone, for example, (a) with a Mac OS X system and (b) running Safari 2.x daily with the latest builds and addressing bugs. I wouldn’t imagine finding someone like that would be too hard these days.

Comment by Leland Scott — May 1, 2007

Leland–
Thanks for pointing out the ticket. I’ll point the Editor2 dev at it today (or tomorrow, depending, he’s halfway around the world). Regarding Safari, you should probably know that a good portion of the Dojo team (Alex, me, Dylan, Dustin, etc. etc. etc.) all work on MacBook Pros; I won’t speak for any others but I happen to love the latest WebKit nightlies. In fact, they had contacted us about the Dojo Charting engine breaking in some of the nightlies, and fixed it very fast–and frankly their SVG rendering speed is hands down the fastest out there right now.
Saf 2 is definitely supported by Dojo; it’s the Dijit team that is looking to minimize some work and worries. One of the big problems with Safari (IIRC) is that its JS engine simply can’t handle some of the amount of code other browsers can…anyways, Dojo itself supports Safari 2 and will probably run just fine in Safari 1 (though I’d have to double check that). Your concerns are really about the Dijit project, I think…which is totally understandable. As Alex mentioned, there are some other requirements driving that project, some of which are pretty difficult to do with Saf 2 and Opera (at least that’s what I’m told)…but feedback is good, and thank you for that. And don’t stop!

Comment by Tom Trenka — May 1, 2007

I’m just curios, can somebody tell me whats the problem with Opera? What other libraries can i consider for widgets? I tried dojo today but it appeard to many bugs, so it need som polishing before I can take it serious.

Comment by Ivar — May 2, 2007

Leave a comment

You must be logged in to post a comment.