Recently, Mozilla had the opportunity to help do something quite new and free a piece of JavaScript software, namely the TurboAjax TurboGrid. The code has been freed under the auspices of the Dojo Foundation, becoming a new Dojo Grid component.
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.
What I find to be most interesting about this announcement, however, is the situation upon which it arrived. Mozilla and a number of Dojo users (SitePen, Nexaweb, Redfin and SnapLogic) all pooled their resources together in order to purchase, and subsequently, free the widget to the general public. I find it interesting that the companies chose to take this course of action, as they could’ve left it as commercial software, paying a licensing fee whenever needed. Instead, they decided that this component was so important to JavaScript and web development, in general, that the source be made open for all to use.
The position of the corporations using Dojo is obvious: They want to see Dojo succeed, and having a unified Grid component will ease their development costs significantly. However, for Mozilla, the goal is slightly more esoteric: We want to see the Open Web succeed (and by which, we mean the advancement of open software, standards, and development practices). Thus, by sponsoring the freeing of a critical piece of JavaScript development infrastructure, Open Web development becomes that much more feasible.
With this event taking place, I feel like a significant corner is being turned in JavaScript development. If you look at what was required to come up to this point:
- JavaScript libraries congeal to a point to warrant standardization (in this case, in the form of Dojo) and Open Source development.
- 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.
That means that the JavaScript community has had the opportunity to mature to the point at which it can make a full cycle (having closed source software being built on open source software, becoming open again). A rather exciting time.
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.
That’s a rather minor point however as this feels like it’s really just Mozilla starting to test the waters for funding Open Web JavaScript development. It wouldn’t surprise me if we saw more of these “jailbreaks,” or even sponsorships, in the future.
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)
The TurboGrid widget is cool and all, but I don’t know, it’s not enough to sway me to change from jQuery and Prototype.js based development to Dojo. Dojo has some nice aspects, but I just feel more comfortable doing object-oriented and unobtrusive JavaScript development in Prototype and jQuery. Obviously you can accomplish the same goals with Dojo, but I feel more comfortable practicing unobtrusive OO in jQuery and Prototype. Perhaps that will change one day, who knows, but for now, I love the documentation and resource base with both jQuery and Prototype and it makes me more comfortable developing with those. I especially like jQuery in how overt it is about playing well with other libs, you can gain the best of both worlds.
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)
Hey John–
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.
@alek: At times like this, I like to remind myself of something Joyce Park likes to say: “why is it that when it comes to JavaScript, there always has to be ‘there can be only one’?” Egos aside, I’d rather see a number of JS libraries out there, all solving a specific set of problems. We at Dojo wouldn’t have a number of features if it weren’t for Prototype and jQuery and MooTools and Ext, and I have a feeling that this is reciprocated in some fashion–making all of the toolkits better. As any capitalist will tell you, competition is good :)
@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)
@Tom:
Did you read my comment at all, or just jump right into the contradiction?
“I just feel MORE COMFORTABLE doing object-oriented and unobtrusive JavaScript development in Prototype and jQuery.” I even explicitly stated “obviously you can accomplish the same goals with Dojo”. For some reason you felt the need to contradict me, but you ended up saying the same thing.
I prefer the JavaScript I write to be unobtrusive. Also like to practice OO in many cases in my JS. Yes you can do so in all three libs, but, by personal preference, it’s a more comfortable experience for me personally in Prototype and jQuery. More so than writing JS without a lib, yes. That does not mean Dojo isn’t great. Different strokes for different folks.
“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)
@Tom: Yes I’m aware, and I think most people are aware that they are two separate concepts. Not to be blunt, but it’s not that profound of a distinction. …I combined my ‘likes’ in a sentence, didn’t mean to confuse you or anyone else. –prefer to practice unobtrusive JavaScript. (prefer to NOT write inline JS, write my JS in separate files, attach events when the DOM is ready, or when the window loads, etc, prefer my code to gracefully degrade when JS is turned off, etc) Separately, in many cases, prefer to practice object oriented code in JavaScript. I didn’t anticipate a simple comment would be looked at so pedantically.
@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)
@Tom: Let’s not forget that it was competition amongst browsers that made JavaScript a dirty word in the first place, forcing us to call everything Ajax, because nobody would hire us if they saw JavaScript on our resume. It is the incompatibilities between the competing browsers that each toolkit attempts to tackle in its own way. In addition each toolkit extends some core functionality in obvious ways (I am thinking CSS style DOM selectors), but does so using incompatible methodologies.
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)
Hi John,
As always, your remarks are an insightful look at the future of JavaScript. You freaked me out a little, though, when you said when Safari 3 goes Gold, you’re dropping support for Safari 2 in jQuery. Can you clarify this a little? Does this mean you’ll stop actively trying to make sure it’s 100% compatible with the full jQuery suite? Or does it mean you’ll make intentional changes you’ve been waiting to make that will essentially cripple Safari 2 support?
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 :)
Thanks,
Steve
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.
@Mark: I disagree with your posts completely. They don’t seem to make sense. They seem uninformed, and strange. You repeatedly use the words “object-oriented and unobtrustive javascript” as though it’s a feature that your framework does better. But a) they’re completely different things. b) in my experience, Dojo does these things as good as, if not BETTER than any other. Dojo is a lot more powerful. Especially when it comes to class support, inheritance etc.
Your comments “I prefer the JavaScript I write to be unobtrustive” are illogical – I wonder if you don’t understand what the term means. Any framework can be used to develop unobtrusive code. The concept of ‘unobtrustive’ is about TECHNIQUE, not the platform. Perhaps you will learn this over time.