When I first started playing with Javascript in the 90s I used it almost exclusively for onMouseOver and onMouseOut events for a clickable pseudo-3d button or image on my first webpages. I also used Javascript with image-maps, onClick events, or to validate input before a form was submitted. But that was about it. In the end I had a small collection of functions, but most of the time, the Javascript code was really just embedded inside the HTML markup, far from any structure or being readable or reusable.

Eventually I began to use Javascript for more extensive tasks. The inline Javascript disappeared and instead of replacing images I now worked with stylesheets and the document object model. I also organized Javascript code in dedicated Javascript files and attempted to make the code as reusable as possible. Some examples included a tree-menu that was populated with values from a database. That was actually before Ajax became a buzz-word and common practice. I had to use several tricks to transport data. On the server side I created a function that initialized a few data exchange variables…somewhat resembling JSON. With other tricks I managed to load more data dynamically, just in time, as you expanded the tree-menu. At that time it was quite an undertaking because Internet Explorer and Netscape/Mozilla had much more issues with each other than today. Although Internet Explorer still doesn’t behave as it should, web development has become much easier nowadays.

Impressed by what could be done with Javascript I once wrote a client-/server chess-game in I think late 1999, using Javascript, PHP and HTML. The Javascript functions would validate a move before it was sent to the server. The exchange of moves as well as (semi-)instant messages between the two players were handled by an invisible frame that was refreshed automatically in a certain interval. This chess program was nothing but a challenge to see if I could do that with nothing but Javascript, PHP and HTML. It all worked well and looked nice, but it really still was nothing but a bunch of Javascript functions.

In the beginning of the new millenium I found that you could actually create much more complex applications with Javascript. By sticking to some conventions and using the concept of prototypes you were able to use Javascript almost like other object-oriented languages. Instead of collecting a bunch of functions that would float around in a text file, you could organize and use them as real objects with real properties and methods. When I discovered this I couldn’t believe that I never used Javascript that way before.

I immediately had that vision to create a framework of reusable components and plugins that follow the same conventions on both the server-side with PHP (at that time it was still PHP4) and the client-side with Javascript. That was the my era of making Javascript go “Enterprise” :) The support of Javascript in IE vs Mozilla was not so much an issue anymore, and I could make the code work on both platforms without tearing my hair out. Not only could I create a neat software architecture in Javascript, but also take advantage of all the events available including key-strokes without getting a problem with code becoming impossible to read or maintain.

I worked many months–in fact closer to two years–on this idea and framework, but I wasn’t the only one. Other companies were faster and published a series of new technologies that were much better and more powerful than my silly unfinished solution. A good part of my own code became somewhat obsolete after learning about JSON and libraries like Prototype and Script.aculo.us. With the new PHP5 release many of my semi-object-oriented workarounds became obsolete. There also was Microsoft who brought their .Net platform onto the market. And Google who began to offer rich and excellent web-applications like Gmail or Google Maps, and released packages like the Google Web Toolkit for developers. I figured it wouldn’t make sense to continue to work with an idea that soon would become completely obsolete with the new wave of technologies. So I dropped the idea of the Javascript/PHP “Enterprise” framework and worked on some smaller Javascript files to explore the power of Javascript as a “real” programming language instead.

I tried to take some of the old game and demo source codes in C and C++ and rewrite them in Javascript. I thought it would be fun to have some nice animations in two or three dimensions. By adding some interaction there was the potential to create some nice Javascript based games. I moved forward well, but the output became a problem. I tried to simulate a virtual “Javascript-screen” and render pixels found in a Javascript screen buffer, but it was way, way too slow. It worked for a static image, but you couldn’t use that for animations at all. Eventually I gave up and focused on Ajax and Java instead… and then I had to put more time into paid graphic design jobs than programming, which I always found much more interesting and fun, but didn’t pay the bills.

A few months ago I discovered how Lee Semel solved the display problem with his version of the old first-person shooter Wolfenstein in Javascript. Size: only 5K! As a “display” he creates XBM images, a monochrome image format that unlike other binary image formats is actually a C-style ASCII text format that can dynamically created with Javascript. I found this solution very impressive, and especially its small size. Unfortunately, this format is not supported by IE or Windows anymore.

But wait, it gets even better. Just recently I discovered Nihilogic, a blog with a focus on Javascript. There you can find Javascript versions of Super Mario Kart (11K), Wolfenstein 3D, 3D Chess, Super Mario (14k) in color! He has a 3D-renderer, a 3D Particle Generator or tools to manipulate images in Javascript. This is just amazing, far beyond anything I dreamed of in my Javascript days.

Instead of XBM images he uses the canvas element that is part of HTML5 and supported by both Opera and Mozilla. Not surprisingly, IE doesn’t support canvas (it doesn’t even support SVG), but there are solutions like ExplorerCanvas to bring the same functionality to IE.

I’m truly impressed by what can be done with a scripting language that essentially started as a simple onMouseOver event. I think I should take some time and play with the possibilities of the new canvas element. Of course SVG and Flash/ActionScript, and Java are good and valid candidates for user interfaces still… but Javascript presents a fun challenge, and it doesn’t require any large frameworks or third party plugins.