David Flanagan on JavaScript 2

By chromatic
August 22, 2008 | Comments: 8

You may also download this file. Running time: 00:31:14

David Flanagan is a programmer and the author of several O'Reilly books, including JavaScript: The Definitive Guide, Java in a Nutshell, and The Ruby Programming Language. In particular, JavaScript: The Definitive Guide demonstrated how a little language seemingly thrown together in the early days of the web was capable of so much more.

In this interview with O'Reilly (conducted shortly before the JavaScript Harmony announcement, David discusses how the conception of JavaScript has evolved from little hacks and distractions to a fundamental piece of modern web applications, how the design of the language might have changed with the advent of EcmaScript 4 and EcmaScript 3.1, how the web has evolved from the early days until now, and how HTML and JavaScript might be the new BASIC.

When I think about the language of JavaScript I think about something traditionally underappreciated. I looked at it several years ago and thought—my gripes with the language are mostly that its platform is so bad. I had tried it on different web browsers, the main environment where I can get to it, and it's inconsistent between those. When I look at it as language there are a couple things that bother me, about as much as any other mainstream programming language. That was the first time I took it seriously.

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?

I started working on JavaScript back in 1996, right after I had written Java in a Nutshell. You have to go back a ways to remember what the web was like then; the web was new. The first commercial sites were coming out and applets appeared on the scene. This is before animated GIFs; the only way to have animation you know on the web was with Java applets. Now it's a huge thing. I wrote the Java in a Nutshell book, and timing was good and people liked the book.

I remember being at the Java One Conference and signing books and it was lunch break. I was behind some Sun engineers. I think they did security stuff for Java or something. They were like, "So David, what are you going to write about next?", assuming I was going to continue with Java. I said "You know, I'm thinking my next book is going to be on JavaScript." They were appalled. [Laughs] And it just—I don't know; they lost a lot of respect for me or something. They couldn't see that JavaScript was going to have a much larger impact on the web.

Java went on to have a huge impact on the server side of course, but applets faded into pretty much obscurity because JavaScript was just more tightly tied to the content of pages even back then. It was kind of a natural outgrowth of my work with Java in the sense that Java was at the time a web technology, a client-side technology and JavaScript seemed like the next big thing.

That seems like so long ago though.

it's a strange thing. When the 5th Edition of my JavaScript book came out I didn't realize it; it was just about to go to the printer and I looked back at the printing history of it you know inside the front cover and realized that the 5th Edition was coming out almost exactly 10 years after the first edition did.

To go back to some of your earlier points about the language, I've always thought that the core language itself was fairly stable and reasonably consistent across browsers once we got past Internet Explorer 3, things like the core language was fairly consistently implemented and that wasn't the problem. But all the headaches that anyone who worked with JavaScript on the web suffered were inconsistencies in the client-side Document Object Model. That's crucial for using JavaScript on the web but it's not about the language itself, and you know finally we're growing out of that too I think. But I think that—I think it's Douglas Crockford's new book, JavaScript: The Good Parts, his philosophy and I can't quote him exactly but he's been known to say something to the effect of basically that JavaScript is this ugly language with a beautiful language hidden inside or something.

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.

book cover book cover book cover
For a complete list of all things JavaScript,
visit javascript.oreilly.com

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.

What surprises me about JavaScript is that it's like Ruby. People were doing great things in it for a while but then something suddenly happened and all of the sudden people started taking it seriously. In my mind, I think a lot of people tie that back to the introduction of Google Maps where people said "Wait, you're doing what now? You can do this with JavaScript? You can do this on the client side?" All of the sudden there was—we'll call it the post-Google Maps explosion—where people were able to identify the use of JavaScript asynchronous requests, XMLHttpRequest, and say here's a way to get beyond the statelessness of HTTP and do more client side. That makes us work like a desktop application.

Yeah; but I think your analogy is good that the occurrence of Ajax did for JavaScript what Rails did for Ruby. At least it seems that way to me at the time. I really regret—when I was writing the 4th Edition of my book I came across XMLHttpRequest and I think Microsoft documentations; they were the first ones to introduce it.

Right.

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.

Maybe a vindication of all of those years laboring for just using JavaScript to switch images if you didn't want to rely on CSS Hover for example.

Right. Well, you know, people were switching images with JavaScript before CSS could do that.

In Netscape 4 you had to enable JavaScript to get CSS to work in the first place. That was an odd period in the web.

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.

I don't miss those days. Speaking of web browsers, if you look at technologies such as Mozilla and some of the derivative products such as Songbird and Komodo, those are primarily desktop applications built in a combination of XML and JavaScript. That sounds strange to me. I still have a hard time wrapping my head around the notion of building a desktop application in JavaScript.

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.

Infinitely uglier. It can't really get any worse than that it seems to me, but like I said I really shouldn't go down that path. XUL seems like a pretty neat idea, to leverage that HTML renderer and the GUI library that it's in that Mozilla, in their core library and then be able to build your own stuff with it. Obviously I'm more interested in the HTML renderer and the web fetching all their stuff is there and you couldn't access it in a high-level way. Their API was unfortunate as I recall on JavaScript just because they were trying to mimic Microsoft's Object Technology or whatever and it was so abstract and hard to use.

The version of COM? XPCOM?

Exactly, and that seems like a real stumbling block to me but the idea, a pretty nifty one, speaking for JavaScript specifically—it's a perfectly powerful language for that. i'm sure that Mozilla had confidence in their implementation. You know if you're going to be doing that obviously you didn't have browser incompatibility issues. Mozilla defined the JavaScript interpreter and they defined all the API for it. They have a fast C-based implementation and we all think that Perl and Python are fast enough interpreters for scripting languages, so there's no reason that Mozilla's SpiderMonkey interpreter shouldn't be fast enough for writing applications then too—especially when most of it is driving the UI code.

You're mostly blocking for user events and network events and things like that.

Right, and I assume that the model for most of those applications is that the heavy lifting computation could be done on the server side, you know since they are sort of web applications ported to the desktop. It seems like JavaScript was a perfect language for that. Although I imagine that is—and I'm using this as a segue—I imagine that experience with JavaScript and XUL is what drove interest in JavaScript 2 and really evolving the language in a way that will enable programming in the large.

It's hard to imagine that there would be a JavaScript 2 or a push so much for JavaScript 2 if people weren't interested in pushing more stuff to the client side and running that through JavaScript.

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?

Right.

Or importing. Those are things that I look at when I do serious programming in other languages. If I try to do something serious in JavaScript in the same way I run up against those limitations.

I said it was a language that was created very quickly when Netscape 2 was going out the door, but JavaScript 2, which I guess everyone now just calls ES4 for ECMAScript, the 4th Edition of ECMAScript Standard that's being evolved now—is going to have name spaces, classes, interfaces, iterators, generators, all kinds of stuff—types, typed variables, optionally typed variables and they've done some really amazing stuff with types. I guess the fury of type calculus or whatever, which is an area I really know nothing about has really grown over the last decade I suppose. People are really doing interesting things with that it. We've got generics in Java; ES4 takes that a level further. They're going to have parameterized types like generics—just some really amazing stuff and do it all in a way that's compatible with the current version of JavaScript so that the current JavaScript code will continue to run.

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.

Let's move away from the web for a minute. Technologies like SpiderMonkey, Mozilla's standalone library that includes a JavaScript interpreter; that's been around for several years.

Yes.

I think in many people's minds they still think of JavaScript as a web-programming language and not necessarily a standalone programming language, whereas I hear a lot of people say that JavaScript is one of the most widely deployed programming environments anywhere and it's suitable for novices to teach themselves programming or learn programming for the first time because of its ubiquity and simplicity.

Right, that's the new BASIC. The computers don't come with BASIC interpreters anymore the way they used to but now every web browser has a JavaScript interpreter so you can try it out. Part of the reason that it's not used as a standalone language is that any embedding of it has to define its own host objects. There's no file system access for example; it really can't do much other than you know count. You can write loops and stuff but you can't even output them or get user input or display output, or you can't read a file or write a file if someone hasn't defined the bindings for that. It's suffered from that.

I think JavaScript 2 could change that, although once again—as far as I know—there's no talk of having a standard file system API or even just a traditional file class built into the JavaScript 2 specification. But I imagine a fairly thin layer around JavaScript 2 interpreter could add that and then you'd have a scripting language that would be a very interesting alternative to Python and perhaps even to Ruby. You know I haven't tried enough to know how I'll like it but I tend to think that could easily become my language of choice with the powerful stuff they've done with types and things.

Barring fragmentation of course; if there's no standard way to access a file system everyone needs to invent his or her own....

Right.

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.

Yeah; and I don't know who would release the JavaScript 2 for scripting command line version, but someone could do that and give us a standard operating system level API to files and other operating system stuff. Then we've got a really powerful scripting language to use—but you're right; it really hasn't taken off except in the web browser. The one exception to that, I suppose, is for Flash programmers who are now I gather working with sort of an early version of JavaScript 2, a previous incarnation of JavaScript 2 that Adobe has released as ActionScript 3.

Wasn't ActionScript 2 more or less JavaScript with bindings to the Flash model?

As far as I know every version of ActionScript has been a version of JavaScript. I actually am not a Flash person so I don't know much about it and I don't know exactly what version added what, so I can't really say much more about ActionScript 3 except that it's based on a very old proposal for JavaScript 2 and so it's not really compatible with what they're talking about now. I do know that Adobe is working hard; I think they're one of the main drivers behind the ES4 specification.

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.

Right.

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.

Does it still retain the JavaScript flavor and if so what is that flavor? How do you look at a piece of code and say this feels JavaScripty to me?

Oh, that's interesting. I'm not sure that it does. They maintain compatibility, and they've got a whitepaper up on their website about evolutionary programming, how your JavaScript 1 code can evolve piece-by-piece into something more robust using JavaScript 2 features. In that sense it retains compatibility so there's still that small core JavaScript language that's still in there. Hopefully the set of good parts is widely expanded to boot all this other goodness. I imagine there will be people who are freaked out by it; people who are scared off from Java generics for example might be intimidated by ES4.

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.

You're right there. It's the corner cases with Java generics that drive people nuts, not the common use cases. I think JavaScript 2 is going to feel like a new language. Whether or not average web developers will feel like they're using a new language, I don't know whether that's the case or not. It could be that it will be the library developers who are the ones that are using JavaScript 2 to create their library; the average web developer will continue using those libraries and it will still feel like JavaScript with which they're familiar.

The other piece that we should probably talk about is that as an interim there's also a group of people including Microsoft and Yahoo and Google and many of the same browser vendors working on intermediate ES 3.1, just a feature or a bug fix release to the 3rd Edition of the specification. Gosh, I forget how long ECMA Script 3 has been out; it's been quite some time now. They're bringing the specification upstate with reality with what browser vendors are doing now adding a lot of—not a lot—adding a few very nice features to the API, some functional programming methods and array methods that Mozilla started with and added in what they called JavaScript 1.6. Those look like they might get standardized and then the language also has a few sort of hidden power user features that are really going to enhance the ability of library developers to write robust libraries.

Is this something they can deploy on a fairly quick basis?

I think the idea is that this can get pushed out more quickly than a full JavaScript 2 implementation. I think it's important although I don't pretend to really understand the politics there. Microsoft is actively involved in the ES3.1 effort and they don't seem to be actively involved in the ES4 effort.

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.

It seems likely that we will have intermediate steps of transition at the ES3.1 before we see a full JavaScript 2 based on the ES4 specification. We might have Internet Explorer compatibility with ES3.1 more quickly because again they're mostly standardizing what a number of browser vendors have already implemented. Once we get it all out there for everyone to start using and have a standard written, I think that will be a nice little bump in the capability of—well it will definitely still be JavaScript 1 but it will probably be called JavaScript 1.9 or something I suppose. I'm not sure if that space has been settled.

In terms of JavaScript 2 what are the features that you're most looking for? If I asked you what you really wanted to see most, could you give me a list of two or three things?

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.

I actually have been watching the evolution of JavaScript 2 actually for years now because there were talks about it four or five years ago that petered out. I've been observing those with dread knowing that when it does finally come out it's going to be a massive rewrite for a whole new book because it clearly is destined to be new in many ways.

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?"

Right.

One of the interesting things about talking about web-programming, I mentioned this before, you said—I don't want to misquote you but I think we can do this—"JavaScript and HTML are the new BASIC". Someone who wants to start programming can put together a web page and make a little button that changes the background color. That's an hour's worth of work for a 14 year-old who may or may not have a book, but he can find a tutorial on Google.

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?

No, no; I'll just use Viper and we'll all be happy. Speaking of text editors; do you think there's a gap between so-called "real programmers" and people who have just picked up something like JavaScript?

"Just" meaning that's the only language they know or "just" meaning they just recently learned it?

Either way.

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.

That's true; I don't think there's anything about JavaScript that makes it a lesser language, if that's what you're asking.

Yeah.

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.

Isn't that how most of us who've ever done any JavaScript picked it up?

Yes, I think that's true, and I think that's part of the reason that my definitive guide, the JavaScript book is well-received. People who learned it that way eventually come to that book and read it and come of have this a-ha moment of "Oh, it is a real programming language and it all makes sense once you get your head around it."

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.

Sounds like there may be room for a book that's JavaScript: What Actually Works.

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.

Right.

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.

Right.

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.

You're probably looking forward to things like Gears and Prism then right?

No; I haven't looked at Gears much at all and I haven't even heard of Prism I'm sorry to say but there does seem like there's a lot of promise there. I haven't looked at Adobe AIR or JavaFX. I think they're all trying to capture some share of that. But yeah; that does seem like doing it in a scripting language like JavaScript and building upon a web API based on open standards gets us around all the platform and compatibility that we'd have to deal with if we were writing native applications.

Transcript provided by Shelley Chance t/a Pro.Docs


You might also be interested in:


8 Comments

It should be pointed out that this interview took place before work on JavaScript 2 was abandoned. So you can ignore those parts of the interview :-)

Despite my enthusiasm for the JavaScript 2 proposals, I do think that the new plan to evolve the language in much more modest ways makes a lot more sense...

I'm a great believer in internet standards however here we have a major problem in that at least two parties involved in 'developing' the standard would not want it to progress much at all.
I have written a JavaScript editor in HTML/JS and with JS2 this would be a lot easier. With JS2 and SVG one could fairly easily write replacements for Flash and SilverLight.
You can see why MS and Adobe don't want JS to progress past 1996.
I do hope Mozilla has the courage to release a JS2 capable version of FireFox.

What a fantastic article!
Thanks for the time and consideration that went into this piece.
I too am a great believer in internet standards but with the efforts split between the two dominate sources, which way will it go?
Dave

Great piece, thanks for sharing this.

i Emuan Preious i am very greatful to write you people of your product that it is good i really like it.
thanks yours friend

When I think about the language of JavaScript I think about something traditionally underappreciated. I looked at it several years ago and thought—my gripes with the language are mostly that its platform is so bad. I had tried it on different web browsers, the main environment where I can get to it, and it's inconsistent between those. When I look at it as language there are a couple things that bother me, about as much as any other mainstream programming language. That was the first time I took it seriously.

An interesting article , thanks for you !

Jake

Great piece, thanks for sharing this.

JavaScript 2? Wow I feel old already. xD

Popular Topics

Archives

Or, visit our complete archives.

Recommended for You

Got a Question?