Infrequently Noted

Alex Russell on browsers, standards, and the process of progress.

Comments for Why JavaScript?

That's not true in practice. You're allowed to include Lua interpreters and the like. That you can't dynamically import code from the outside world is a different concern.

by alex at
"No other successful platform is so limited to a single language (in semantics if not syntax)."

iOS.

by Adam at
another take here: https://nicolas.perriault.net/code/2013/why_javascript/ (same title!)
by bob at
My preference would be for the ecmascript/es-discuss group to have the Dart deal: A new language - with a new lean, sane runtime - which initially compiles down cleanly to ES5.

It's almost 20 years since Java and Javascript. We need something new - which works well with the 'DOM Reformation' - Web Components, Web Animations, Pointer Events etc.

The goal of Dart isn't bad - the implementation of that goal is. There is so much more innovative thinking on es-discuss - but it's hampered by maintaining backward compatibility with JS.

One of the objections to a 'new' language and runtime a few years ago was hardware/memory limitations. But now lets skate to where the puck is going - really great multi-core CPU/GPU's with 2GB+ of RAM.

In 2001 I was develop apps on IE5 which were pulling down JSON with XMLHttpRequest and building MVC interfaces. Also using .hta's and htc's. ScriptX for printing. And when MS released C#/dotnet with ASP.net I knew something had gone seriously wrong at MS - because ASP.NET was oblivious of the rich IE5 platform - it was all about round trips. Then MS stagnated IE to focus on xaml etc - and the rest is history. But now with the new API's like Web Components - innovation has started again.

Google need a unified platform across Chrome/ChromeOS and Android. Something sane, simple, secure and structured. With snappy touch and graphics. I don't think the dalvik stack is right long term for apps on anything bigger than a phone. And can V8 handle more complexity?

by kevin c at
There is ASM.js which is a first attempt at making a low level standard which could be optimized in a very different way. For now I think there is no way to tell if it's going to fail or be a success, but seems a nice addition to the web.
by Nux at

Hey Nux,

Yeah, ASM.js is a good example of how it's possible to explain more of the stuff that JS can't "do" by expanding the set of things it can do. Much the way Binary Data in ES6 is going to open up JS's ability to describe things that were previously "out of scope" for JS, expanding JS is, to me, the only credible way to peel back the onion of the web platform compatibly. Using that lens gets you a long way, and kudos to Mozilla for continuing to push.

by alex at
The references to JVM and bytecode sound like you're confusing JavaScript with Java.
by Rob at

Rob:

I haven't confused them, but apologies of it reads confusingly. Understanding the strains of argument often means adopting the perspectives of those doing the arguing, and adopting the CLR variant of the bytecode argument would have put up a regrettable and irrational "but that's MSFT! I hate them!" barrier in the minds of many readers.

Regards

by alex at