Welcome to the new look and feel of Tech Talk. Along with a new look, the Powers That Be have decided to change the name of this column, but we’re still discussing whether I’m a technology diva, full of technobabble or live on the bleeding edge. So, for now, it’s still Tech Talk.
Along with these changes, this columnrepresents another change as well: I’m writing it using Google Docs instead of Microsoft Word. If you’ve never used Google Docs, you might be surprised at how much it feels like using a desktop-based word processor. And that’s because it almost is. Most of the work being done by Docs and similar applications is happening right on your computer.
In the olden days, circa 1995, a Web page (the browser, really) sent data to a server, the server did something with it, and sent a whole new page back to the browser. It’s hard to imagine writing a document in such an environment. Sure, you could type your document into a text box, but you couldn’t make the characters bold or italic, or even change the font.
There were four important developments that allowed browser-based applications (as opposed to Web-based applications, which rely on a server) to occur. The first was Javascript. Lots of people confuse Javascript with Java (and there are Java applets that run in Web browsers, further confusing the matter). Javascript (like Java) is a programming language. But if you want to appear technologically savvy, remember that Javascript is not Java. Very early on, the creators of the Netscape browser realized that HTML (the markup language used to create Web pages) wasn’t enough to create the dynamic experience users wanted. They needed to add some programmability.
Javascript itself is just a programming language, although a very nicely designed one. It doesn’t have any special features that integrate it into the browser. On the contrary, the browser developers had to do two things. First, they had to make it possible for Javascript to run in the browser. In other words, making it possible for Web pages to contain programs and for the browser to run them. The second thing they had to do was make it possible for those programs to make requests of the browser. Nowadays, we call it an application programming interface (API). At the beginning, this API was pretty simple, exposing objects like the current document and the browser window for Javascript to control.
It became clear that, to really make Web pages interactive, a program had to be able to control all the aspects of the appearance and behavior of a Web page. This led to the development of the document object model (DOM). Every element on a Web page is part of a tree that represents the entire document (web page). Javascript, via the DOM API, can manipulate the behavior and appearance of every element in that tree.
At the same time, Web developers were trying to separate the content from the appearance of a web page. The answer took the form of cascading style sheets, which have gone through several revisions. Basically, you can say that a particular part of a Web page is a heading or a paragraph (the <h1> and <p> tags in HTML) and use a separate style sheet to decide what headings and paragraphs look like. The advantage is that you don’t need to have the page content to change its appearance dramatically. The styling characteristics of an element are available for Javascript programs to manipulate via the DOM.
But the problem of sending data to the server and getting a whole new page back persisted. Every page refresh constituted an interruption in the user’s experience, clearly different from the seamless look of a desktop application. It’s interesting that it was Microsoft that developed the next big innovation that finally allowed browser-based applications to become a reality. It’s name? XMLHTTPRequest. Surprisingly, it was first released in 2000 as part of Internet Explorer 5.5.
There’s more to the story, but Word, er, Google Docs, is telling me I’ve reached my limit. Tune in next month, when I’ll discuss the real impact of browsers that run programs.
