Book Image

Object-Oriented JavaScript

By : Stoyan Stefanov, Stoyan STEFANOV
Book Image

Object-Oriented JavaScript

By: Stoyan Stefanov, Stoyan STEFANOV

Overview of this book

Table of Contents (18 chapters)
Object-Oriented JavaScript
About the Author
About the Reviewers
Built-in Functions
Regular Expressions

A Bit of History

Initially, the Web was conceived as a collection of static HTML documents, tied together with hyperlinks. Soon, as the Web grew in popularity and size, the webmasters who were creating static HTML web pages felt they needed something more. They wanted the opportunity for richer user interaction, mainly driven by desire to save server round-trips for simple tasks such as form validation. Two options came up: Java applets (they failed) and LiveScript, which was conceived by Netscape in 1995 and later included in the Netscape 2.0 browser under the name of JavaScript.

The ability to alter otherwise static elements of a web page was very well received and other browsers followed suit. Microsoft's Internet Explorer (IE) 3.0 shipped with JScript, which was a copy of the same language plus some IE-specific features. Eventually there was an effort to standardize the various implementations of the language and this is how ECMAScript (European Computer Manufacturers Association) was born. Today we have the standard, called ECMA-262, and JavaScript is just one implementation of this standard, albeit the most popular one.

For better or for worse, JavaScript's instant popularity happened during the period of the Browser Wars I (approximately 1996-2001). Those were the times of the initial Internet boom when the two major browser vendors—Netscape and Microsoft, were competing for market share. These two vendors were constantly adding more bells and whistles to their browsers and their versions of JavaScript. This situation, together with the lack of agreed-upon standards brought a lot of bad opinions of JavaScript. More often than not, development was a pain: you write a script while working in one browser. Once you're done with development, you test in the other browser and it simply doesn't work. At the same time, the browser vendors were busy adding features, but falling behind on providing proper development tools.

Browser vendors were introducing incompatibilities that annoyed the web developers, but this was only one part of the problem. The other part of the problem were the web developers themselves, who were adding too many features to their web pages. Developers were eager to make use of every new possibility that the browsers provided and ended up "enhancing" their web pages with things like animations in the status bar, flashing colors, blinking texts, shaking browser windows, snowflakes, objects stalking your mouse cursor, and so on, often at the expense of usable pages. These various ways to abuse JavaScript was the other reason why the language got its bad reputation. This caused "the real programmers" (developers with background in more established languages such as Java or C/C++) to dismiss JavaScript as nothing but a toy for front-end designers to play around with.

The JavaScript backlash caused some web projects to completely ban any client-side programming and trust only their predictable and reliable server. And really, why would you double the time to deliver a project and spend this additional time debugging problems with the different browsers?