maybe ill take a look at dojo in future :]

Getting animation toggles working correctly is one of the last things that slipped into 0.9 final from beta. It’ll be there. You can track the progress here: http://trac.dojotoolkit.org/ticket/3641

Regards

http://dojotoolkit.org/book/dojo-porting-guide-0-4-x-0-9/io-transports-ajax

It looks like the sections in the Dojo Book are not there yet for this, but also the book is focusing more on use case approaches than simply listing out the features Dojo provides. Note also that xhrGet and xhrPost are a part of the Dojo Base, while other transports are part of the Dojo Core (this means that when you use the built version of Dojo, you don’t need to do anything to use xhrGet/xhrPost, but you do need to dojo.require other transports).

It’s by no means complete, and feedback is most welcome, but it should outline some of the major selling points of Dojo and where our focus differs from that of other libraries.

http://download.dojotoolkit.org/release-0.9.0beta/dojo-0.9.0beta/dijit/tests/test_TitlePane.html

now doubleclick fast on the pane , it will get broken and not wipe out and in correctly then.

Guys i have spend over 3 months developing on dojo, and i think its a great promising platform , but please focus on fundamental things like animation package, what good is it when it gets easly broken, and all the plugins that depend on those function too.

How can i rely on a framework library that does not fix bugs like that in half a year ? I wish i could use it and depend on it in my work. But this simply is not possible right now, ive tried YUI later and never ever had a problem with it, im pretty confident you can do the same ;-) just do it :]

Good Luck

Marcin

As with 0.4.x, your build determines the number of files fetched. We provide the tools you need to tune your site however you wish.

As for a11y, we’re working with folks who are in nearly constant communication w/ the a11y tech vendors. We can indeed inform the browser when things update (see http://developer.mozilla.org/en/docs/AJAX:WAI_ARIA_Live_Regions), and our components are being actively hinted with not only keyboard and high-contrast mode defaults, but also WAI ARIA roles and states. Using a Dojo ContentPane to pull in content from a URL will flag to a reader that the contents have changed and when you tab to focus on it, you’ll know what you’re looking at.

As with everything else web-related these days, we’re done waiting for Microsoft to take a leadership position on these issues. Give the ARIA stuff a look, I think you’ll be pleasantly surprised at how far the Open Web can go in making accessible interfaces today.

Regards

For performance it’s not just file size that counts but number of objects. Given that you can only open 2 sockets to any server at a time in a Browser, downloading 25 or 50 js files onLoad makes latency a real issue. I understand that .9 will fix some of this.

While screenreaders and other assistive technology may now be able to read widgets, they still won’t know when you’ve updated one of those widgets with a fancy DHTML effect. That technology is a couple years away and doesn’t have full support by Microsoft yet. This is a problem with DHTML, which everyone calls Ajax, and not just Dojo.

The api docs and manual for Dojo are unusable as is – any improvements here are welcome. Despite dojo being open source and written in javascript – using it is still a little like black-box programming. Who the heck knows what dojo is doing to your DOM – good luck debugging! Improvements in documentation would be very nice.

We tried the losely-bound method before, but what happens is that instead of everything relying on just one thing, everything winds up relying on *everything else*. The resulting packages and builds are rambling and from a process perspective, no one feels responsibility for the size of the system as a whole. We’ve solved the social and technical issues at once by setting a hard size limit for Base and fitting as much functionality as we possibly can in that budget. The rest of Dojo code no longer has to feel slightly guilty for requiring other modules…almost everything other systems need is in Base. From JSON to Deferreds to Ajax to the parser to the event system to HTML and style utilities to pub/sub notification to the package system, nearly everything many of those modules were previously including manually is under one (highly curated) roof. If it’s not there, there’s a reason, and if it’s there, you probably need it in a non-trivial app.

Regards

scriptor – Load time numbers are nice, but there a lot of variables (location, connection speed, etc). Size, esp within the context of previous version weight, is a nice consistent metric that doesnt require much explanation.

As for the question about splitting up the base, you need to find a balance between throughput and latency, and Dojo does a very nice job of that. If you trim down base too much, you are making a number of round trips to the server to pull in subsequent libraries. Even with all the nice XHR work to make those fetches non-blocking, the latency of waiting for those libraries to load can kill your user experience.