Quantcast
Channel: Scott Hanselman's Blog
Viewing all articles
Browse latest Browse all 1148

JavaScript is Assembly Language for the Web: Part 2 - Madness or just Insanity?

$
0
0

UPDATE: Check out the Podcast I did with Erik Meijer on Hanselminutes this week on this very topic: JavaScript is Assembly Language for the Web: Semantic Markup is Dead! Clean vs. Machine-coded HTML.

Some folks think that saying "JavaScript is Assembly Language for the Web" is a totally insane statement. So, I asked a few JavaScript gurus like Brendan Eich (the inventor of JavaScript) and Douglas Crockford (inventor of JSON) and Mike Shaver (Technical VP at Mozilla). Here is our private email thread, with their permission.

Mike Shaver:

I've heard the comparison before, and I think it's mostly right. It ignores the amount of effort put into JS's developer ergonomics, though, since assembly is not designed to have a humane syntax (especially modern assembly).

Brendan Eich:

I said "JS is the x86 of the web" a couple of years ago [likely at JSConf], but I can't claim it's original. [Nick Thompson said it on Hacker News this year as well.]

The point is JS is about as low as we can go. But it also has higher-level facilities.

Shaver's right, assembly without a great macro processor is not good for programmers or safety. JS is. So the analogy needs some qualification or it becomes silly.

The mix of high-level functional programming and memory safety, with low-level facilities such as typed arrays and the forthcoming ES.next extension of typed arrays, binary data, make for a more powerful programming language than assembly, and of course memory safety is the first differentiator.

Douglas Crockford:

I think it is a little closer to the mark to say that JavaScript is the VM of the web. We had always thought that Java's JVM would be the VM of the web, but it turns out that it's JavaScript.

JavaScript's parser does a more efficient job of providing code security than the JVM's bytecode verifier. JavaScript did a better job of keeping the write once, run everywhere promise, perhaps because it works at a higher level, avoiding low level edge cases. And then Turing takes care of the rest of it.

There are certainly a lot of people who refuse to consider the possibility that JavaScript got anything right. I used to be one of those guys. But now I continue to be amazed by the brilliance that is in there.

Brendan Eich, again:

Doug's point about source beating bytecode is good. My friend Prof. Michael Franz of UC Irvine long ago showed O(n^4) complexity (runaway compute cycles, denial of service) in the Java verifier. JS is strictly more portable and fast enough to lex/parse as minified source.

Source as "bytecode" also avoids the big stupid Java bytecode mistake: freezing a poorly designed lowered form of Java, then being unable to evolve the high-form source, i.e., the Java programming language for fear of breaking Java bytecode compatibility. This severely messed up the design of inner classes and then generics in Java -- and then Sun broke bytecode compat anyway!

From a YCombinator Thread a while back, Nick Thompson said:

My admittedly biased view: I spent two years of my life trying to make the JVM communicate gracefully with Javascript - there were plenty of us at Netscape who thought that bytecode was a better foundation for mobile code. But Sun made it very difficult, building their complete bloated software stack from scratch. They didn't want Java to cooperate with anything else, let alone make it embeddable into another piece of software. They wrote their string handling code in an interpreted language rather than taint themselves with C! As far as I can tell, Sun viewed Netscape - Java's only significant customer at the time - as a mere vector for their Windows replacement fantasies. Anybody who actually tried to use Java would just have to suffer.

Meanwhile Brendan was doing the work of ten engineers and three customer support people, and paying attention to things that mattered to web authors, like mixing JS code into HTML, instant loading, integration with the rest of the browser, and working with other browser vendors to make JS an open standard.

So now JS is the x86 assembler of the web - not as pretty as it might be, but it gets the job done (GWT is the most hilarious case in point). It would be a classic case of worse is better except that Java only looked better from the bottom up. Meanwhile JS turned out to be pretty awesome. Good luck trying to displace it.

The point is, of course, that no analogy is perfect. Of course JavaScript as a language doesn't look or act like ASM. But as an analogy, it holds up.

  • JavaScript is ubiquitous.
  • It's fast and getting faster.
  • Javascript is as low-level as a web programming language goes.
  • You can craft it manually or you can target it by compiling from another language.

This topic comes up on Hacker News often.

  • "The JavaScript we've got now is the assembly language of the client-side. We can't easily change it, but we have to start building better tools on top of it." - jonnycat

Have at it. I enjoy our thoughtful, measured and reasoned discussions, Dear Reader. You guys rock.



© 2011 Scott Hanselman. All rights reserved.



Viewing all articles
Browse latest Browse all 1148

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>