Javascript for the BPM Developer: Beginnings

Bad Ass Beginnings
Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInShare on RedditShare on Tumblr

The Browser

The early 90’s .. the web was nice and static. No interactivity. The browsers, Netscape Navigator and Microsoft IE, were C++ applications created to connect to http servers to render and display .html pages. Netscape was first to bring some interactivity by adding Livescript which,  due to the marketing department, got renamed to JavaScript (the only relation with Java being it sounded cool in 1995 and Netscape wanted to push their own Java based server architectures).

Netscape Navigator

Figure: Netscape Navigator

This new JavaScript proved to be a good idea.  No longer you had to use a 14.4Kb modem to send a form to the server and then wait 30sec for the response to say.. oops zip code is mandatory. JavaScript allowed access to the internal C++ DOM objects used by the Browser Engine to render the page. It could validate the form elements before sending it to the server. A brave new world..

Microsoft, not to be left behind, introduced not one but two integrated languages vbscript and Jscript. So there was a lot of diversity and little consistency.. reasons for which a standard had to be created, and since no corporation gives away free names (aka the JavaScript brand), the standard was intuitively named ECMAScript or ECMA-262. Basically all we call JavaScript today is just a proprietary (more or less) implementation of the ECMA-262 standard.

Browsers are just C++ applications, JavaScript in each browser is an implementation of ECMA-262 standards, and its point is to allow access and manipulation of internal C++ DOM Objects, which in turn are finally displayed on screen.

Browser’s Render Flow

strongly suggest you go through this article:  http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/ to get a thorough understanding of how browsers work.

Browser Rendering Flow

Figure: Rendering Engine Basic Flow

Basically a browser like Chrome will have a Rendering Engine (WebKit), JavaScript Engine(V8) and many other components we are not focusing on.  The important aspect for us is that it takes a .html document, it parses it into C++ Objects (DOM Tree) it then gives layout information to this Tree and constructs a Render Tree which gets finally painted on screen. What you’ll see on screen is no longer .html but DOM Tree elements.

Webkit rendering flow

Figure: WebKit main flow

I’m stressing this point, because the JavaScript Engine(V8) has access to update and modify these DOM Tree elements. When we work with JavaScript we do not modify the original .html but we work with whatever the browser has in the DOM Tree. And even if initially the DOM Tree maps very well the .html file, once the first script is run, it can dramatically change the structure of the DOM.

This is also an important point to remember when considering where to embed scripts. If you embed a script in the header of the .html, the DOM structure for the rest of the file it is not yet constructed. For example consider you have a script that says all <p> elements are to become red. If you have

<p>First Paragraph</p>
<script>
$(‘p’).css(‘color’,’red’);
</script>
<p>Second Paragraph</p>
only the First Paragraph will be affected. Because once the Parser reaches the script it automatically runs it.. And when it asks for all <p> it actually looks in the current DOM Tree which at that point only contains the First Paragrah , since the second one was not yet reached by the Parser and does not exist in memory.

When we work with JavaScript we do not modify the original .html but we work with whatever the browser has in the DOM Tree at that precise moment.

The DOM Tree

After mentioning it so much is time to take a closer look to the DOM (actually short for Document Object Model). Our .html file is being parsed by the Browser Engine character by character. Each relevant element (once closing tag is found) becomes a C++ DOM element. The root of the tree is the “Document” object. If no scripting is involved the DOM has almost one-to-one relation to the markup. For example:

<html>
<body>
<p>
Hello World
</p>
<div> <img src=”example.png”/></div>
</body>
</html>

This markup becomes:

DOM Tree

Figure: DOM Tree of the example markup

The DOM is the programming interface for the HTML mark-up. It allows us via scripts to modify the document structure, style and content.The DOM provides a representation of the document as a structured group of nodes and objects that have properties and methods. Nodes can also have event handlers attached to them, and once that event is triggered the event handlers get executed. Essentially, it connects web pages to scripts or programming languages.

I think the best explanation is done by MDN Document Object Model Introduction Please take the time to go through it.

For example, the W3C DOM specifies that the getElementsByTagName method in the code below must return a list of all the <P> elements in the document:

paragraphs = document.getElementsByTagName(“p”);
// paragraphs[0] is the first p element
// paragraphs[1] is the second p element, etc.
alert(paragraphs[0].nodeName);

The DOM is a programming interface, providing a representation of the document as a structured group of nodes and objects that have properties and methods.Though accessed using JavaScript, the DOM is NOT part of it and it can be used by other languages, though this is much less common.

Now, every browser is just an application, created by specific businesses (with teams, managers, marketing and so on) with their own goals. And each wanted to impose their own implementation on the market. So initially the DOM API could vary quite substantially from browser to browser (Netscape Navigator, IE, Opera .. ). This made life for web developers in the 90’s and early 00’s a pain.

What gave JavaScript a bad reputation was not the language itself but the inconsistent API offered by each browser. You would wholeheartedly prefer not to touch any of that sensitive IE6 scripting, since it could crush so easily and be such pain to debug.

Fast forward today, we have a stable W3C DOM standard followed by most modern browsers, and whatever inconsistencies left ( since the list of browsers with the addition of the mobile devices has grown significantly ) are dealt with a base layer library  (like Dojo, jQuery, Prototype ..) which expose a consistent and easy to use API for manipulating the DOM no matter the browser.

So instead of doing document.getElementById(id) you can just $('#'+id) or dojo.byId(id) and be sure it’s consistent everywhere.

Yet, I feel it is still strongly beneficial to have a grasp on the most relevant DOM elements and API’s:

MDN DOM Introduction
MDN DOM Examples
MDN DOM Interface

Short example of interacting with the DOM API:

<!DOCTYPE html>
<html lang=”en”>
<head>
<title>width/height example</title>
<script>
function init() {
var arrImages = new Array(3);

arrImages[0] = document.getElementById(“image1”);
arrImages[1] = document.getElementById(“image2”);
arrImages[2] = document.getElementById(“image3”);

var objOutput = document.getElementById(“output”);
var strHtml = “<ul>”;

for (var i = 0; i < arrImages.length; i++) {
strHtml += “<li>image” + (i+1) +
“: height=” + arrImages[i].height +
“, width=” + arrImages[i].width +
“, style.height=” + arrImages[i].style.height +
“, style.width=” + arrImages[i].style.width +
“<\/li>”;
}

strHtml += “<\/ul>”;

objOutput.innerHTML = strHtml;
}
</script>
</head>
<body onload=”init();”>

<p>Image 1: no height, width, or style
<img id=”image1″ src=”http://www.mozilla.org/images/mozilla-banner.gif”>
</p>

<p>Image 2: height=”50″, width=”500″, but no style
<img id=”image2″
src=”http://www.mozilla.org/images/mozilla-banner.gif”
height=”50″ width=”500″>
</p>

<p>Image 3: no height, width, but style=”height: 50px; width: 500px;”
<img id=”image3″
src=”http://www.mozilla.org/images/mozilla-banner.gif”
style=”height: 50px; width: 500px;”>
</p>

<div id=”output”> </div>
</body>
</html>

Browsers are mainly applications for parsing .html / .css / .js text resources to render them in a nice and consistent manner. JavaScript was created to allow scripted manipulation of the DOM. The DOM is the interface that the C++ Browser Engine reveals to the outer world. Modifying it will directly impact what is painted on screen.

The browsers are everywhere, JavaScript is now the defacto language of the web and is expanding beyond its initial purpose  (see Node.js, or exciting projects like Espruino ), carried by its flexibility and event driven heritage.