More than a year ago I had the pleasure meeting a man by the name of Amit Green. At the time we got to talking about lots of things, and eventually his arguments helped turn the tide on making the big changes required for Dojo 0.9. As a part of of those discussions, he convinced me to read this book, which in 2007 read as part wise tome and part time-capsule from a simpler, slower time in business. Perhaps the most important thing I took away from it was the difference between power and authority. To quickly summarize, "power" is the ability to affect change while "authority" is the right to make any given decision. It's easy to see how these are different: the person actually doing the work has all the power while the person who signed off on the spec has the authority. Sometimes these things are embodied in the same person but the minute they're not you have a "management problem". The solution isn't to just assume that one person will do everything; you'll get no division of labor that way which defeats the entire point of modern economics. Instead, you have to get everyone to respect the other parties such that authorized decisions represent the interests of those with power and that those with power have some agency.
But what happens when that process breaks down? When those with power forget that they have (or should have) instigating new decisions or framing them correctly? Or when everyone on the outside assumes that those with authority are the ones who can really make something happen? I'll argue that you get the web as we know it today.
As a case study in putting your faith in the wrong idols, you can't do better than posts like this which "blame the W3C" (via Molly). Blaming the W3C for not pushing the web forward is both humorously off-target and distressingly common. I've written about this before, but fundamentally you can't blame the W3C for failing to act because it's not the W3C's job to act. An MBA should be able to tease this out a bit more effectively – any decision only requires that you have answers for five questions: why? what? how? when? who?
Answering these for pushing the web forward is straightforward, even on a simplistic level:
- Why?: it's too hard to build reasonably sophisticated interactions with current web technology
- What?: new tags, JS and DOM APIs, CSS syntax, and renderer support for all of the above. Eventually, a spec or five reflecting these new technologies.
- How?: we could try asking the W3C to do it, but they don't have any power. When they've been left to their own devices, the W3C has failed. Miserably. Over and over and over again. Instead, browser makers should introduce new stuff and then agree to agree on it (via the W3C or similar organizations).
- When?: introducing new features in any given browser seems doable in short-order. In the case of Open Source browsers, the answer is "as soon as someone decides to invest in them". Competition has even spurred Microsoft to some level of action. The likely time-scale for new features over all, though, appears to be on the order of 5+ years. That's clearly not soon enough.
TODO: investigate ways to speed this up.
- Who?: browser makers and others in a position to affect the code that goes into the renderers we use.
Figuring out "how" leads you directly to "who" in this case. The action we all want is the sole purview and responsibility of the browser vendors and they alone have the power to push the web forward. The "web standards community" has made it clear that they'll need the imprimatur of some authoritative body where agreement can be forced, but that hasn't kept the browser vendors from taking the initiative there, either. The big, open questions then center around how the "web standards community" can make enough room for renderer vendors to try out new stuff, since that's how we get new things. Demanding agreement on what to do before trying it out demonstrably doesn't work, so it's then imperative that there be a mechanism for the web to iterate prior to standardization. In fact, I'll argue that this is now the biggest reason that Paul Ellis isn't getting the improvements he wants out of the web: there's no mechanism in place by which any browser vendor can take significant risks without incurring the wrath of a swarm of WaSPs, or worse. Attempts to even begin to lay the groundwork for such a mechanism have been shot down forcefully by may folks who, like Paul, view "fixing the web" as the W3C's job.
Standards bodies are animated only by the needs of industry to reduce costs by forcing vendors to agree on things. Like Open Source, they can act as a back-stop to the monopoly-creating power of network effects by ensuring that the price of software commodities eventually does reach zero. In this context, then, the W3C's only effective function is to drive consensus when visions for how to go forward diverge or lead down proprietary ratholes. Asking the W3C for more is the fast path to continued disappointment.
The W3C is just a sail and all sails need the wind to function. You can't blame the sail for the wind not blowing.
I'm incredibly excited about the SitePen Dojo Toolbox AIR app that just launched. I've been using early versions for a couple of weeks now, and in that time it has earned a privileged place on my desktop. Being able to make local builds without delving to the command line is something that I've wanted to be able to show new Dojo users for years and this tool finally makes it easy. There's more work to do around configuring the profiles themselves, but the new tool demystifies many of the build configuration options significantly. Having a searchable API viewer available is also a godsend. Huge props to the team that put it together!
Edit: I forgot to note one of my favorite parts of the project, namely that because the Dojo build system is written in JavaScript (thanks to James Burke's awesome work), the build system in the Toolbox doesn't require Java. Instead, SitePen was able to port the few Rhino dependencies in the build tool to work with the native JavaScript engine in AIR. It's a minor thing, but it speaks to the excellent engineering behind Dojo's tooling and the power of having actual web-native technologies inside a desktop app.
I'm not sure how I missed it for so long, but I'm now reading every word of the Linux Hater's Blog. It's beautiful catharsis, and I say that as someone who used to serve as President of a university LUG and who writes open source software for a living.
Like the author of LHB, I've written my share of low-level Linux stuff and shudder in horror and how backward the linux desktop still is. X11 is an abomination and configuring sound or wifi or some new-ish device...well, I still have those scars. It wasn't that long ago that I was hacking together bits of kernel patches to get an early firewire iPod (a gift from Jennifer) working on my SuSE desktop. And I was using SuSE because it usually required the least futzing of the then-available distros. Even when Linux was my desktop OS of choice – I had since climbed down from my brief flirtation with OpenBSD – it was blindingly clear to me that building my own packages was a fool's game. My time is simply worth more than that. Perhaps the most cogent point I took away from reading the LHB archives is that building professional code for the "Linux Platform" is nearly impossible, not because it can't be done, but because it costs too damned much to justify the costs. The Linux crowd seems to mis-value the immediate vs. long term costs of choice. By failing to provide a binary-friendly environment, the Linux world creates conditions only friendly to Open Source software, crippling their platform and robbing it of the capital investment that would allow it to truly compete. Many people who suffer through some Linux distro as their desktop environment no doubt see this as a good thing. I, however, need to get some work done. The LHB cogently lays out why everyone else on the planet whose time is worth more than what Amazon charges for a CPU-hour on EC2 similarly dismisses Linux for anything but servers.
The almost religious belief that choice is good ignores the inability of most people (myself included) to fully judge the long-run costs of any given technology decision. Oddly, the web browser world seems stuck in a similar position. Choice in browsers is promoted like some sort of panacea, when in fact our big problem isn't choice, it's that browsers simply can't natively attempt the feats we need them to accomplish. Smart people don't replace their browsers, they use what works until it doesn't any more. No wonder it's taken Firefox so long to gain market share. Like linux distros, browsers evolve in hodge-podge was, never quite tracing a straight line toward real progress. The refrain of "standards will save us" seems to ignore the reality that, like the LSB, the existing W3C standards are absolutely insufficient to address the problems at-hand. Both CSS3 and HTML5 are nice first-stabs, but they don't get us "there". For Linux, the LHB points out that there's zero reason to not ship "the same bits", and for the web, the issue is that content can't tell the browser "no, really, use that renderer". Interestingly, Microsoft tried to convince the world that we should version our content and the standards zealots just shot them down without really considering the consequences. Instead of making the world safe for a better web, the HTML standards geeks instead did the most powerful thing they could do to prevent it from materializing. In essence, they preserved "choice" at the expense of utility. What a waste. Seriously, if these are the deep thinkers on "our team", why not go just use Flash to build everything?
Many people have gotten worked up about Microsoft's role in killing Netscape (although they tend to minimize Netscape's role in its own demise), but ISTM that the real long-term harm done here has been to remove the renderer as a profit center. Once Microsoft set the price of the browser at "free" they effectively killed browser evolution as part of anything but an OS-based platform play (in part, to preserve their existing OS-based platform play). Interestingly, then, web-based services have routed around the difficulties of the platform to date to deliver apps that seemed well out of reach of HTML 4.01 as implemented by IE 6, but well, we're a plucky lot, aren't we? The most progress being made right now seems to be coming from a large software vendor in Cupertino with an OS-based platform play that absolutely needs the web to sparkle in order to drive adoption of their OS and hardware.
Like Linux, the web will probably lurch forward this way for the forseeable future. The standards zealots smacked down the IE team so hard on content versioning that I don't think anyone else will have the testicular fortitude to try again for a good while. It's down to the whole "vision thing", and the web standards crowd doesn't seem to have any. It's about time someone took the punch bowl away from them once and for all. The open web needs real progress too badly to stall any longer.
Several Dojo's most prolific European contributors have banded together to form Uxebu, a new consultancy centered around Dojo and JavaScript (blog here). SitePen recently expanded to the UK and while we're doing lots of business in the EU, it's an exciting time to be working with Dojo as the demand is very high. I'm tremendously excited to see that Nikolai, Wolfram, and Tobias are stepping in to help fill the need! Given the quality and quantity of their contributions to Dojo, I expect great things of their new firm.
Congrats guys!
Now, right this very minute, you can learn pretty much everything there is to know about Dojo thanks to 3 newly published books. Writing a book on Dojo is hard in the way the writing a book on Python is hard: there's so much to talk about, where do you start? When you could teach anyone anything, what do you focus on? Thankfully each of the books takes a different tack, talks to a different audience, and as a result I think the entire spectrum of web developers is pretty well served. Having reviewed 2 of the 3 books before they went to press (Dylan and Pete reviewed the other one), I've been amazed both by the depth of the books and by how different they are.
Pragmatic's "Mastering Dojo" has my name on the cover, but don't let that fool you...it's actually quite excellent, largely because Craig and Rawld focused do heavily on helping you not only learn what's valuable about the toolkit and how to use it, but by digging deep into the guts and showing you why the pieces are put together the way they are. The real art of building really responsive JavaScript driven UI's is about making good tradeoffs, and this book really helps you understand what Dojo provides you with in ways that let you trade things off for the benefit of the user experience.
The Pragmatic book isn't shipping from Amazon yet (unlike the O'Reilly and Addison-Wesley books), but if you buy it from the Pragmatic Programmers directly, you can get a PDF of the book immediately while the dead-tree copy wends its way through the end of the supply chain.
Update: Andy Hunt emailed me to let me know that the Pragmatic book is indeed shipping, and last night, upon arriving home from a business trip, I found my copies of the book waiting. Andy informs me that Amazon is also shipping them, so if you prefer the "one click" experience, you can order there as well.
"Dojo: The Definitive Guide" really is. As a reference, you can't beat Matthew Russell's tome. Where "Mastering Dojo" teaches you the how's and the why's, "Dojo: The Definitive Guide" is the book you'll keep on your desk and reach back to when you're not entirely certain what the inheritance tree of the Dijit form widgets is (and therefore, which you need to subclass or mix in). "Dojo: TDG" is chock full of insightful commentary and explanatory diagrams, and where the Pragmatic book helps you learn the pieces and pull them together intelligently, TDG gives you more of the pieces and helps you really get a handle on the vast functionality available in many of the nooks and crannies of Dojo. Don't develop serious apps without them both.
James Harmon's "Dojo: Using the Dojo JavaScript Library to Build Ajax Applications" stands out among the crowd as the easiest introduction to the toolkit. While the O'Reilly and Pragmatic books provide serious firepower for application developers, James' book gives a solid introduction which helps web developers who might not be down with the whole "Ajax" thing just yet a chance to catch up and start taking full advantage of the features Dojo has to offer. Large chunks of Dojo have been designed with non-programmers in mind, from the declarative markup syntax to the template system, and James' book helps really showcase how simple it is to start building rich, compelling UI's with Dojo.
There's probably still room in the market for 2 more books: one on using just dojo.query() and dojo.behavior for progressive enhancement, and one on advanced dojo.data (there are a pleathora of stores and use-cases there) and visualizations like the Grid, Charting, and dojox.gfx. I know that there are even more books in the works of, for, and by the Dojo community, and if the quality of those that come after is anything like these 3, it'll be just more proof that when the Dojo community does something, we do it right.
My personal congrats and thanks to all the authors who poured their lives into these books for months on end. The results are nothing short of spectacular.
Older Posts
Newer Posts