It’s good to be back. I let the old blog field lie fallow in order to focus on work in Ecma TC39 (JS standards), Firefox 3.5, 3.6 and 4; and recently on a newproject that I’ll blog about soon.
In the mean time [UPDATE and in case the embedded video fails], here’s the video link from my JSConf 2010 surprise keynote in April. Highlights include:
What would happen in a battle between Chuck Norris and Bruce Campbell
Clips from Netsca^H^H^H^H^H^HEvil Dead 2 and Army of Darkness
Discussion of where JS has been and what lies in its immediate future
True facts:
I did meet John McCarthy of LISP fame in 1977
My haircut was influenced by Morrissey’s (hey, it was the late ’80s)
It seems (according to one guru, but coming from this source, it’s a left-handed compliment) that JavaScript is finally popular.
To me, a nerd from a tender age, this is something between a curse and a joke. (See if you are in my camp: isn’t the green chick hotter?)
Brendan Eich convinced his pointy-haired boss at Netscape that the Navigator browser should have its own scripting language, and that only a new language would do, a new language designed and implemented in big hurry, and that no existing language should be considered for that role.
I don’t know why Doug is making up stories. He wasn’t at Netscape. He has heard my recollections about JavaScript’s birth directly, told in my keynotes at Ajax conferences. Revisionist shenanigans to advance a Microhoo C# agenda among Web developers?
Who knows, and it’s hard to care, but in this week of the tenth anniversary of mozilla.org, a project I co-founded, I mean to tell some history.
As I’ve often said, and as others at Netscape can confirm, I was recruited to Netscape with the promise of “doing Scheme” in the browser. At least client engineering management including Tom Paquin, Michael Toy, and Rick Schell, along with some guy named Marc Andreessen, were convinced that Netscape should embed a programming language, in source form, in HTML. So it was hardly a case of me selling a “pointy-haired boss” — more the reverse.
Whether that language should be Scheme was an open question, but Scheme was the bait I went for in joining Netscape. Previously, at SGI, Nick Thompson had turned me on to SICP.
What was needed was a convincing proof of concept, AKA a demo. That, I delivered, and in too-short order it was a fait accompli.
Of course, by the time I joined Netscape, and then transferred out of the server group where I had been hired based on short-term requisition scarcity games (and where I had the pleasure of working briefly with the McCool twins and Ari Luotonen; later in 1995, Ari and I would create PAC), the Oak language had been renamed Java, and Netscape was negotiating with Sun to include it in Navigator.
The big debate inside Netscape therefore became “why two languages? why not just Java?” The answer was that two languages were required to serve the two mostly-disjoint audiences in the programming ziggurat who most deserved dedicated programming languages: the component authors, who wrote in C++ or (we hoped) Java; and the “scripters”, amateur or pro, who would write code directly embedded in HTML.
Whether any existing language could be used, instead of inventing a new one, was also not something I decided. The diktat from upper engineering management was that the language must “look like Java”. That ruled out Perl, Python, and Tcl, along with Scheme. Later, in 1996, John Ousterhout came by to pitch Tk and lament the missed opportunity for Tcl.
I’m not proud, but I’m happy that I chose Scheme-ish first-class functions and Self-ish (albeit singular) prototypes as the main ingredients. The Java influences, especially y2k Date bugs but also the primitive vs. object distinction (e.g., string vs. String), were unfortunate.
Back to spring of 1995: I remember meeting Bill Joy during this period, and discussing fine points of garbage collection (card marking for efficient write barriers) with him. From the beginning, Bill grokked the idea of an easy-to-use “scripting language” as a companion to Java, analogous to VB‘s relationship to C++ in Microsoft’s platform of the mid-nineties. He was, as far as I can tell, our champion at Sun.
Kipp Hickman and I had been studying Java in April and May 1995, and Kipp had started writing his own JVM. Kipp and I wrote the first version of NSPR as a portability layer underlying his JVM, and I used it for the same purpose when prototyping “Mocha” in early-to-mid-May.
Bill convinced us to drop Kipp’s JVM because it would lack bug-for-bug compatibility with Sun’s JVM (a wise observation in those early days). By this point “Mocha” had proven itself via rapid prototyping and embedding in Netscape Navigator 2.0 , which was in its pre-alpha development phase.
The rest is perverse, merciless history. JS beat Java on the client, rivaled only by Flash, which supports an offspring of JS, ActionScript.
So back to popularity. I can take it or leave it. Nevertheless, popular Ajax libraries, often crunched and minified and link-culled into different plaintext source forms, are schlepped around the Internet constantly. Can we not share?
One idea, mooted by many folks, most recently here by Doug, entails embedding crypto-hashes in potentially very long-lived script tag attributes. Is this a good idea?
Probably not, based both on theoretical soundness concerns about crypto-hash algorithms, and on well-known poisoning attacks.
A better idea, which I heard first from Rob Sayre: support an optional “canonical URL” for the script source, via a share attribute on HTML5 <script>:
If the browser has already downloaded the shared URL, and it still is valid according to HTTP caching rules, then it can use the cached (and pre-compiled!) script instead of downloading the src URL.
This avoids hash poisoning concerns. It requires only that the content author ensure that the src attribute name a file identical to the canonical (“popular”) version of the library named by the shared attribute. And of course, it requires that we trust the DNS. (Ulp.)
This scheme also avoids embedding inscrutable hashcodes in script tag attribute values.
Your comments are welcome.
Ok, back to JavaScript popularity. We know certain Ajax libraries are popular. Is JavaScript popular? It’s hard to say. Some Ajax developers profess (and demonstrate) love for it. Yet many curse it, including me. I still think of it as a quickie love-child of C and Self. Dr. Johnson‘s words come to mind: “the part that is good is not original, and the part that is original is not good.”
Yet here we are. The web must evolve, or die. So too with JS, wherefore ES4. About which, more anon.
Firefox 3 looks like it will be popular too, based on space and time performance metrics. More on that soon, too.
Mozilla is a huge project, now cursed with success. It did not start that way. To think about where to go, we should mull over how we got here.
Over the years since the first major roadmap, I’ve tried to steer the project toward the shortest path to the next port of call that was not going to leave us cannibalizing the ship and ourselves, for want of supplies and fresh crew (more contributors). Doing this without running out of stores and existing crew along the way required good luck, along with a hard-nosed attitude about what to keep and what to throw overboard.
Some paths were long, for instance the reset in late 1998 around Gecko, XPCOM, and an XPFE. This was a mistake in commercial software terms, but it was inevitable given Netscape management politics of the time, and more to the point, it was necessary for Mozilla’s long-term success. By resetting around Gecko, we opened up vast new territory in the codebase and the project for newcomers to homestead.
Firefox changed everything for us, for the industry, and most important, for browser users. We have heard repeatedly from people who feel as though their computers are friendly tools again, instead of spyware-ridden zombies infected via the default browser. These folks now see the web as fun and empowering, not static or even degrading over time.
Now, having given the default browser a little competition, and helped advance the causes of simple yet powerful UI, web content standards, and user innovation toolkits and networks such as XUL extensions, their own extensions (e.g., GreaseMonkey’s user scripts), and AJAX/DHTML/whatever new-style web apps, we must journey again to an even better place, with another hundred million downloads, and even more users worldwide.
We see the Web outpacing traditional desktop and operating system software development. Great web services and mashups abound in the new, over-hyped era. In spite of the hype, these new Web apps usefully point to the immense, hardly-realized value of people connected by the Internet.
Firefox is “just a browser”, but it has an evolving role to play in this world. The browser is a platform, as threatened in 1995 and dismissed with the death of Netscape. Yet every web app is hobbled by stagnant content standards from five or ten years ago. There is no good reason for this.
There is no reason why browsers should not innovate, along with plugins, applications, and operating systems, to support modern hardware-assisted graphics, dynamic programming languages, and richer content types. The reach of the web still favors the browser over any particular OS or non-Web platform.
Therefore in order to innovate nearer to “Web time” on the Firefox user interface and extension fronts, we propose to develop the front end of Firefox 2 and the platform for Firefox 3 concurrently, with Firefox 2 releasing in less than a year. The details have been drafted in a product roadmap that Chris Beard has written. (Many of you know Chris as an active driver and product manager in the project since Firefox 1.0 launched. He’s been a huge help, and I’m very grateful for his contribution here.)
The back end code, Gecko and other modules such as the JavaScript engine, will occupy the Mozilla source tree “trunk” development during the Gecko 1.9 milestone, which is already under way. The major efforts are to:
rearchitect our rendering layer to support hardware-accelerated graphics;
selectively improve architecture in the layout engine, to fix longstanding bugs;
improve web author productivity with better content languages and debugability;
move XUL to the next level in concert with the rendering and programming improvements;
make XULRunner the embedding vehicle for Firefox and all modern XUL applications.
Mike Shaver and I have gathered together the requirements and plans of many folks in a new platform roadmap.
These roadmap drafts are rough, and although much work has already been done in the directions outlined by these documents, much more remains, and our plans will change as needed. But plan we must, perhaps more than ever in the project’s history. We have reached the big time now, and there is no turning back or coasting along.