Enough with the JavaScript already

The reality is... JavaScript is here to stay. So stop your complaining, that's such as waste of time. Rather than complain, champion better solutions. Be bold and advance a new and more efficient agenda.

> If you deviate from the standard using valid JavaScript, you lose the gains.

That's true for lots of JavaScript optimizations. JS optimization is all about speculation that the more dynamic features won't be used. Try adding calls to "eval" within a JavaScript function in any modern JS engine and watch its performance drop by an order of magnitude. Does that make functions that don't use "eval" no longer JavaScript? After all, adding a call to the standardized function "eval" negates the performance benefits of "eval"-less JS.

asm.js is just this principle writ large.

> Calling it "JavaScript" is just a semantic game.

No, it means that asm.js is backwards compatible. That is not a game; that is the entire point. That is why asm.js worked in Chrome (with good performance even!) from day one.

> It's not like you folks at Mozilla couldn't get support for a "real IR" from Google/Chrome -- that's half the market right there. In fact, the actual problem is that Google could never get support from you.

Because PNaCl is not a good idea for Web content. People have this idea that Mozilla knows PNaCl is "better" than asm.js, but Mozilla wants to stick to JS out of some sort of pride or NIH syndrome. This is not the case. Backwards compatibility is the main advantage of asm.js, of course. But there are also many others: LLVM IR is a compiler IR and was not designed for this; asm.js is smaller when gzipped than LLVM bitcode; asm.js compiles faster than PNaCl; asm.js can reuse the JavaScript infrastructure, leading to a smaller, simpler browser; asm.js does not have the Pepper API which reimplements all of the Web APIs in underspecified ways.

I think this is very true. When Java launched I re-did the Sun home page as an applet. Bill Joy suggested that in the future HTML would be gone and each web page would be its own Java applet. He was mistaken of course :-) But as I've watched the emergence of 99% js pages I am reminded of his insight. His reasoning was pretty straight forward, the reason PDF (and that thing Imagen/Xerox did (DDF?)) existed was that to convey the document creator's intent to the consumer over a fungible media like computers, required that the document be a program describing what it looked like, leaving it up to the end node to interpret that program and then do its best to recreate it for the end user. That was something ASCII could never do. So with web pages, especially interactive ones, they were destined to be "programs" rather an some form of semantic markup structure.

I have come to appreciate that this is a pretty profound concept (well for me anyway :-), having the end result sent as generalized instructions for reconstruction, rather than as a external representation of the constructed object.

JavaScript assumes a "web browser". What happens when we're not using a "web browser"?

A few days ago, I was actually downvoted for even suggesting that a user could disable JavaScript and that this might reduce her vulnerability to exploits. I'm always fascinated by the strength of the bias in favor of JavaScript.

I'm guessing that so many developers are now so heavily invested in JavaScript that if it were to become less popular they believe they would suffer somehow. They will thus defend this language with fervor. That's my guess.

Days ago we saw Dan Bricklin, who is no stranger to a world without a web browser and is responsible for the app that literally launched the PC into the mainstream, put in his plug for JavaScript. But we also learned he's written entire spreadhseet applications in JavaScript. It appears he's heavily invested in this language. It stands to reason he would defend its use.

On this thread someone mentioned that Bill Joy thought Java applets would power the web. Not surprising considering his company was responsible for Java, and he has called James Gosling, the father of Java, his favorite programmer.

I think when we look at JavaScript we need to ask ourselves who stands to gain the most from it. My belief is that it benefits developers more than users. It's aesthetically pleasing to most developers, but more importantly, programming in JavaScript requires less work than using a language with manual memory management that does not expect to be run inside another application (a "web browser"). JavaScript boosts productivity.

Users, I believe, do not see the same benefits. (e.g. I have seen Marissa Mayer while at Google state how important speed is to users. We might accept that speed is one benefit that users would recognize.)

Because the love for .js is so strong and criticism of it is not well received, I won't go into any more detail. But suffice it to say, if there are problems with using JavaScript, I believe it is not developers who would suffer the most from them. I believe it is users who would bear the burden.

I have never really understood this. JavaScript it is a a programming language and the only reason people built languages that compile to it is because they felt the needed something better, but this has always seemed incredibly hacky to me.