I've always prided myself on my impartiality when I write. I don't side with any of the Microsoft/Open Source/Sun/etc. camps and prefer being on the outside looking in so that I can write objectively about technology.
After all, I write books on Microsoft technology for O'Reilly -- you can't be more of an outsider than that.
Lately I've been reading some negative comments about the Mozilla project from folks impatient for the release of a browser from this effort. A general consensus seems to be that if Mozilla had just focused on the browser and none of the other technologies -- such as XUL, XPCOM, and XSLT support -- a "standards compliant" browser would be on the street and Microsoft's IE wouldn't be in the position of dominance it's in today.
Well, dominance comes and dominance goes and no one's king forever.
To me, as an outsider, if Mozilla hadn't branched into innovations such as XUL and XPCOM, I wouldn't have paid it a second glance.
|
Also Featured This Week Mozilla is Not Netscape (and Other True Facts) Infinite Extensibililty with XBL  
|
There seems to be a belief that if a "standards compliant" browser were issued, folks wouldn't use anything else. However, in reality, support for standards is not as much of an issue as client base is for people who create web sites for a living.
The majority of web page authors create pages that are compatible with browsers used by their clients or defined as the target browsers by their company. This means that many web page authors are still writing for older browsers such as Navigator 3.x, much less the newer Navigator 4.x or IE 5.x.
Standards just aren't the primary focus for web developers: Making a living is.
Internet Explorer is, currently, the dominant browser and will continue to be used by a significant number of people into the future. Web page authors won't drop support for this browser even when one considered more standards compliant is released -- not if the web site owners want to attract clients from the general Internet population.
So, a standards compliant Mozilla or Navigator 6.0 isn't going to knock Internet Explorer out of the picture and really isn't going to change the world of Web development overnight.
What made Mozilla (and Navigator 6.0) stand out and command my attention was the approach that Mozilla took for the development effort, and the technologies the team has created to build the browser, technologies such as XPCOM and XUL.
Since XUL has become a target for folks unhappy with the Mozilla effort, let's take a closer look at it and what it brings to the browser development effort.
I wasn't overjoyed when I first read about XUL, the XML-based user interface language used to build Mozilla and Navigator 6.0's user interface. After all, what we didn't need was yet another proprietary technology.
However, when I actually began working with XUL, and realized what it can mean to a user interface developer, it was love at first byte.
Consider this: I can create a Windows-based application that contains menus, and toolbars, and collapsible tree-based TOCs, and that loads Web pages and other resources, all using nothing more complicated than XML, CSS, and some scripting. Best of all, my application's interface will work the same in Linux or the Mac OS without me even having to touch either of these operating systems. Not once. Now, that's power.
Now, I could use something such as Java and Swing to create an interface that runs on all sorts of platforms, but anytime I want to change said interface, I have to go into the code, pull it apart, put it back together again, and hope -- hard -- that it will continue to work.
Or I could use XUL and pull out a couple of lines of XML and replace it with another couple of lines, maybe add a line or two to a CSS file, and I'm done. I'm not touching the underlying implementation, only pulling out one XML widget and replacing it with another.
As a case in point, I created a small Mozilla tutorial application using XUL that I test with each Mozilla milestone release (the code is still alpha and the architecture can change at times). I used an RDF (Resource Description Framework) file to provide the data for the collapsible tree-based application TOC rather than hard coding it into the application page, and then used XUL templates to process the data into the display. RDF is based in XML, as is XUL, so the only technology I had to use to create the TOC was XML.
Between milestones M15 and M16, the Mozilla RDF folks redesigned how RDF was processed in order to provide a more standards-based approach.
Well, I'm all for standards, but this change broke my TOC.
In a hard coded situation, I would have had to do some recoding in my application in order for the TOC to start working again based on the new RDF/template structure. However, with XUL, all I had to do is redesign the RDF file and do some tweaking of the XML for the template. Again, the only technology I had to use to meet the architectural change was XML, and the amount of time it took me to make the change was very small compared to how long it would have taken me with Java and Swing.
The efficiency of using XML-based widgets to create a user interface has appeal for more than just the Mozilla development effort and individuals such as myself. For instance, ActiveState is using XUL to develop Komodo, an IDE for developing applications using Perl or Python.
XUL is more than just a programmer's convenience: It also expands our understanding of what we can do, really do, with a standardized markup language such as XML used in combination with a little ingenuity.
XUL is just one component of the platform that is known as Mozilla, and a reusable one at that. In fact, there doesn't seem to be one component of Mozilla that can't be pulled out and reused in some other application.
|
Most of us talk about reuse and the importance of application modularization, but the Mozilla team walked the talk, and followed through on the principles of application design that we've been pushing for the last ten years.
After all, Mozilla, the platform, is nothing more than a set of reusable components, all of which were necessary for the development of Mozilla, the browser. A side benefit is that the same components can be used for other applications.
The one problem with reusability -- and the number one reason we keep coding and re-coding the same old functionality over and over again -- is that creating an application consisting of reusable components can sometimes slow the first release of the application. In these cases, the long-term benefits of this approach aren't realized until a later time, such as when new releases of the application are created.
Developers of large applications have long faced this early cost/later payoff issue with corporate managers and bean counters, and it's only with the second or even third release of the application, or releases of other applications, that the benefits of creating reusable code become apparent. In the beginning, though, the road to reuse is all uphill.
With Mozilla, you don't have to wait for the second release to see a payoff with its component-based architecture.
Returning to XUL again, it's true that the Mozilla developers could have hard coded a user interface instead of first creating XUL and then using XUL widgets to create the interface. The interface may have been finished a bit sooner (or may not, hard to say). However, any architectural change in Mozilla would then result in a recoding effort. With XUL, all that happens is some XML tweaking.
So when an architectural decision was made to alter the RDF/template processing, the Mozilla developers responsible for necessary browser elements such as the preferences dialog or the sidebar didn't have to recode their application pieces -- they modified the XML instead.
Recode the application interface versus tweak some XML: Do the math.
Reusable components aren't the only side benefit we'll get out of Mozilla. The project management techniques used to manage the Mozilla effort are also worth a closer look.
Personally, I wouldn't want to manage an open source project. The team members may or may not be employees, may or may not live in the same geographical area or time zone, and most likely have decidedly different interpretations of how the development process should occur.
I'd rather visit my dentist.
Mozilla is a complex application -- all browsers that appeal to web developers needing something more than a layout engine that processes HTML are, by necessity, complex.
Because the application is complex, and based in open source, the Mozilla team had to create new project management paradigms to control the code development process. Guess what? You can actually benefit from the lessons learned from this process in your own application development environment.
Consider this: A key factor of Mozilla development has been to break the application into manageable modules and assign ownership of these modules to small groups of people that are empowered to do what's necessary to create their modules, within the overall application architecture. If new functionality is wanted, a new module is created and isolated in such a way that if the functionality isn't finished, it doesn't get included in the Mozilla release. More importantly, it doesn't hold up the release.
To make this process work, much of the team communication is also in the open: in bug reports found in Bugzilla (a bug reporting/ tracking system you can download and use for your own development efforts), in status updates at the Mozilla site, and on newsgroups focused on each of the modules. This openness actually leads to some interesting results at times.
Earlier I mentioned that I was a Mozilla outsider. Well, this isn't entirely true.
When I tested my little XUL-based application with milestone release M16 and found my TOC wouldn't work, I checked with the Mozilla RDF newsgroup and found that the RDF processing had changed. Chris Waterson, a Mozilla/Navigator 6.0 developer who works on the RDF/template module, directed me to a document on how the new template process worked.
After reviewing the document, I asked Chris if he had any documentation or examples on nested content. Within a day, Chris added an example and a document page on how to implement nested content with the templates.
Chris helped me directly, but I actually worked within the Mozilla effort, indirectly, by asking a question that led to additional documentation that will help other developers.
How about that -- I was empowered.
Now, if I had asked Chris to change the template processing back, he would have said no, as this would violate the application architecture. My empowerment was checked within reasonable bounds.
The architecture constrained/modular project management approach worked, and worked well. Now, when was the last time you could say that about any large application project you were on?
There's more to the Lizard then meets the eye, but you have to take a look beyond the box -- or should I say browser?
Because much of the Mozilla effort's project management has been in the open, we can learn from this effort, and even apply many of the management techniques to our own efforts.
As just one example, if you work for a large shop, consider using internal newsgroups as a way for your own architecture teams to communicate with other developers -- this approach does work.
If nothing else, you can download and use Bugzilla, a sophisticated, free, bug tracking and reporting system.
As for the Mozilla platform: Take a moment to appreciate that the Mozilla development team has only been following the programming practices we've all been pushing for the last decade, and that the reusable component-based architecture is one we can all benefit from.
It's a better use of your time than beating the Lizard.
Shelley Powers has been working with, and writing about, web technologies--from the first release of JavaScript to the latest graphics and design tools--for more than 12 years. Her recent O'Reilly books have covered the semantic web, Ajax, JavaScript, and web graphics.
Also Featured This Week
Mozilla is Not Netscape (and Other True Facts)
Infinite Extensibililty with XBL
Discuss this article in the O'Reilly Network Browsers Forum.
Return to the Mozilla DevCenter.
Copyright © 2007 O'Reilly Media, Inc.