The Butt Ugly Weblog

HTML5/CSS3/Javascript is the new x86

Web apps. Widgets. Websites. All dispersed along a line, where at the other end you have static HTML and at the other end you have fully self-contained Javascript applications (widgets), that only perhaps contain a single <script> statement in their HTML. These are the building blocks of Web 2.0; stuff that was growing in the background while everyone else ogled over Google Docs and Wikipedia and oh-my-god-but-what-does-this-all-mean.

Without much ado, the browser has become the operating system. But at least my personal problem has been for a while that Javascript is a really lousy environment to work in: tools pale in comparison to commercial grade Java tools (try to profile your Javascript app - you've only got bad and worse solutions) and the language is, well, gnarly.

But if we treat the browser as the operating system, then is it not logical to treat the Javascript/HTML/CSS environment like a binary interface instead of a programming environment? You can see already how inadequate the environment is by looking at the dozens of libraries that have spawned, such as JQuery, Dojo, Mootools, etc. This all reminds me of my early programming days, when I sweated with the 68000 assembly language on the good ol' Amiga. Everybody wrote their own support libraries at the time, and the most popular became essentially the basis of later operating systems.

So would it be too far-fetched to call the HTML5/CSS/Javascript combo (call it JCH, pronounce like you're coughing) the new x86 assembly language? They're both fairly sucky environments but if that suckiness is hidden by more rich environments and languages on top of them, they can simply become the workhorse on which all major development will occur in the future. And much like most current programmers don't understand about x86 assembly language, perhaps future programmers won't know diddly about Javascript closures?

The logical next step would therefore be to port well-known languages to create JCH instead of their own bytecode or assembly. Not surprisingly, these tools already exist: Google Web Toolkit creates JCH from Java; ScriptSharp from C# and Pyjamas from Python. And who web developer hasn't used an HTML editor ever to design their HTML/CSS page? Also, look at how Java Virtual Machines turned from the sloths they were into the performance monsters they are today - and then consider that all those lessons are almost directly applicable to Javascript engines. The development of JS engines in Chrome and Safari has been mindboggling over the past couple of years, just the same way JVM performance and x86 performance has beaten all expectations.

Perhaps the secret to the next web (and if you call it Web 3.0, I will break your legs) is the realization that there's now, finally, a unified binary interface for all developers which is already deployed on every desktop. It's, again, going to be the developer playground just like the original web was.

We ain't seen nothing yet.