by Shelley Powers
08/18/2000
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  
|
A browser is a browser is a...
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.
XUL: XML never looked so good
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.
Pages: 1, 2 |
