

JavaScript is Web Assembly Language and that's OK. - daigoba66
http://www.hanselman.com/blog/JavaScriptIsWebAssemblyLanguageAndThatsOK.aspx

======
Herald_MJ
No, it's not, and it's certainly not OK. Javascript is a quirky interpreted
scripting language created for scripting minor workflow events. It's an
afterthought by Netscape, duct-taped to a bundle of silly hacks, wrapped up in
some interesting attempts to standardise, with a few more vendor-specific
hacks crowbarred in there for good measure. asm.js is one more hack on top of
the mess, and while it's technically interesting, and probably very useful
(much like the rest of javascript), we shouldn't be building these monstrous
feats of engineering on top of such shaky foundations.

> there's only one language that works everywhere without installation or
> trouble and that's JavaScript.

This is true. But we've arrived at this situation virtually by chance, and
it's a huge mess and we shouldn't be readily accepting it. We need a real
bytecode for the web, we need it to be standardised and we need to push for
browsers to support it. NaCl seems to be the furthest down the road to this
objective so far.

~~~
johnpmayer
> We need a real bytecode for the web, we need it to be standardised and we
> need to push for browsers to support it.

We had one. It was called Java. Actually, we still have it, but it just has
such a bad reputation now; users don't trust it because of "security" and
developers don't trust it because of "public static cruft()" and "Oracle".

But it is still quite capable. Did anyone else first play minecraft in a web
applet? It worked incredibly well for me. So I argue that we do have a viable
bytecode, we're just ignoring it.

~~~
pekk
The experience sucks beyond compare, always has, and blaming the user isn't
going to solve that.

You have to download a separate plugin with stupid ads in it. If your version
is wrong, it won't work or it won't work right. A number of things won't work
unless you use the one from Oracle. If you are lucky, a little tray reminder
obtrusively harasses you every few weeks to update to a new version. If you
don't, you have to worry about unpatched vulnerabilities. Now you come across
a page with an applet in it. This applet stuck inside a little rectangle on
the page takes a few seconds to kick off at all. Most of the time it looks
terrible once it's up. It isn't at all uncommon that it crashes. Many people
have experienced this bringing down the browser or even hanging the computer,
which is especially awesome when you didn't even ask for the thing to run.

This isn't a matter of the users being stupid and not knowing what's good.
This isn't good. It has never been good.

------
arocks
One of the endearing qualities of web design and development was how the
source was open for everyone (HTML, CSS and JS). Developers could read the
code, understand and remix each other's work. This helped in its rapid growth
from a design platform to an application platform.

Enter asm.js, where the source code is as readable as a compiler's assembly
output. Once again we are back to code that is hard to hack and improve. Sort
of similar to the days of Flash except that entire applications are being
built on this platform.

It might be a great end user experience, but it is not the best way forward
for web development.

~~~
wwwtyro
> Enter asm.js, where the source code is as readable as a compiler's assembly
> output.

What do you mean? Isn't it roughly as readable as C?

~~~
jerf
No, it's roughly as readable as decompiled executable, without even a symbol
table to provide semi-readable names. John Resig has a somewhat reformatted
example a couple of pages into this: <http://ejohn.org/blog/asmjs-javascript-
compile-target/>

~~~
wwwtyro
I'm not following you. Are you referring to the minimized code that has been
beautified? Of course it is not going to be particularly legible. Same for any
minified code, asm.js or not.

From the link you gave, the DiagModule function is asm.js, and every bit as
readable as C.

~~~
jerf
Sorry, I was unclear. In this context, which if you follow back up to arocks'
post is in the context of using "View Source" to learn how things are done,
I'm referring to the sort of asm.js that comes out as a result of compiler
output, not stuff written by hand. The Gist is what I was pointing at. There
is no way you're going to read that and learn how, say, the Unreal Engine port
does something.

I think people may think I'm trying to be faintly critical, but I'm not. It's
just the nature of the beast.

~~~
wwwtyro
> I'm referring to the sort of asm.js that comes out as a result of compiler
> output

That Gist - what is visible from "View Source" after beautification - _is not
compiled asm.js code_. It is not the result of any compilation. It is the
result of minification. Most minified code is as illegible as that.

~~~
jerf
Yes, it is. (Perhaps not entirely, but it's generally what you're going to
find in the wild.) Read under the Gist for the bullet points. It may be
minified, but that's not what makes it impossible to understand.

Hand-written asm.js code is not going to be the norm, for the forseeable
future, for a variety of reasons. The rules for the grammar are difficult and
tedious to manually write. The fact that everything runs in a massive array,
so you've got a lot of memory management to write, is going to be a problem.
The existence of numbers like 1384465 and 4980736 is what makes that
particularly hard to read. Most asm.js code on the web is going to be
incomprehensible; the examples you can read are the exceptions, for didactic
purposes, not the rule.

~~~
wwwtyro
> Yes, it is [compiled]. (Perhaps not entirely...

Wow. No, it absolutely is not. I have no idea what you could possibly mean by
"not entirely" compiled.

>The rules for the grammar are difficult and tedious to manually write.

There's nothing difficult about the syntax. It's a subset of javascript.

> The fact that everything runs in a massive array, so you've got a lot of
> memory management to write, is going to be a problem.

No more difficult than managing memory in C.

> The existence of numbers like 1384465 and 4980736 is what makes that
> particularly hard to read.

The lack of _meaning_ for those numbers is what makes it hard to read. It
wouldn't matter if 1384465 were 2 or "a". It's been minified, so the meaning
has been stripped away. I agree that it is hard to read, but it's not a result
of using asm.js, it's a result of minification and auto-generating code.
There's nothing inherently illegible about asm.js.

> Most asm.js code on the web is going to be incomprehensible; the examples
> you can read are the exceptions, for didactic purposes, not the rule.

Sure, just like most javascript on the web is incomprehensible, by virtue of
being minified or auto-generated.

------
zxcdw
I don't understand why people say such silly feats of pseudo-"engineering" are
somehow "OK" and acceptable. How have we arrived to this situation?

I get that 1) agreeing upon a more sane bytecode-based language for the web 2)
implementing it on all major browsers 3) changing the tooling and workflow(no
more a .js file, save and open in browser but a compiled file instead) would
perhaps be not worth the benefit(more sane target, better support for common
programming constructs without performance, safety or determinism issues and
so on).

Simply, people don't give a fuck, web works "well enough" and iterative
engineering solves the major problems. These just are things we have to deal
with, something we can't change, which I find pitiful but understandable, but
most definitely _not_ "OK" or acceptable.

~~~
pornel
> I don't understand why people say such silly feats of pseudo-"engineering"
> are somehow "OK" and acceptable.

Network effect and worse is better.

Any solution that cannot be introduced gradually with backwards- and forwards-
compatibility is very unlikely to gain traction on the web. You'll always get
a vendor that doesn't like some tech or has multi-year-long
development/distribution/upgrade process. Tools can be even slower to upgrade
and you'll also need to educate developers and get them out of their comfort
zones.

It's not that people don't give a fuck. It's not pseudo-"engineering". It's
the best you can get within constrains that are both technical and social.

------
JonSkeptic
It would be OK if Javascript was a better language. It is terrible, but it
works. Most importantly, there is no alternative. That's why we use it.

~~~
jumblesale
That doesn't account for node's popularity. I like Javascript. That's why I
use it.

~~~
saosebastiao
I'm not an arbiter of what makes things popular, but from what I can see,
Node's popularity has more to do with the fact that front end guys no longer
have to learn a new language to work on the back end.

------
xradionut
JavaScript is a kludge. It's a bag on the side of a bag. The amazing thing is
that it works well enough to be useful.

~~~
codeulike
JavaScript is a dynamic language with C-syntax, prototype-inheritance and
lambdas. Embedded into every browser on the planet. Whats not to like?

~~~
vijayp
Also, no integers. Who needs integers anyway?

~~~
codeulike
Ok, thats true. And some of the built-in functions are crazy - parseInt("09")
anyone? - but the basic workings of the language seem ok to me.

~~~
zxcdw
The problem is that when the base language has such limitatios and funky
semantics, how should languages which target that be able to deal with that in
1) standard 2) predictable 3) efficient way?

This is the reason CPU instruction set architectures are so simplistic and
"low level" and don't really do things for you -- because if they did,
targetting such a CPU would be a _major_ pain with all inefficiencies due to
workarounds due to funky and incompatible features.

------
wslh
I bet that in less than 10 years we are running a standard VM in the browser
instead of Javascript.

BTW, it would be interesting to add real $$$ bets in HN. In this way users can
play with real money, not only with argumentation.

~~~
michaelwww
<http://longbets.org/>

~~~
wslh
Yes, I would like to have one integrated in HN :-)

~~~
michaelwww
I wouldn't bet against you on this!

------
fetbaffe
Thanks to JavaScript we rediscovered functional programming, because we
realized that the inheritance model Java polluted everywhere just stinks.

------
mwcampbell
What bothers me about asm.js and Emscripten is that, if used on a large scale,
they'll perpetuate the C memory model, that is, a single flat heap of
arbitrary size in which things are referenced via fixed pointers. Perhaps this
memory model is necessary for small pieces of high-performance code, but I
wouldn't want us to keep using it as the primary memory model for new
applications, especially when at least some of the current JS engines have
advanced copying/compacting garbage collectors.

I would love to have a memory-safe language that compiles to efficient
JavaScript with no intractable semantic or runtime mismatches between the JS
and the source language or its libraries (e.g. no preemptive threads with
shared memory) and takes full advantage of the JS engine's garbage collection,
but can also be compiled ahead-of-time to fairly efficient native code for
environments where JIT compilation isn't an option (e.g. iOS apps). I suspect
that a language like this would need static typing. To gain traction, such a
language would need to stick to fairly mainstream concepts (e.g. not purely
functional). Perhaps this language could be a subset of JS itself. The trouble
with Java and C# is that their standard libraries and most third-party
libraries assume multiple threads and blocking APIs; perhaps the compiler to
JS could transform the code into continuation passing style.

------
mbrock
Isn't it more like, uh, Java for the web, except without a bytecode? This
analogy is just weird.

~~~
Drakim
Java was always an external plugin to the web (like Flash), while JavaScript
sits more comfortable in the same shelf alongside HTML and CSS.

~~~
mbrock
The web is an external plugin to the computer. JavaScript is its programming
language.

------
taylodl
JavaScript is most emphatically _not_ the assembly language of the web. It is
instead the _lingua franca_ of the web. I actually think this is what people
intend to convey when they say this sort of nonsense.

------
Ygg2
I had a silly idea. Why not make LLVM a part of browsers? I heard it was a
really performant albeit hard to write languages in. It seems to not have the
stigma attached to JVM, especially association with oracle.

~~~
mwcampbell
This is what PNaCl (Portable Native Client) is trying to do. I'm skeptical
though; PNaCl is still experimental in Chromium 29 (the current development
version), and requires the browser to download extra files outside of the
Chromium package itself, probably because LLVM is quite bulky. If we're going
to run high-performance code with the C memory model in a browser, I think
asm.js is the best way to do it.

------
TheCondor
I prefer to think of it as web COBOL.

