From a technological perspective, the grid is quite robust, offering a number of features, including support for large datasets, column manipulation, data independence, and editing of cell data.
- Developers begin using, and adopting, the libraries as their development platform of choice.
- Commercial widgets are built on top of the platform.
- A commercial widget is freed, and becomes Open Source.
Now, obviously, the assumed effect on Open Web development that this particular widget has will vary greatly depending on whose asked. In the opinions of the Dojo Foundation (and the sponsors), it’s very important. Asking users of another library, however, and you’ll get a significantly different story. That’s the one piece of this equation that particularly grates with me, especially coming from a vendor-neutral organization like Mozilla. The support of this widget is actually saying three things: 1) This is a high quality piece of code 2) Having this code open for all to use will better the web and 3) That you should be using the Dojo Toolkit for your development (since it’s required in order for the widget to work).
I think an optimal approach would’ve been one with an extra stipulation: The widget would be freed both ownership-wise and dependency-wise. It’s definitely possible, and the recent work that the Ext library has done proves that it can happen.
Side discussion: Apparently dojo 1.0 has dropped support for Safari 2? Bwahh? How is it even possible to drop support for a browser release that is still its current version? Trust me, once Safari 3 goes gold, I’m dropping Safari 2 support from jQuery like there’s no tomorrow, I hate that browser with the fury of a thousand angry web developers, but until that time – too soon?
Update: I was asked to clarify a couple things: I’m not expecting Dojo to go out of their way to port the widget to other platforms (or even to free it from their own), I’d just think that Mozilla should make a strong attempt to generate codebase-neutral code. Granted, that may not be always possible – in the case of the Dojo Grid there’s a significant amount of functionality tying it back to Dojo core.
Also, as far as the dropping of Safari 2 support goes, it was clarified to me that the Dojo 1.0 release will be at about the same time as OS X Leopard, thus, Safari 2 will already be by the wayside at that point. Noted – and approved of!
Sebastian Werner (September 19, 2007 at 1:54 am)
We have already dropped Safari 2.x support from the current trunk in qooxdoo. The new major version of this development is planned for the end of this year. As Safari 3.0 will also be available for Tiger I do not see any reason to keep support for this buggy buggy browser in current development branches. I think the same applies for Dojo 1.0. For stuff which do not get released before Safari 3 is out it is perfectly safe to remove support for this old version now.
pd (September 19, 2007 at 4:26 am)
Congratulations on being able to diplomatically state the bleeding obvious:
“Why did the company I work for decide to buy code that doesn’t support my library?”
If I was in your position John, I’d be pretty shitty.
Les (September 19, 2007 at 7:37 am)
The more I learn Dojo, the more I like it. But, the doc is still lacking compared to other frameworks. Are there any plans to improve it when Dojo 1.0 is released?
Mark Holton (September 19, 2007 at 12:49 pm)
Thanks for the insights, as always, John.
alek (September 19, 2007 at 4:46 pm)
I had to wince when I first saw this announcement. As you point out it easily reads as an endorsement of Dojo as the dominant framework.
Then after about a half second of thought, I canâ€™t imagine it would be a remotely easy to make it work with any other framework. In fact I think we may have replaced the browser wars with the even more diversified framework wars!
Now I am starting to see what Crockford described as a “nightmare scenario” in this thread.
Even the mentioned Ext has moved in the direction of their own core and have not been announcing support for updates of other frameworks.
Aside from rebuilding every widget for each framework, is there a solution here? To take an even more basic widget: how hard would it be to make the calendar from jQuery UI work without jQuery? Now how about making it generic enough to take advantage of selectors from any framework. Is this even possible?
Tom Trenka (September 19, 2007 at 8:58 pm)
I don’t know where you got your info with regards to Safari 2, but the fact of the matter is that it’s only Dijit (the UI library) that doesn’t support it; the Dojo Core supports it just fine. My understanding is that with Dijit, it’s just too difficult (with regards to the JS stack) to try to get it going with full accessibility.
Also not sure where Mark is coming from WRT to “unobtrusive OO with JS”; they are two separate things, you can practice any kind of OO with pure JS (you don’t need Dojo or Prototype or jQuery to practice decent JS development), and you can use all three libraries (bear in mind, I’m talking Dojo Core here) to do unobtrusive dev. I’ve used both Dojo and Prototype that way, and both served their purposes very well for the situation.
(My apologies in advance, I have not used jQuery and I find it unlikely that I will in the future; nothing to do with the toolkit itself, it’s just that most of the dev I’m doing at this point can be solved just fine without having to delve into a 5th toolkit (personal experience).)
Oh, and “moo”. Figure that needs to be added before it’s too late and someone complains about moo not being mentioned :)
I think that it’s very possible in the future for all of us to be cooperating in terms of being able to use more than one library at a time; it’s unfortunate that there’s duplication but at the same time tools are designed for a specific purpose, and despite any kind of zealotry I would hope that responsible people would choose the best tool for the job they have at hand, as opposed to making a square peg fit in a round hole.
@Les: we’re working on it, we consider it a blocker for 1.0, along with the aforementioned grid and the charting engine (I’m working on it, I swear!)
Mark Holton (September 20, 2007 at 3:28 am)
Did you read my comment at all, or just jump right into the contradiction?
“More comfortable” = Personal preference, Tom. I like Class.create. I like Event.observe, $(document).ready, etc etc etc.
Les (September 20, 2007 at 8:29 am)
@Mark: Dojo is a lot more powerful than Prototype and especially jQuery with the ability to create modular OO code. jQuery doesn’t provide any class support; Prototype 1.6 RC0 provides class support including inheritance, but it has no concept of modules.
Tom Trenka (September 20, 2007 at 8:47 am)
@Mark: I was responding to this:
“but I feel more comfortable practicing unobtrusive OO in jQuery and Prototype.”
I don’t have a problem with your personal preferences; to each their own, life’s rich pagent and all that. What I was responding to is the way you mix “unobtrusive” with “OO”. They are two separate things. Mixing the two is confusing and it’s been a pet peeve of mine for a long time: unobtrusive coding has nothing to do with object-oriented coding, and OO coding has nothing to do with unobtrusive.
This is what I was trying to point out, and responding to. You’d be surprised how often terminology usage leads to misunderstanding, and not just with programming (again, speaking from experience).
Mark Holton (September 20, 2007 at 2:19 pm)
@Les: appreciate the heads up, will have to check out the module support in Dojo in more detail and see what sort of benefits are provided there over and above creating modules in straight JS via common namespace/initialization convention.
alek (September 20, 2007 at 3:33 pm)
As long as the toolkits continue to diverge on these points they will perpetuate a new version of the browser wars. Fortunately the end users are not paying the price this time. But I have had managers asking if it is dangerous to commit to a JS toolkit because the company (meaning: Dojo, jQuery, Ext, etc.) may fold and support would be lost. The result is managers that are afraid to allow toolkits to be used on their sites.
I have been thinking about this, and perhaps there is the chance for agreement on common method names in core functionality. At the very least this might allow for some cross toolkit widgets to be built. Consider com.mydomain.mywidget.toolkit = dojo (or jQuery, or Ext, etc.)â€¦ com.mydomain.mywidget.toolkit.cssSelector(â€œbodyâ€)
The alternative is com.mydomain.mywidgetDojoVersion, com.mydomain.mywidgetJQueryVersion, com.mydomain.mywidgetExtVersionâ€¦ Which in the end will result in com.mydomain.mywidgetIamNotUsingAnyFreakingFrameworkVersion
Tom Trenka (September 20, 2007 at 6:44 pm)
@Mark: It’s less you and your comments here, and more of the repetitiveness of seeing the same terminology all over the place. Sure, it’s pendantic–but at the same time, it’s that kind of collusion that gave a lot of people the wrong impression about JS in the first place (and I’m talking back during the brower wars that Alek refers to), and it’s taken a *long* time to get some traction back. All I need to see is someone asking a question about “how do I do this with Dojo using unobtrusive OO techniques”, and I say to myself “god, you know, I know people like Mark may know what they are referring to but it’s *so* easy for people who aren’t in the know to get confused about it, and just drop JS altogether for something like GWT.”
It may seem pendantic, but (like I said before) you’d be amazed at how often terminology gets in the way. Glad to see you know the difference, though :)
@alek: “dirty word” is a bit strong, don’t you think? I think the problem in that respect was less the browser wars and more what Crockford calls “the world’s most misunderstood language”; *still* too many people consider it a toy. Sigh. Anyways…
Part of what each kit does is to tackle incompatibilities, sure. Sounds to me though like you’re looking for a standards group for Ajax toolkits. The problem is, though, coming up with those standards in a way that everyone will buy into. There’s the OpenAjax effort, which (in theory) is trying to what you’re talking about; hopefully there will be some success with that, but the problem there (from what I’m hearing) is that it’s being driven by organizations that don’t really grok JS overall, and are in the process of implementing something sorta Java-like.
I think that most of us in the JS trenches don’t like that at all.
You might think that this is a reiteration of the browser wars but I like to think of it as pushing vendors to get everyone what we need in the first place; and you can see some traction there taking place (for instance, with John here being at Mozilla now). It’s an interesting time to be a JS dev (among other things).
One thing I will say is that it does seem like we (the major toolkits) are standardizing node querying on CSS3; I’d like to think that future developments will follow in the same vein.
Steve (September 22, 2007 at 10:02 pm)
I love jQuery, and one of the main reasons I’ve chosen it to power several of our clients’ web sites was its “production readiness” and thoughtful support of a range of browsers. If jQuery just stops working in Safari 2, that would pose a problem that I’m sure others would share.
Again, great work, and I’m hoping you can calm my nerves a little bit :)
John Resig (September 23, 2007 at 5:47 pm)
@Steve: There’s no way that we can “cut and run” from Safari 2 right when Safari 3 is released. However, I suspect that we’ll just stop stressing out over testing in it and just transition to Safari 3 completely.
I suspect that we’ll have to wait, at least, 6-8 months after the release of Safari 3 before we can consider removing Safari 2 fixes, I’d imagine. A lot of that depends on if Apple forces the Safari 3 update, or not. If the update isn’t forced, then we’ll have to wait a long time – if it is forced, then it’ll just be a matter of months.
Steve (September 24, 2007 at 6:17 pm)
@John: Thanks for the reassurance. I figured that’s what you meant, I just misinterpreted your language to be a little stronger than it was.
Gavin (September 25, 2007 at 8:36 pm)
Great article. A word of advice to any who haven’t used it yet, TurboGrid is a *VERY* powerful piece of software. The Virtual scrolling is superb, and IMO a much better approach to data navigating than ‘paging’ which is slow, ugly, and ‘archaic’. I believe TurboGrid is going to be a HUGE push forward for the already great Dojo.