No one language can meet every need. Even if it has been done, Javascript is a terrible language to write an MP3 decoder in, relative to more suitable languages. So if we're continuing to expand what the browser can do, shouldn't we expand what languages we can express them in? Why do we have to write our WebGL programs in Javascript? Javascript isn't a terribly great bytecode language, either, unless you're basically just writing a thin skin over Javascript.

The logical conclusion of this line of argument is pretty much NaCL: http://code.google.com/p/nativeclient/ Is that the anwser? Is there some intermediate where Javascript isn't the only choice for everything but we don't go to the other extreme?

Beats me, but we'll all find out together. But my main point is that it definitely is not the case that Javascript is just the answer to everything and the situation is just peachy keen as it is. It isn't the answer to everything. No one language is. Either we get something else into the client, or we face some combination of wasted effort jamming programs into a language that doesn't really want them and applications simply never written because they don't work well with Javascript's abstractions. Maybe that's OK too, maybe we want a distinction between "native" and "web" app.

So i'm curious what you mean by "more suitable languages" for writing an mp3 decoder. Also which of Javascript's abstractions are do you think are so inherently unsuitable?

As far as general purpose programming languages Javscript does pretty well with regard to object semantics. That's why things like Coffeescript are as powerful as they are. Javascript certainly doesn't have the elegance that say Ruby or Python has built in, but thanks to JavaScript's powerful and flexible nature, a lot of those capabilities are possible to build on top of JS's core.

http://documentcloud.github.com/underscore/ (which was also written by jashkenas and others) is a great example of this.

On the performance front, given all of the work that's gone into the various browser implementations of JS, that you could call it unsuitable from a performance standpoint. Could perhaps elaborate on this further?

"Also which of Javascript's abstractions are do you think are so inherently unsuitable?"

No, that's the wrong way of thinking about it entirely.

When you create a language, you must unavoidably privilege some ways of thinking and working above others. You must make some things easier, at the expense of making some things harder. There's no one set of answers that works universally.

Suppose I want to make an immutable language. Can I program Javascript purely immutably? Well... sort of. You can try, anyhow, but you'll get no help from the compiler, and any existing libraries will be all but useless, it's really a new language. Suppose I want to prove things in Javascript; with both mutable values and object prototypes that can be freely rewritten at any time, it's infeasible. Suppose I need C++; where's my private variables? Expressable? Sure. Useful? No; Javascript has made them much harder while working on making its object system powerful in different ways. That's not a criticism; a language has to make some things harder when it makes some things easier, to be a criticism I'd have to be calling it a "bad tradeoff", which in most cases it isn't.

It's not whether a thing can be done, it's how well it can be done, and Javascript isn't the best at everything. And "how well" something can be done matters, because the harder you make it, the less likely someone is to do it. No amount of theorizing how that doesn't have to be the case will change that.

There's nothing that any Turing Complete language can't do (with the proper hooks into the machine it's running on, anyhow), but no one language can be the best choice for everything. I wouldn't want to try to make an OS out of Javascript. Now, I personally wouldn't want to try to make one out of C particularly either, but Javascript would be even worse.

So either we lock all those apps out of the browser, or we make them much harder to write than they would be in a language actually suited to them. There's a time for C and a time for assembler and a time for Haskell and a time for C# etc. etc. Languages profoundly affect what gets written in them.

The two things i have to say in reply to that. First, i think there's a lot of bunk common wisdom about tradeoffs as well. Scala's a great example of a coherent merger of object oriented programming and functional program, two paradigms that have for whatever reason been typically seen as oppositional (please note, i'm not accusing you of that, but i think it's reasonable to ask which things you think are unsuitable, understanding that there are tradeoffs). Second, when you're talking about suitability, i have to ask about what your constraints are. If all languages have their tradeoffs, then i don't see the problem with saying that JavaScript is as good a general purpose programming language as any other. Sure it's got tradeoffs, but JS as a language and as a programming platform has really hit a firm stride, and clearly has at least a couple years of solid growth ahead of it. Yes, JS like any other programming language, isn't perfect, but it is going to continue getting better and growing into new niches.

An example that shows that Javascript wasn't designed for performance: it doesn't support integers. They can be used in some Javascript implementations that do smart tricks to convert float arithmetic to integer arithmetic, but it is not reliable. If you were designing a language for performance in the first place, this would be a ridiculous method to get access to integers. Same for dense arrays. Yeah, JS is pretty fast if you know how the particular implementation that you're targeting works, but even then there are many things that just need a lot more performance than JS can offer.

On the expressiveness front: Javascript doesn't support proper lexical scoping. It's object model is broken. It doesn't use proper abstractions in the standard library. Etc. These can all be fixed by compiling another language to Javascript, but then you lose on the performance side.

Dense arrays are coming in Harmony, thanks to WebGL. (JS.next)

CoffeeScript incurs no penalty when compiling to Javascript; in fact, in many cases it's faster than handwritten code.

CoffeeScript is only kinda "another language." It's very intentionally designed to map closely to JavaScript. Try it with an actual independent language like Python, Ruby or Haskell and you'll have more trouble.

Yea, Coffeescript incurs no penalty because it's so close to Javascript, but therefore it doesn't fix Javascript's flaws either. Coffeescript still doesn't have proper lexical scoping and it doesn't have a good standard library.

It sure fixes a lot of the expressiveness problem.