
JavaScript is Not Web Assembly - jashkenas
http://blog.izs.me/post/10213512387/javascript-is-not-web-assembly
======
jashkenas
I usually try not to weigh in on these debates -- I imagine
<https://groups.google.com/forum/#!topic/nodejs/a7yVzBw1sJk> is what triggered
this post. But...

Mr. Schlueter is right on -- C++ is a much more accurate comparison, and
especially so because it was originally implemented as a cross-compiler into C
source code (circa 1983-1990).

That said, saying that the desire to compile into JavaScript is (to paraphrase
the post) pathological language-wank craziness, is a bit extreme.

I'd like to think that the reason why CoffeeScript has caught on like
wildfire, when there are so many other AltJS languages out there
([https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS)) is that we're trying to take the deeply pragmatic
approach.

Mr. Schlueter writes "you don’t compile it to target a given platform," as if
this would be an advantage or a justification for existing ... when it's
really quite the opposite. JavaScript is plagued with libraries that will only
ever run on certain platforms because they opt-in to platform specific
features. I can't use your simple pluralization library to turn "bit" into
"bits", because it was only written to run on Node.js, and is riddled with
`forEach` and `require`, or because it was only written for the browser, and
hides data in the DOM.

CoffeeScript tries very hard to compile into efficient, lowest-common-
denominator JavaScript (read avoid Internet Explorer bugs) because that's how
your library can be used widely across devices and runtimes, while being
reasonably future proof.

I don't know when "order of magnitude difference" became a synonym for
"worthwhile difference", but ... how much easier does a program have to be to
read and write before it becomes a worthwhile choice to make the change? 2x?
1.3x?

In any case, CoffeeScript is a little thought experiment -- not a corporate
project, or a Dart-like browser takeover. If it suits your fancy, use it, and
if it itches you the wrong way, by all means leave it out.

~~~
Rusky
The desire to compile into JavaScript is not what's being criticized here;
it's the "blah is to JS as C is to Assembly" analogy: "That’s not to say that
any of these systems are bad, just that the “blah is to JS as C is to
Assembly” analogy is wildly wrongheaded."

Trying to treat JavaScript as assembly is silly because it doesn't vary too
much between browsers- it is palatable to write, by hand, cross-browser JS
programs, whereas it is literally impossible to do so in assembly because
different assembly languages, as human-readable machine code, have virtually
nothing in common at that level.

Treating JavaScript as C is the reality, because JavaScript is what gets run
in different browsers (the analogy to compiling C to different platforms).

CoffeeScript is more like C++ than C because the language it's
replacing/augmenting/etc. is very similar semantics-wise- it's just trying to
make the same basic idea nicer to work with. The 10x difference thing is
pointing out that C->assembly is a massive translation, whereas C++->C, while
still a worthwhile difference, is much smaller.

Again, this is not a value judgement of CoffeeScript or GWT or anything. It's
pointing out a flawed analogy. This is useful because when we think of JS as C
rather than Assembly, it becomes clear that it shouldn't be the only option.
It would be an improvement if, in the future, more mature language compilers
could bypass JS to some form of bytecode (be it browser-specific, which would
be a much bigger problem in the browser world, or a standardized one like the
JVM does for the non-browser world... this is where the analogy breaks down a
little).

~~~
artsrc
A compiler that did an 'identity compilation' on a strict subset of real
JavaScript, and rejected any problematic or confusing constructs would have
value.

CoffeeScript goes further than that and provides different syntax.

One of the things that complicates C++ is the requirement for source code
compatibility with C. This necessarily requires preservation of confusing
quirks.

CoffeeScript is not source code compatible with JavaScript.

~~~
IsaacSchlueter

        A compiler that did an 'identity compilation' on a strict 
        subset of real JavaScript, and rejected any problematic 
        or confusing constructs would have value.
    

It would. But it would be a linter, not a compiler.

~~~
SimHacker
It would only be a linter if it weren't a compiler. If it compiles language X
to language X, it's a compiler. Because it compiles. Rule of thumb: if it
compiles, it's a compiler, not a linter. Simple. Like ducks.

~~~
marshray
What if it compiles language X to language Y, where Y is the union of all the
valid programs in X with a set of possible descriptive error strings?

------
swannodette
I think anyone who thinks this should take a good long, long look at
ClojureScript.

* You don't have to refresh the browser to develop, this is single largest productivity boost I've experienced in my 6 years as a JS developer.

* You can fully leverage JS prototypal inheritance (even on natives) because of ubiquitous namespacing

* You have access to macros - you can build the very features that people have been talking / debating about for years _today_

Unlike CoffeeScript (which I like and use), ClojureScript _does_ lets you
write correct code you would _never_ write by hand.

~~~
cheez
> You don't have to refresh the browser to develop, this is single largest
> productivity boost I've experienced in my 6 years as a JS developer.

How does it work?

~~~
swannodette
ClojureScript supports a feature called Browser REPL. The compiler REPL
compiles your code to JS and sends it to the browser for evaluation which
sends the result back. This means you can develop w/o restarting the browser
or ever leaving your source file while incrementally developing your project.

At the moment it works best in Emacs, but people are starting to add support
for other development environments.

After developing JS this way going back is simply painful.

~~~
bretthoerner
Is the only difference between the ClojureScript REPL and Firebug/WebInspector
(for JS) that I get to keep using my editor? I mean, you can already do JS at
the REPL without reloading the page.

fwiw, I'm an Emacs user, Lisp geek, and huge Clojure fan. I see the benefit of
this, I'm just curious if not leaving my editor is the only advantage or if
I'm missing something else.

~~~
swannodette
I dunno, IME, refreshing the browser to test small changes is a massive time
sink.

~~~
bretthoerner
I think you misunderstood. I can already pull up a REPL (that's running code
on the current page) and write/paste as much JS as I like into it without ever
refreshing.

So is the fact that you get to stay in Emacs the main selling point? Like I
said, I'm just trying to understand.

~~~
pandeiro
Yeah, I think you're right, the REPL itself isn't revolutionary, although I
felt as enthusiastic as the op when I discovered it existed. Then I tried to
use it.

It's alpha quality, breaks and has to be restarted quite often. And a large
part of webapp dev is testing code that is inaccessible from the global scope
because of architecture (module pattern, etc). There is some magic however for
dynamically loading Google Closure Library code that it wasn't compiled with,
but I found setting up correct paths to include my own ClojureScript files to
be tricky, especially doing so when targetting platforms with their own
particular architectures (eg CouchDB/Couchapps).

That said, I think the op made a very good point about ClojureScript producing
code that one would never write by hand. It's really the Clojure/Lisp idioms
that are the win. The REPL an accessory, and a nice one, even moreso once the
rough edges have been smoothed over.

~~~
swannodette
You can switch namespaces by eval'ing the ns form in your file after starting
the REPL. Agreed there are lots of rough edges. But even with those I am able
to code / test faster than w/ plain JavaScript or CoffeeScript.

------
Locke1689
This is a stupid debate over language. What people mean when they say
Javascript is web assembly is that Javascript is a compilation target, which
is completely true.

~~~
jibbit
Absolutely. I never heard anyone actually say “blah is to JS as C is to
Assembly” nor did i take them to mean that when they said "Javascript is web
assembly"

------
politician
I have to admit that I just don't understand the value of this discussion.
Regardless of whether JavaScript is like assembly or C or C++ or MSIL or punch
cards, I'm pretty sure all of us have heard of _cross-compilation_ and that
many of us realize the value of _targeting the installed base_ (which is why
we supported IE6 during the dark years).

Cross-compiling a language designed to address JavaScript's numerous flaws
into a safe subset of JavaScript for wide deployment seems like one of those
ideas that we already have a noncontroversial word for -- _polyfill_.

Prediction: Someone writes a CoffeeScript to Dart cross-compiler.

------
tptacek
I wonder if the author would be surprised by how many language compilers have
targeted C for their output.

~~~
hbien
I don't think he'd be surprised. Didn't C++ initially compile to C? He
mentioned how these "to-JS" languages are more like C++ to C than C to
assembly.

~~~
tptacek
C++ only briefly compiled to C, but compilation-to-C is a time-honored
compiler building trick.

It's not always reasonable to make inferences about the quality of a
programming language by reasoning about its compilation target. It's probably
never reasonable when you're talking about compiling-to-C, which is basically
a macro assembler.

~~~
ajross
Not even briefly, I'd say. Cfront-based compilers were the rule rather than
the exception well into the 1990's. It wasn't until the death of proprietary
Unix and the emergence of msvc and gcc that the world got used to the idea of
C++ being a first class language.

~~~
tptacek
You're probably older than I am. I started my career in C/C++ and I've never
used a Cfront-based compiler. (My first dev job was in the mid '90s).

~~~
bzbarsky
So C++ had existed for 10+ years by the time you started with it, right?

I was still having to deal with Cfront-based compilers (the one on HP-UX, for
example) in 2002 or so. Amusingly enough, it actually had really good error
messages.

------
azakai
Technically speaking the article is correct: "JS is the assembly of the web"
can seem misleading if one means assembly as "machine-specific code".

But "JS is the assembly of the web" is correct in the sense it is normally
meant, which is "a language that you can compile into as opposed to writing
directly for."

We are seeing that today, as the list of languages compiling into JS grows,
and begins to resemble the list of languages compiled into assembly. Whereas
the list of languages that compile into say C is much smaller.

So it is still a fair statement to call JS "the assembly of the web", at least
as long as we understand what we mean by that.

------
ses
Whether or not javascript is analagous to assembly language, I find 'compile
to javascript' frameworks such as GWT, GWT-Ext, Vaadin and Thinwire very
compelling to use and allow for a consistent and cohesive presentation layer
in rich web apps. Unfortunately all of these great platforms are Java based
and I would really like to see the same approach adopted for other languages.

Some people just don't like writing plain javascript, myself included. But
then I do generally develop UIs which more or less behave like desktop
applications, so the value of being able to plug in a few preset components is
much more attractive, if I wanted a very customised feel to the components I
used I guess it would have to be native javascript.

------
seldo
While I completely agree, C++ is both useful and popular, so these to-JS
languages will continue to proliferate.

The critical issue, as you identified, is debugging -- whichever language
solves this will probably win the space.

~~~
tptacek
The idea that debugging tools should determine how Javascript is generated or
written baffles me. It's only been over the past few years that we've had any
credible Javascript debuggers. The debugger builders will adapt to whatever
the developers use. The horse pulls the cart.

~~~
seldo
I think a major step in the development of complex javascript apps was the
development of real debugging tools for Javascript. Prior to that, the barrier
to a complex JS app was too high for the hobby developer.

------
jokull
.. so he _likes_ CoffeeScript? I'm not sure I grok the complaint or general
message of the blog post. I've never actually heard "Assembly of the web" in
relation to JavaScript. A link to earlier discussions that sparked this post
would be useful, because I think there might actually be a takehome point in
there somewhere : )

------
jasonwatkinspdx
You're correct. It's also a somewhat pointless clarification.

------
juiceandjuice
And assembly is just abstracted bytecode in a certain syntax.

It's rad that you're totally into CoffeeScript, but splitting hairs like this
is silly. A lot of the metaphor comes from the fact that JavaScript is
actually compiled down to assembly in software like v8. X to JS compilers can
even take advantage of that knowledge as well and produce optimized JS for
those compilers (I'm sure GWT leverages this) So yes, JavaScript is more like
C in that sense, but C compiles so ridiculously close to assembly that it's
practically just there to make system calls and memory management easy for
you.

So, if anything Javascript is the common language of distribution, or the
English of the web.

------
edtechdev
There are literally dozens of languages that compile to JavaScript already:

[https://github.com/jashkenas/coffee-script/wiki/List-of-
lang...](https://github.com/jashkenas/coffee-script/wiki/List-of-languages-
that-compile-to-JS)

------
sherkund
It's a metaphor.

~~~
marshray
The first sentence is:

 _It’s fairly common these days to think of JavaScript as a sort of “assembly
language for the web”._

That's definitely a simile, not a metaphor.

~~~
stickfigure
A simile is like a metaphor.

~~~
marshray
Certainly moreso than Javascript is like assembly language.

Upon seeing that article I was like "Oh yeah, I get the two confused all the
time WTF?!"

------
schiptsov
Over-simplifications and over-generalizations are ones enemies rather than
friends. We didn't say that Visual Basic is an assembly language of an office
or AutoLisp is an assembly of construction business.

Repeat after me: Javascript is just an in-browser scripting language. Period.

Yes. I know, it is possible to use JS on a server side, but you also can hack
a VB run-time to send you some files via http. Wait, isn't that crap already
exist and called Azure?

------
stottc
Assembly = "as low as you can go". You can always build things on top of it,
but you can never go any deeper. Javascript shares that much. Not too much
else.

------
yason
JavaScript is more or less a (potentially standard) language runtime, just
like JVM or CLR--just more compatible and more widely and natively supported.
I don't see the need for a strictly binary or bytecode runtime either since
parsing and interpreting/compiling JavaScript further inside a browser or
other native environment is "fast enough" for many definitions of fast.
Certainly faster than booting JVM :)

------
benfle
What would be very interesting to talk about (instead of entering into the
details of an innocent analogy) is a toolkit that would make very easy to
create new higher level languages on top of JavaScript.

Unfortunately, JavaScript and its VMs have limitations that would not allow us
to create very performant languages for some domains but I think we could have
a lot of other useful higher level language to program (the web).

------
andjones
I have an issue with the general premise of this article.

Who is saying that javascript _is_ web assembly?

I've only seen one comment in the comments so far, and its weak at that. Yes
no human can read Google's javascript, but that says nothing about its
efficiency, optimization, or correspondence with machine language.
<http://news.ycombinator.com/item?id=2783060>

------
tybris
Meh, this is just about wording.

~~~
turtle4
I agree. The point of the original statement was just to show that you should
be compiling to javascript, not writing javascript. This article is
technically right, the original comparison isn't perfect, but it is really
splitting it fine.

------
horofox
I think this is a pointless blog post annd all the comments here are
worthless.

------
IsaacSchlueter
I'd like to respond to a few of the comments here.

Jeremy imagines correctly. This blog post was essentially a continuation of
the subject on the node mailing list, and particularly the assumption that if
you feel you shouldn't compile to JS, then you should just write in Assembly,
or that JavaScript is only worth using if you want to be "closer to the
metal". I believe that these points of view are wrong.

Yes, of course I'm aware that C++ was originally cross-compiled to C. That's
why I chose it for the analogy, like Lassie on display in the Louvre. People
tend to take comparison that as either a compliment to CoffeeScript, or an
insult, depending on their feelings about C++ vs C. I consider both
interpretations to be correct.

I have no problem with people compiling to JavaScript, though I personally
prefer dealing with JavaScript directly. I like stack traces with line numbers
that correspond to the line numbers in my editor, and it's not such a bad
language. One of the biggest things I've found lacking with both Node and
Browser JS is post-hoc debugging. Syntax sugar doesn't help with that. I'd be
much more excited about efforts to produce state-capturing crash dumps that
would let a developer revisit an error condition and investigate it after the
fact. Other language have this, and it makes me very envious.

"Expressiveness" is a measure of how many tokens are required to write
programs. Read some of pg's essays about arc and blub. A less than 10x
increase would still be relevant, but.. well... meh. It's not a major leap in
power that Assembly to C is, or C to JavaScript is.

Increases in expressiveness often come at the cost of also increasing the
difficulty of reasoning about programs' precise behavior, but increase the
ability to reason about their intent. Reading assembly isn't exactly fun (in
my opinion), but it's also quite clear exactly what the computer is doing --
so much so that it can be tricky to figure out exactly what the human was
trying to accomplish.

C is much more humane, and still pretty clear what's going on. It's an obvious
sweet spot for many tasks. JavaScript, on the other hand, runs on this huge
black box, but it's much more expressive than C (and thus, much easier to
write), and it runs in web browsers (which makes it inescapable), doesn't
require a compilation step, and is quite fast for a lot of tasks. I've yet to
see any similar leap from a to-JS language. They're just other high level
languages that all have pretty much the same basic set of features. A lot of
them are a bit nicer than JS, but they lack JavaScript's relevance factor.

I must not be a very good writer, because people often read things I write,
and seem to come away with the impression that I have these strong
prescriptive views about syntax and coding style. I don't. The reason I'm so
unenthused is because most high level languages don't really seem to differ
all that much. Coding style doesn't solve very many problems, and the problems
it does solve aren't particularly hard.

------
georgieporgie
This whole thing is weird (and stupid). I listened to the Hanselman interview
with the guy who started pushing the concept of JS as Assembly. He came across
to me as being really confused. He seems to conflate the concept of a .Net
assembly, with "assembly language". I got the impression he had never written
anything in assembly language, and didn't understand that it's a minimal
mnemonics + macro layer over actual byte code, _not_ something highly
portable, and _not_ something that "assembles" components together.

[http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageFo...](http://www.hanselman.com/blog/JavaScriptIsAssemblyLanguageForTheWebSematicMarkupIsDeadCleanVsMachinecodedHTML.aspx)

JavaScript is the new universal web glue language. This is great, as is the
fact that people are developing better-abstracted languages which compile to
JS. But it's not any sort of "assembly language" unless you employ really
confused semantics. I take issue with this for precisely the same reason that
I take issue with using "Cloud" interchangeably with "Internet" or "Website".

------
javascriptlol
The problem with JavaScript targets is not the terminology, but how bad the
design of the whole web stack is. It's like watching people badly redesign
operating systems in the browser, every so often catching up to something that
was solved 20+ years ago on the desktop. Painful.

