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.
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.
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.
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.
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:
- The Early History of Programming Languages
- An introduction to object oriented languages
- The ascent of scripting languages