[Why] Is JavaScript Popular?

When one has to extend the experience of web browsing beyond what comes out of browser-makers, a key programming language that everyone seeks refuge in is JavaScript.

In my previous post, I wrote about Google Apps Script that enables customization and integration of Google Documents and Products through JavaScript that is executed on the server, in the cloud.

Now, with this additional flexibility at the server, you can expect more adaptation of product and computational functionality by Internet application users themselves by using JavaScript.

The use that JavaScript can be put both in providing Rich Internet Applications — e.g., Google's Gmail — on the client side and in customizing server side logic in the form, for example, of Google Apps Script will only increase the popularity of JavaScript. Even if other languages -- Java, C++, Ruby on Rails, etc. -- are used for implementing server-side functionality, there is a certain homogeneity that is brought about by the use of JavaScript on both sides.

Scripting for the Google Web

Not too long ago, Google announced the availability of scripting for the web for Google Apps Standard Edition customers too. If you play with a little bit, you will begin to see the power of JavaScript in its ability to provide meaningful automating capability to web documents, particularly as it is being promoted by Google.

A very interesting application in automating — screenscraping as it is called by the author, Tony Hirst — can be studied here:
Screenscraping With Google Spreadsheets App Script and the =importHTML() Formula.
The author illustrates how council elections results of the town of Lichfield, UK, can be analyzed using Google App Script.

While the Internet is well known to be a great equalizer, it is also true that it also a great personalizer, thanks to scripting everywhere -- at the [browser] client and in the [server in the] cloud.

Microsoft has done some good things for the web browser industry too.

For all the flak that Microsoft has had to take in recent weeks on IE6, it was heartening to learn when Crockford, Yahoo!'s JavaScript Architect, mentioned yesterday that it was Microsoft's contribution to the Document Object Model, that all HTML elements were made script-able, that has provided lasting value so far, for the browser platform.

A couple of other noteworthy points:

1. "With Ajax, the source of innovation shifted from the browser makers to the web developers. Ajax libraries."
2. "Ultimately, we should seek to replace the DOM with an Ajax-influenced API."

Crockford is an engaging speaker who sprinkles his talk with very effective humor. This particular talk was how the Ajax technology came about. You can review all of his talk, including video & transcripts, on the Yahoo! User Interface Blog site.

As I have listened to Crockford on the 4 out of the 5 sessions so far, I cannot but come away with the feeling that many of the mistakes of the past would not have been committed in the latest specification.

The future of web-based applications is definitely brighter.

HTML 5, Google I/O and Evolution of Applications.

Earlier this week, I had occasion to attend the Google I/O conference. This blog post is more reflective than a factual report on the event. (For factual reports, e.g., see Google: The browser is the computer, Google Wave: A new kind of mega-application).

In the beginning, e.g., with the ENIAC, people programmed in 1s and 0s. The initial tedium was avoided by the invention of assembly language programming. The primitives that the programmers dealt with included registers, memory and i/o in the form of tapes and disks.

Subsequently, there were several high level programming languages invented, stack machines supported block structured languages. For a very long time, the stack machine seemed sufficient, and even the concept of classes were implemented on top of the stack machines. The primary commercial successes in this arena are C/C++ and Java and their variants.

In this conference, the primary message appears to be that the communication content, in Google Wave, is modeled as hosted XML documents, and the primitives that a programmer uses within a browser are the ones that manipulate the document object model (DOM); and, there are several new primitives, i.e., tags like canvas, video, audio, etc., built natively into HTML 5. (A good introduction to the model methods is available at HTML DOM Primitives and XML DOM Primitives). Thus, while the stack machine continues its reign, additional functionality is being expected of the platform in terms of the DOMs.

To promote concurrency in applications, the concept of Web Workers is available in HTML 5.

What happened in the last 50 or so years? Now, the basic computational platform (within a browser) is one that supports very granular manipulation of pieces of communication that is relevant among human beings (and computers), rather than registers, stack, etc. This is good; it is easy to see progress.

Now, in the future, why would anyone want to build non-browser applications? Particularly since JavaScript engines seem to be gathering better performance all the time? Chrome's V8 JavaScript engine is available as open source. (There is a separate web page (v4) to assess V8's performance of a browser on your computer).