I know you've been working with it and writing about it for much, much longer than I have. What drove you to the language from the start?
That seems like so long ago though.
That sounds really familiar.
If you just use the good parts which he writes about in his book, you know that's just the beautiful stuff and it's a pretty elegant language.
It seems to fit pretty well with how the XML community has treated the DOM as well, thinking "Okay, we have this model but programming is a real pain and there are all these other models for processing and consuming and producing XML that have nothing to do with the DOM except that it's there." They don't have to worry about it so much. It's just a model that's there. I wonder if his comment comes from the idea that the DOM is there and we know how to work with it, but it's not a pretty thing.
I think that was Crockford's point; he's limiting his comments to the language itself—not the client-side binding to the DOM. He's talking about there's a few warts on the language because really it was produced back in early dot-com boom days. Brendan Eich had serious deadlines when he was first getting this language out; some of that is reflected in some unfortunate choices that have persisted, but overall for considering how quickly the first version of the language was put together it's been remarkably appropriate for what it's used for—the DOM and XML. The history of that was kind of strange too. As I recall, the DOM started being defined specifically for web browsers and HTML and then all the XML people kind of took over and then grew unwieldy and huge and expanded to encompass CSS and all sorts of things.
The history of web standards in a nutshell there.
They grew until they could handle XML; that's a whole other topic. [Laughs] But we probably shouldn't go there; I'll say things I'll regret about XML.
I kind of didn't get it and dismissed it and didn't cover it you know. It's not standard; the 4th Edition I was really focused on web standards. Finally we were emerging from the dark days of browser incompatibilities and there was a DOM and I was really focused on "This is the standard and I'm sticking to it." I missed out on that one because it actually has been around since 2001 or 2002. Ajax—it took four years or something of no one doing it and then all of the sudden, yeah Google pioneered it and got the catchy acronym for it and all of the sudden it was everywhere.
That was sort of the time when Netscape came out on the wrong side of the web standard trying to push things too much themselves, you know. Usually we think of Microsoft as the one evolving incompatibly; but Netscape 4 was a weird time.
And XML, which is—[Laughs]—I assume you're talking about XUL.
I'm talking about XUL.
I remember thinking that was pretty cool when Mozilla announced it. I never really did that much with it; I played around with it some and got hung up on "XML is not just a language to be describing things in." I use it all the time for writing books. It's a text-markup language and that's what it was created for and everyone tries to cram it into making a programming language out of it. XSLT for example I think is an abomination.
It's a Scheme with an uglier syntax.
The version of COM? XPCOM?
You're mostly blocking for user events and network events and things like that.
Just for the size of Ajax libraries and visual effects libraries and stuff that people are using now. I think we've reached that stage where people are programming in the large without tools for doing it.
The lack of an include mechanism or namespaces perhaps?
They talk about evolutionary programming. You can start with your existing code, run it in ES4 and as it grows you start adding types here and there and evolve your objects so that some of the properties subtype, some don't necessarily. They're doing amazing stuff. You read the spec and it's like "Yeah, how are they ever going to implement that?" but they are plugging away at implementations and they've got a number of different browser vendors all talking about it and working on implementations I gather, so it's going to be exciting if it comes out.
When you talk about compatibility I presume you're talking about source compatibility because talking about binary compatibility probably doesn't apply in this case.
Right; it doesn't apply to a scripting language like that. They're working quite hard to insure that the phrase you hear a lot—monitoring the mailing list—is "we can't break the web", so when browsers come out supporting this new version of language they have to continue to run all the legacy codes that's out there.
How tied-in do you think this is to HTML 5 and the WhatWG group? Are they all intertwined or are they kind of separate? How does that work?
I was monitoring that for a while and sort of dropped that and started monitoring the ES4 mailing list pretty closely and have stopped monitoring the HTML 5 stuff as much. I don't hear any discussion in the ES4 mailing list; no one is talking about HTML 5 at all. As far as I know there isn't really overlap in the people working on it, although there's surely overlap between the companies so there must be some sort of coordination but no one is talking about language features that are required to implement HTML features or anything.
Barring fragmentation of course; if there's no standard way to access a file system everyone needs to invent his or her own....
That's the nice thing about Lisp; you can invent your own control structure or your object system but the problem with that is everyone will invent his or her own object system and control structures.
They donated part of their virtual machine to Mozilla as well.
That's right; that should be interesting. I haven't followed carefully what the benchmarks are of that or anything but I imagine it will be a nice performance gain.
My understanding of it is too. Sometimes I'm a virtual machine guy. I haven't looked at Tamarin in any detail, but it adds some really unique features like just-in-time compilation, dynamic recompilation—it's hard to say those two words together—some interesting technologies you see from projects like Smalltalk and Strongtalk and the modern JVM and CLR.
There are some real benefits.
Right; hopefully a very robust and fast interpreter.
Even in the case of Flash we're still talking about a security model tied to possibly un-trusted code running on the client-side where you wanted a very strict sandbox. You don't necessarily want unfettered file system access for one; you may not want file system access for another.
I certainly would hope that browser vendors would not go include a file system module in the web browser.
Right. It seems like what I hear from you—and please correct me if I'm mischaracterized you or ECMA Script here—it sounds like a lot of the evolution of the language is still within the context of the browser and its security sandboxing.
Certainly the people working on ES4 are well aware of the browser content that you know will sort of be a primary focus, but I think they've also pulled out the stops and decided to create a really, really good and state-of-the-art programming language. The discussions I see going on about ES4 and the mailing lists I monitor don't seem particularly tied to the browser, although security debates do pop up and those are implicitly browser-centric.
It seems like an interesting creative tension to me though; if you're thinking "Our main use and our main driver and our main popularity has been this particular model" which imposes these constraints, but obviously the success of things, such as Mozilla and even ActionScript, to some degree demonstrate that this is an actual programming language. You can write a 1,000-page book on it for example, which I wouldn't do for CSS. This demonstrates that there is a real programming language. I think Douglas Crockford would say "There is a there there." As ugly as some of the parts may be—this is a quote you gave earlier, there is something nice in there. That creative tension between building something that's still viable for its core purpose but allowing it to evolve outside of that is interesting to me from a language design standpoint.
I haven't played with the reference implementation much but it does seem like—they have kept compatibility but ES4 really does feel like a brand new language. From my perspective as a writer, it's going to be a brand new book. To document it forever remains to be seen of course as to how long it takes before it's out there on the web widely enough that people can start using it, so this book may not have to happen right away.
That might not be a good comparison because Java generics—I don't know a lot of people who consider that a great implementation. You have a debate in the Java community; I suppose you can probably talk about this even better than I can but anything that takes this much to explain and understand and has these exceptions in it—not the Java exceptions but exceptions to the [model]—that's not a great feature.
Is this something they can deploy on a fairly quick basis?
The argument there has always seemed to mean "We can't break the web" and they're talking about the dark web, all the intranets in the world where you can't necessarily see the code.
I spend my days writing about languages more than I spend programming them. It's been a while since I've done programming in the large that this is—focused on that, so I don't feel a strong need for my day-to-day work to have this language. As a computer geek it looks like a really cool language; you know it's done amazing stuff with types like I said, very interesting to work with name spaces as well, so it just looks like it would be a fun language to learn and to start using. It's not like there are specific features that are going to make my job easier.
No one knows what the great new libraries or idioms are going to be yet.
Yeah; that has not shaken out yet.
In my experience that usually takes somewhere between two and five years after a major release of a language or platform before people start saying "This way works, this way doesn't", and all the designers slap their foreheads and say "Why didn't we think of that five years ago?"
That's very true; I have long thought that it ought to be a good programming language for beginners. I don't know whether that someone is actually using it in that way but it strikes me as ubiquitous and straightforward enough, hampered a little bit by just the scarcity of plain text editors. So many people now when they think about writing something they pull up a word processor and if you do that, if you open a word processor and start typing angle brackets for HTML they're presumably going to get escaped and come out as plain text rather than tags, so that's one hoop that an novice is going to have to jump through. I suppose figuring out web browsers are ubiquitous, but Emacs isn't, which is perhaps a shame.
I'm a Vim guy so I won't necessarily go with you on that.
Are you going to hang up on me now?
"Just" meaning that's the only language they know or "just" meaning they just recently learned it?
I think there's just necessarily a difference between people who program as their day job and people who are learning it because they're curious or taking up—
Some people who program as a day job aren't very good programmers to be fair.
People who learn it through a cookbook approach using snippets of code out on the web are likely not to really learn it very well and not really get a full flavor of what programming is all about.
That was certainly my first impression of it—my producer Sarah Kim handed me the book and I looked at it and said "Oh my goodness, this thing weighs four pounds. There's something there."
There is something there, and a language shouldn't have to have a book that big to explain it. To be fair half, of the book is reference material for language and for the document object model and only half of the first half is about the language itself, so only about a quarter of the book do you have to get through to understand the language. Then the second quarter you understand the web browser context and the rest is reference. It's a one-pound language, even though it's a four-pound book.
Are you suggesting that the DOM is fat?
Parts of it that are relevant to web programmers aren't actually too bad, especially once you start cutting out all the legacy stuff that no longer is really necessary because everyone pretty much supports the standard now. You can throw out the old Netscape stuff, throw out the old IE specific stuff, and it's not that bad. If you ignore the stuff that has never been well supported by the web browser vendors: some of the CSS style sheets for reversing functions that are standardized by the DOM. I don't think anyone is actually using them, and I certainly couldn't tell you what browsers support them and what don't. If you just focus on the core stuff for traversing an HTML document, that's not too bad.
That's something I've had to punt on; it was just too much—there are too many browsers, too many operating system combinations to actually test it all. In my book I recommend the Quirks mode website run by Peter-Paul Koch. I have an extra [inaudible] in the file but he at least used to do a pretty good job of trying to figure out what works and what doesn't on what browsers. To be fair, we are reaching a stage where the important stuff works on pretty much all the browsers, which is a nice place to be now.
After a decade.
Yeah; after a decade—this brings up my almost decade-old experience trying to get stuff working across browsers. I want to focus on that. We have a lot of software; a lot of people really believe that we'll move to—back to the thin, the client server model where we had a really, really thin client that has—what's effectively the 21st Century's version of the 3270 terminal emulator which is the web browser window.
I know you write about and program in several different languages some—traditionally on the client side and some traditionally on the server side; what's your prognostication for what's appropriate client side versus server side versus desktop side?
I really always have been a desktop compliant side programmer. I've done very little server side work. I started writing about Java back when it was for the desktop and applets and the web browser. I think you should take my prognostications with a grain of salt because I don't feel like I'm on the pulse of industry. I can follow the language well and explain languages well, but I can't really predict. I tend to favor pushing stuff onto the client; you've got that CPU that is just sitting there—you might as well use it, and perhaps that's just my bias as a traditional client side and desktop programmer that I'd rather have that control there and the client do as much processing on the client side as I can, freeing up bandwidth and server cycles.
In terms of where the client is web browser versus the "traditional" desktop application, any strong opinion either way there?
The browser does keep evolving to have more and more features we can take advantage of, and it does seem like that's where you get your cross-platform compatibility to do it in the browser. It does seem like there are a lot of possibilities there. I would love to see more options for writing web style applications that look like desktop applications that can be launched you know—you can have an icon desktop but really what's going on under the covers is launching up the browser window that looks like a window or something.
Transcript provided by Shelley Chance t/a Pro.Docs