Scripting Languages and the Web

By Sterling “Chip” Camden
Contributing Writer, [GAS]

When Tim Berners-Lee first proposed the “Mesh” (later renamed to the World Wide Web) to CERN back in 1989, the concept was much simpler than it has become today.  The problem Berners-Lee sought to solve was how to establish links between the massive number of related documents generated world-wide by CERN projects, especially the LHC.  So he focused primarily on hyperlinked text.  In a section of the proposal titled “Bells and Whistles”, we read:

Storage of ASCII text, and display on 24×80 screens, is in the short term sufficient, and essential. Addition of graphics would be an optional extra with very much less penetration for the moment.

Never mind embedded videos or Ajax-driven interactivity.  You request a page, you get a page.  But in the section titled “Live links” we get a glimpse of the web’s future:

Hypertext allows documents to be linked into “live” data so that every time the link is followed, the information is retrieved. If one sacrifices portability, it is possible to make following a link fire up a special application, so that diagnostic programs, for example, could be linked directly into the maintenance guide.

Server-side scripting

In usage, it soon became apparent that the more “live” the data, the more useful the site.  Nevertheless, it took a few years for server-side programming to standardize on the Common Gateway Interface (CGI), which uses environment variables and standard input/output to transfer data to/from a separate executable (or later, an embedded module of the web server).  All those who have written CGI programs in C or Bourne Shell please raise your hands (if you still can).  The Perl language soon proved to be a far superior alternative to either of these for CGI programming — partly because it combined some of the best features of both, but mostly because of its advanced capabilities for manipulating strings and regular expressions.

But using any of these languages requires you to explicitly output the entire returned page, even the static parts.  Web developers wanted to be able to write plain HTML, and add scripting code where needed for the dynamic bits.

PHP arose as an answer to that problem.  Any content in a PHP page that isn’t within the <%php and %> delimiters is simply output as-is, within the execution context of the code that is within those delimiters.  That code is Perl-like — but much simpler and less consistent, betraying a history that contains more evolution than intelligent design.  Hundreds of inconsistently named base functions in a single, global namespace often make finding the right way to do something a lengthy exercise in searching php.net.  Yet, PHP powers many of the most visited sites on the web, including Wikipedia, Yahoo!, Facebook, and millions of WordPress blogs (including this one), perhaps because of its simple (though numerous) functions to access back-end databases.

I shouldn’t fail to mention a couple of similar but less widely used alternatives:  JavaServer Pages (JSP) and ColdFusion’s CFML.  Both allow the insertion of special tags into an HTML-like page to direct the generation of dynamic web content.

Active Server Pages (ASP) provides a capability similar to PHP, but for Microsoft IIS Servers.  The <% and %> delimiters demarcate script embedded within HTML.  By default, the scripting language is VBScript, though JScript (an implementation of JavaScript) and PerlScript (derived from Perl) can be used instead.  The syntax of VBScript is, as the name implies, much more like Visual Basic than like C or Perl — which means that it’s simpler and less expressive than even PHP.

ASP.NET represents a stark departure from the scripting model of web design.  Development of web pages more closely resembles desktop GUI development, and the result is a compiled assembly rather than a runtime-interpreted script.  Any .NET CLR language can be used for the code behind (for the vast majority, that means Visual Basic .NET or C#).  While this model may be more comfortable for programmers who grew up on Visual Basic (assuming that’s even possible), I find the number of things that are done for you behind the curtain to be a little unsettling.

Ruby also provides the ability to embed code in HTML, via eRuby.  Several such templating systems are available for Python as well.  Both of these languages offer excellent support for standard CGI programming, too.

A number of web frameworks have been built on top of these languages, often employing the model-view-controller design pattern.  Some of the more popular include Ruby on Rails (for Ruby), Django (for Python) and (still in preview) ASP.NET MVC for ASP.NET.  These frameworks offer the advantage of nearly eliminating duplicated effort between projects that more or less follow the standard pattern.

Client-side scripting

Generating all your web content on the server side may give you a nice sense of control, but it sure makes for some clunky user interface if every update has to be achieved by requesting a whole new page.  To make pages more interactive, you want to be able to direct the browser’s actions by embedding scripts within the page that is sent to the client.

Brendan Eich invented the JavaScript language for this purpose, and it was first included in Netscape back in 1995.  Despite its name, this language is only superficially similar to Java — it’s really a much more dynamic and functional language than Java could ever be.  It started out in life making little bits of web pages more interactive — for instance, if you didn’t need to go to the server to validate a field, you could alert the user as soon as they modified it.

Internet Explorer added scripting capabilities in two available languages: VBScript and JScript.  The latter was similar to JavaScript, with just enough differences to drive a web developer crazy.  In recent versions, Internet Explorer has moved closer towards more standards compliance, but there are still enough differences to evoke the frequent “Curse you, IE!”

The standard for the JavaScript language is properly called ECMAScript, after the Ecma International organization to whom Netscape passed control of the standardization process for JavaScript.  Most modern browsers now support some level of the ECMAScript standard.

One of the more exciting developments in JavaScript in recent years has been the rise of AJAX, which stands for Asynchronous JavaScript And XML (although XML need not actually be involved).  The key to this technique is the ability in JavaScript to send an HTTP request to the web server and retrieve a result without reloading the current page in the browser.  Then the JavaScript can evaluate what it retrieved, and apply any necessary changes to the page without a full repaint.  Originally, the data was always returned as XML (hence the X), but recent refinements include returning JSON instead — a format that is easily converted into JavaScript objects (but not without security concerns).

I love JavaScript as a language.  When I write something in JavaScript, I feel happy for some reason.  It’s a light, agile, but powerfully dynamic scripting language.  However, I’ve often wondered why more browsers don’t support multiple scripting languages.  No, I’m not a VBScript fan (far from it), but wouldn’t it be nice to be able to script both the client and server side in Ruby, for instance?  Unfortunately, for any new client-side scripting language to become viable, it would first have to be implemented by all of the major browsers.  And I’m afraid the script for that dream is:

alert("They've got too much to do already");

This post is Part Four in a series on the history of programming languages.  Here are links to the previous installments: