From the beginning, the World Wide Web that Tim Berners-Lee imagined was a place where the architecture of participation ruled. Berners-Lee's first application for accessing the information Web was both a browser and an editor, and throughout the early 1990s he worked diligently to encourage Web browser development groups to develop editors and servers as well as browsers. As early as the spring of 1992, the challenge was clear: "Although browsers were starting to spread, no one working on them tried to include writing and editing functions….As soon as developers got their client working as a browser and released it to the world, very few bothered to continue to develop it as an editor" (Weaving the World Wide Web by Tim Berners-Lee).
Developers tended to defer the editing functionality for a number of reasons, mostly to compress development schedules and to get the browser out the door - because they felt many people, if they didn't need it, would at least use it - without the editor, which was more complex and useful to a smaller audience. Netscape Communicator 4.0, released in 1997, did finally include Netscape Composer, although its licensing terms only allowed free use for non-commercial purposes. Internet Explorer never contained an editor directly, though Microsoft acquired FrontPage from Vermeer in 1996; FrontPage 1.0 had been released in 1995 (www.seoconsultants.com/frontpage/history/).
It wasn't just the complexity of the editing functions themselves, of course, but also the fact that reading pages required a much simpler authorization model, in which the user either has access to the document or does not. In fact, the cluster of issues at hand - from version control of Web pages to multiple authors editing the same page, sometimes at the same time, to control over who should have access to change what pages - would busy the content management industry for the better part of the next decade.
While the early Web browser teams deferred creation of an HTML editor, they retained a key element of Sir Berners-Lee's original Web browser/editor:
The 'View Source' menu item migrated from Tim Berners-Lee's original browser, to Mosaic, and then on to Netscape Navigator and even Microsoft's Internet Explorer. Though no one thinks of HTML as an open source technology, its openness was absolutely key to the explosive spread of the Web. Barriers to entry for "amateurs" were low, because anyone could look "over the shoulder" of anyone else producing a Web page ("The Architecture of Participation" by Tim O'Reilly).
This "View Source" menu item, which was not buried in developer editions or professional versions but was part of the core browser, created a culture of easy access to knowledge.
As the complexity of presentation-tier Web development grew, with Cascading Style Sheets, JavaScript, and DHTML in the mix, the View Source culture of Web development evolved into an open source culture of frameworks and libraries. It is this culture that enables the viability of current AJAX-based approaches to Web development.
The View Source Culture
From a narrow perspective, the decision to include a View Source option in the Web browser was an insignificant choice, perhaps useful for troubleshooting formatting issues, but of interest to a very small community. As Berners-Lee puts it, "I never intended HTML source code (the stuff with the angle brackets) to be seen by users. A browser/editor would let a user simply view or edit the language of a page of hypertext, as if he were using a word processor. The idea of asking people to write the angle brackets by hand was to me, and I assume to many, as unacceptable as asking one to prepare a Microsoft Word document by writing out its binary coded format" (Weaving the World Wide Web by Tim Berners-Lee). What View Source did (and still does!) was let users who were interested in learning to create Web pages see what HTML source was delivered to the browser to produce the page currently being rendered. Perhaps because many of the early Web users were developers of one kind or another, it became an expectation that any reasonable browser would include the ability to View Source.
Viewed more broadly, however, the View Source command was nothing short of revolutionary. It set the expectation that users should be able to not only view the "rendered" document, but also the "code" that created it. Because early browsers often differed in their interpretation of HTML, this was critical. Significantly, though, the View Source option was not buried in a developer's edition but was part of the edition everyone used, which encouraged even neophyte users to view the source of pages, whereupon they would see the relative simplicity of (especially early) HTML. (An interesting discussion about the need for the View Source option can be found in this bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=256213 - which was a request to move View Source into a developer build of Firefox, and was ultimately rejected.)
This same expectation - that users should be able to view the raw source of files served by Web servers in addition to the rendered effect - was later extended to Cascading Style Sheets (.css files) and JavaScript (.js). In order to be rendered and displayed, browsers would need to download HTML, CSS, and JavaScript files, along with images and other binary files referenced in pages. However, the fact that the major browser developers chose to expose access to raw source as a first-level menu item was extraordinary. (In some cases accessing .css and .js files required a bit more ingenuity on the user's part, but nothing like the difficulty of accessing the source files in any other format such as Microsoft's Word or Adobe's PDF.)
The View Source option was, however, perfectly consistent with the culture of the Web as a whole. Certainly, as I've said above, this was consistent with Tim Berners-Lee's vision of the information Web in which all could participate, and in the choice of HTML as an immensely simplified version of SGML. One could argue that the View Source option simply reinforced the already "open" nature of the Web as a phenomenon, which was firmly in place before the first browser was ever made widely available.
Regardless of whether the View Source option set the tone for the culture or merely reflected it, it is fair to characterize the culture of Web development that came into being as a View Source culture. In the early years of the Web, people learned HTML by example. When you saw a site that was doing something interesting, you would view the source of that site, and (often quite directly) copy their code into your own pages and edit from there. It became quite customary for such "imitation" (which was in some cases arguably copyright infringement by modern definitions) to occur even without the polite inquiry that originally preceded it. At first people asked, "Can I borrow your Web page template? I love what you've done with tables," but over time it became so customary people didn't even ask. People did continue to ask for access to server-side features, like Perl scripts for the common gateway interface, but perhaps due to Perl's heritage (version 3.0, in 1989 had been under GPL, even before Linux's public release), such scripts were commonly shared as well.
As the Web bubble grew, people started to offer well-designed HTML/CSS templates; useful JavaScript snippets; cascading drop-down, slide-out menu frameworks; scrolling marquees; and the like. Some of these libraries and templates were offered as freeware or shareware; some were sold as commercial software. Of course, developers couldn't easily prevent end users with the necessary JavaScript, CSS, and HTML in their browser cache from "borrowing" their scripts - it was very common for such developers to find unlicensed versions of their code on Web pages from around the globe - but people had begun to realize that there was some value in the effort involved in making a useful function work as a cross-browser. In fact, one of the purported advantages of Java applets and Flash movies, when they first arrived, was the fact that they closed this loophole and were emphatically not View Source enabled.
Early efforts, however, to leverage JavaScript and CSS to provide a more compelling browser experience - what we then called DHTML - were hampered by the complexity of developing for multiple browsers, each of which had their own interpretation of the Document Object Model and implementation of Cascading Style Sheets. Two major events provided a way out of this complexity: the recognition of a community of practices now referred to as AJAX (itself enabled by the release of compelling competitors to Microsoft's Internet Explorer) and the appearance of a number of open source frameworks for developing AJAX applications.
AJAX
In what is now a seminal article, Jesse James Garrett noted, in February of 2005, a growing phenomenon of using standards-based presentation (XHTML and CSS), the Document Object Model (DOM), the XMLHttpRequest, and JavaScript to generate rich interface Web-based applications. He called this approach AJAX, and issued a call to designers and developers "to forget what we think we know about the limitations of the Web, and begin to imagine a wider, richer range of possibilities" ("AJAX: A New Approach to Web Applications" by Jesse James Garrett).
While many of the raw materials of the AJAX approach had been available for many years - Microsoft first introduced the XMLHttpRequest object in Internet Explorer 5, and it was leveraged in production by Outlook Web Access - it only took off when the approach was validated by inclusion in the Mozilla framework (and thus Firefox) and Apple's Safari browser (itself based on KHTML, the framework used for Konqueror in the K Desktop Environment for Linux). So long as what Microsoft called "remote scripting" was only available in a single browser (Internet Explorer), many developers felt it was unusable in any public application. (It might be acceptable, for some, to dictate browser usage on a corporate intranet, but most were unwilling to try to do so on the public Internet.)
As the user base of the old Netscape 4.x applications waned, and the availability of new platforms rose, developers were emboldened by the relative ease of developing cross-browser standard applications with rich interaction in JavaScript and CSS, and more and more developers started to create AJAX applications. Garrett's essay crystallized this movement and gave it a name. The AJAX meme spread like wildfire, and the essay became so influential, exactly because so much work of this kind was already being done.
Open Source Frameworks
In addition to the AJAX phenomenon, the other major change that supported the new explosion of activity around Web development was the emergence of open source frameworks for AJAX-style development. While the diminishing use of Netscape 4.x (specifically, the acceptance among developers and their clients of the decision to not include complete functionality in Netscape 4.x as a primary requirement) and the relative stability of standards for HTML, CSS, and JavaScript all combined to make developing cross-browser Web applications considerably easier, writing such applications from scratch still required too much repetitive effort. Though the Mozilla-based platforms had adopted an approach similar to Microsoft's remote scripting, there were enough differences to create a barrier to cost-effective and reproducible development. (see Table 1)
The frameworks that evolved abstracted away the messy details (the difference between Internet Explorer's ActiveX-based XMLHttpRequest object and Mozilla's true JavaScript version, for example) and enabled developers to add snazzy AJAX functionality to their Web applications simply by leveraging APIs provided by the framework.
John Eckman is Senior Director of Optaros Labs. and has over a decade of experience designing and building web applications for organizations ranging from small non-profit organizations to Fortune 500 enterprises.
John blogs at OpenParenthesis and you can find him on Twitter, Facebook, and many other social networks: all his online personas come together at JohnEckman.com.
His expertise includes user experience design, presentation-tier development, and software engineering. Prior to Optaros, he was Director of Development at PixelMEDIA, a web design and development firm in Portsmouth NH, focused on e-commerce, content management, and intranet applications. As Director of Development, he was responsible for managing the application development, creative services, project management, web development, and maintenance teams, as well as providing strategic leadership to teams on key client accounts, including Teradyne, I-Logix, and LogicaCMG.
Previously, John was a Principal Consultant with Molecular, a Watertown MA-based professional services and technology consulting firm. In this role he was responsible for leading technical and user experience teams for clients including JPMorgan Invest, Brown|Co, Knights of Columbus Insurance, and BlueCross and BlueShield of Massachusetts. Before becoming a Principal Consultant, he served in a number of other roles at Tvisions / Molecular, including various project lead roles as well as User Experience Manager and Director of Production.
John's technical background includes J2EE and .NET frameworks as well as scripting languages and presentation-tier development approaches, in addition to information architecture, usability testing, and project management. He received a BA from Boston University and a PhD from the University of Washington, Seattle; he completed an MS in Information Systems from Northeastern University in 2007. He lives with his wife and two cavalier spaniels in Newburyport, MA.
Contact John Eckman
Subscribe to AJAX & RIA Journal Email News Alerts
Subscribe via RSS
