If you have a better way of doing things that I actually believe is better then I’d certainly heavily debate either dropping everything I’m doing right now or trying to find a way to make it happen in projects I already work on. That’s what I did while using prototype and found dojo. I hope that clears up any thoughts you had about me having “fan syndrome” ;)

Regards

Because I know I can use it without any tooling at all during development quite happily it doesn’t raise any obvious flags for me…Everything beyond that point is just “icing”.

As for being opposed to the use of java in tooling, I guess I sort of understand the current trend in not liking it….People started turning against c++ a long time ago too, but more than likely it’s still running the browser you are reading this thread in right now.,.

Best,
Brad

dojo.event – Dojo’s event system, which allows me to do one line to subscribe to events: dojo.event.connect(myElem, “onclick”, this, this._myElemClicked)

Dojo internally normalizes the event object cross browser, handles memory leak issues on IE, and more – this one line vastly simplifies my code and makes it more robust

dojo.string – simple string handling methods that JavaScript forgot or that you have to roll yourself, such as dojo.string.trim(), dojo.string.startsWith(), etc. I usually have to hand roll these myself, so why not just use Dojo’s battle-tested and performant versions?

dojo.html – methods when working with HTML and style classes, such as dojo.html.hasClass(), dojo.html.addClass(), etc. Most developers forget that elements can have multiple classes, and create code like this:

if(someElem.className == “foobar”)

then, they wonder why their code doesn’t work, because someElem might also have the class “important”. Dojo’s class methods solve this:

if(dojo.html.hasClass(someElem, “foobar”))

again, this is not bloated; if you didn’t have these you’d have to roll them yourself, which I’ve done countless times. And if you don’t have them, then your producing incorrect code that will fall over…

dojo.io – A layer over XHR to account for it’s browser differences; again, this is very easy to use:

dojo.io.bind({ url: “http://foobar.com”,
mimetype: “text/xml”,
error: function(type, errObj){ /* error function here */ },
load: function(type, data, evt){ /* load function here */ });

Now, Dojo IO takes care of papering over important browser bugs (like how IE doesn’t actually displatch your GET request if it has the same URL as one it’s done before, handing it from the cache incorrectly instead); handing you back XML if you have text/XML as your MIME type in a cross browser way, etc.

None of this looks bloated to me; in fact, it’s thing I have to create myself usually. What it DOES do is make your code cleaner and more focused on the application rather than browser hacks. My code now actually reads like the processes it’s trying to do, rather than boiler plate junk. Plus, using the above is pretty easy. I’m not sure why people say Dojo is hard; I think what it is is you have to know basic JavaScript. Folks don’t want to take 20 minutes to read an intro to JavaScript article before hacking on Ajax.

Dojo does have more experimental and interesting ‘slices’, such as my Dojo.Storage and the Dojo Widgets, but you DON’T HAVE TO USE THEM. That’s the most important thing that seems to get lost on people; each slice is a seperate package, just like a Java Package, and if you don’t want it DON’T IMPORT IT. Sorry for the caps but I’m getting tired of this same argument…. :)

Best,
Brad

It seems pretty clear that you’re not spending much time with Dojo. What “scaffolding” exists is entirely in the widget system, which is entirely optiona, and even that is over-rideable at every point. Anyway, I’d like to know more about what “dangerous concepts” you think we’re exposing. You’ve said as much a couple of times without outlining what they are. Is is that we provide an (entirely optional) topic-based event system? Or is it something else?

As for XSLT, yes, we’ve considered it, but we already have a system that allows you to send down just HTML snippets (widget templates) and instantiate them at-will. Perhaps providing XSLT for those comfortable with it would be a win, but that’s a pretty small group of people compared with those who can write HTML and CSS.

Regards

My main hope now is that the Dojo project focuses on making these tools easy and accessible to the general Ajax community, because I fear that at present many still consider it a black art (though I realise the Dojo team may have different objectives to the project’s end-developers). Dojo, and especially package management, has already solved many of the problems that hurt developers, but I don’t think many developers are yet aware of how to use the solution. Though some docs talk about running ant and Java, many potential beneficiaries of Dojo have never used either.

I take serious exception at your conclusion that we “rewrote Java in Javascript and called it Dojo”. We embrace and build on the functional nature of JS. I personally prefer Python to most other languages, and only grudgingly use Java. What we’ve done with Dojo is to build a set of layered libraries that you can pick and choose from. Our plan is, and always has been, to build a set of common APIs that we can implement everywhere. A standard library, if you will. We didn’t just invent features because they were fun to hack up, we built them because we needed them in apps that we’re building. The point of Dojo is that you can take or leave them as you see fit. Obviously, you’ve taken a different route. Fair enough. All I ask is that you not jump to the the conclusion that we’re over-engineering or spending effort in places where it isn’t necessary when you aren’t even using the tool.

Regards

When we started all of this, Dojo and most of the other “frameworks” didn’t exist. So we rolled our own. After a while we had similar sized .js files like you described.
Then I came into contact with two very very experienced enterprise software engineers with 20+ years of experience designing, building and implementing all kinds of client/server and messaging systems. They described to me how to unify GUI and data into messages and message frameworks. They were doing this when the Internet was still called DARPA NET on dumb terminals – instead of Javascript and DIVs they used VT220 terminals codes and C. It’s the same thing all over again.

What’s my point? We married the two. Our client side code is a few hundred lines and it’s sole purpose is to dispatch and render messages. The result is a very very light system. Light in the sense that the source code, or scaffolding as we call it, has no moving parts and in no way interferes with your changing business requirements or even changing environments.

So going back to my original point. You’ve come across a platform that allows you to break out of the confines of source code and J2EE mayhem. And what did you do? You rewrote Java in Javascript and called it Dojo.

Best,
Brad

So fundamentally we would like to be *out* of the business of providing these kinds of abstractions. That we have to ship around functions that make up for the stagnant and back-asswards DOM APIs and browser implementations makes me none too happy. And don’t you think that packaging is something the language should provide? The widget system, likewise, is architecturally constrained by the implementation decisions of IE. It’d probably be about a third the code were it not for the various browser issues. The things we’re going to need to do for data binding because the JScript team failed to implement getters/setters just makes me want to cry.

Dojo is big because it tries to accomplish a lot of things and because we try to do them everywhere. The build system is there to help make it as light as you need it to be for your app, but fundamentally, until the browsers start to fix some of the things they’ve left neglected, every major toolkit will asymptotically approach the 100K+ mark for any non-trivial use case. MochiKit and Scriptaculous are there today. Prototype alone is 54K, and all of these are tools that advertise how “lightweight” they are. Dojo builds that do similar things are usually in the same ballpark. We spend a *lot* of time trying to ensure that builds that need just one thing are as lightweight as possible. Jquery and MooFX take a different approach to solving the problem: simply promising to do less. It’s a good solution too.

Dojo is up-front about what you “pay for”, when you pay for it, and how to make your build smaller without rewriting your non-trivial app. If writing, debugging, and testing this stuff yourself is your idea of a good time, well, then no one will dissuade you from doing exactly that. Best of luck. If you want to be part of a community that has hit these problems before, has some solutions, and is constantly looking for better ones, we welcome you to join the mailing lists and help us make Dojo better for whatever your needs may be.

Regards

boycott this stupid shit!