

Why Asm.js Bothers Me - espadrine
http://mrale.ph/blog/2013/03/28/why-asmjs-bothers-me.html

======
haberman
> OdinMonkey is a hammer that will kill incentive to optimize JavaScript that
> humans write.

Eh, I'm not worried about this. Many apps will have no reason to migrate to
asm.js, and for as long as some big and important apps are written in
JavaScript, there will be incentive to optimize plain JavaScript.

JavaScript and other dynamically-typed languages exist because in many cases
they are the best and most convenient way to write apps. But suppose this
weren't true; suppose that in the long-term developers started favoring
statically-typed languages for web apps, either because of performance or
because of usability (Eclipse-like IDE convenience; hard to provide in a
dynamic language). Is the author saying that we should artificially prop up
usage of dynamic languages by taking away some of the inherent performance
benefits of static languages? That doesn't sound like the best way to achieve
technical excellence in the long term.

In the marketplace of ideas and technologies, let things succeed or fail based
on their demonstrated merit, rather than trying to pick winners and losers
based on our preconceptions.

> Somebody might say that [my proposed bytecode] does not run everywhere.
> Nope. It does run everywhere: just take JavaScript and write a simple one
> pass translator from this bytecode to JavaScript.

You can think of asm.js as just that; a one-pass translator of an implicitly-
defined bytecode to JavaScript. If you want to view/edit it as a more
traditional-looking byte-code, you can easily implement a
YourBytecode<->asm.js compiler. It just so happens that asm.js is a backward-
compatible representation, so works more conveniently as the standardized wire
encoding.

(I have not studied the asm.js spec in detail, but I've seen pcwalton describe
it as an alternate encoding of LLVM bitcode, so I suspect that the idea of
implementing a YourBytecode<->asm.js compiler is actually reasonable given the
asm.js definition).

~~~
pcwalton
I should qualify my statement with some caveats:

* asm.js has a very primitive type system, unlike LLVM bitcode. I think this is better for a distribution format; the complex types make sense for compiler IR optimizations but not so much for distribution after the optimizations are already done.

* asm.js doesn't have goto, unlike LLVM bitcode. I'm told that this doesn't seem to matter much in practice, as the Relooper is quite refined now. However, I'm certainly willing to believe that there are some oddly-shaped CFG's that this will hurt. Perhaps JS will need goto.

* asm.js doesn't have 64-bit types. This is unquestionably unfortunate, as it will need 64-bit types to achieve native parity. (Of course, JS needs 64-bit types anyway—it's important on the server, for instance.)

* asm.js doesn't have SIMD, unlike LLVM which has support for SIMD with its vector types. This will need to be added on to be competitive on some workloads. This is a good opportunity for collaboration between Dart and JS, as Brendan pointed out.

Regarding the original post, (and speaking only for myself, not my employer) I
actually agree with mraleph to some degree. From an aesthetic point of view I
don't like the subset approach as much as anyone. But if V8 doesn't implement
asm.js AOT compilation, ignores the "use asm" directive, and achieves the same
performance as Odin, then that's actually a good outcome in my mind. At least
asm.js will have fulfilled the role of an informal standard that engines and
compiler writers alike can agree to target for maximum performance.

~~~
grayrest
> Perhaps JS will need goto

I was under the impression that labeled break/continue were the equivalent.

~~~
DannyBee
Yes, they are equivalent (AFAICT). You can generate irreducible control flow
that will still require breaks to exit loops.

However, it is possible to eliminate (even in the irreducible case) all gotos,
switches, breaks, and continues from a structured program.

goto's can always be transformed into conditional statements or loops.

break/continue can be eliminated by an extension of the control flow
elimination, and use of variables + conditional flow.

A real world implementation can be found here: <http://gcc.gnu.org/ml/gcc-
patches/2002-05/msg00109.html>

(it was never merged, we decided we were fine with goto/switch/break/continue)

------
voidlogic
"the first danger that I sense: OdinMonkey is a hammer that will kill
incentive to optimize JavaScript that humans write. Why waste time optimizing
normal, dynamic, fluid like water JavaScript if you can just ask people that
they write something more structured and easier for compiler to recognize? "

I'm eagerly awaiting the day I can write single-threaded Go or Java, have it
turned into asm.js and never have to write another line of yucky Javascript
again. I like this proposed alternate future.

~~~
Millennium
If something like asm.js could possibly kill the incentive to optimize
handwritten code, we'd still be writing everything in assembly.

Asm.js is aptly named, because it's targeted at small, tightly-looped,
extremely performance-critical operations over large amounts of homogeneous
data. That's one of the few things people still use assembly language for on
the desktop. That's all asm.js really is: a compiler hint that you've gotten
desperate for cycles, so here are some coding conventions that will make
things easier to optimize.

~~~
daeken
I think you're completely missing the point of asm.js. It's not possible to
build small portions of your app with this really (no JS object access, no
strings, etc), and it's not intended for that either way. It's really just a
way of compiling C and C++ applications to run in the browser efficiently.

~~~
Millennium
Actually, you can build small portions of an app with it. That's pretty much
all you can do with it, for the very reasons you stated: no JS object access,
no strings, etc. All you can do is the same stuff you'd need assembly for
anyway: super-tight inner loops that work over lots and lots of raw numeric
data.

That's an important part of compiling C and C++ applications to run in the
browser efficiently, but it's only one small part of the puzzle. C and C++
compilers put a lot of work into optimizing this same sort of code, and asm.js
gives them a path to bring some of those optimizations to the browser. But no
C/C++ application, even compiled with emscripten or the like, is ever going to
be compiled solely to pure asm.js. It's just one part of a larger equation.

------
foursquared
"Please keep in mind that I used to work on V8"

In theory a V8 could optimize regular JS as fast as asm.js, but in _practice_
OdinMonkey made this code 3x to 10x faster (or more) with a couple months of
effort. And to boot it is completely compatible with every JS engine, and the
code generated can be cached offline for fast startup (because of the linking
part), and the FFI between JS and asm.JS is trivial.

Basically this post is sour grapes. Mozilla came up with a better idea than
the so-called geniuses at Google did.

~~~
zem
That's a weird thing to say. Is the perception really that mozilla doesn't
have its share of geniuses?

------
hosay123
He makes a solid point regarding polyfills for asm.js: if the specification is
so rigorously defined, then the only fallback a current-generation browser has
on offer when encountering a "v2 asm.js" is to treat it like regular
Javascript. That's a pretty nasty regression, and hopefully one that will be
addressed.

Regardless I still prefer building on Javascript than any proposed
alternative. No matter what happens next, any pristine standard is going to
look like an overextended mess even in just a few years time. So why not pick
the overextended mess we started with.

~~~
niggler
"So why not pick the overextended mess we started with."

What's the starting point? Javascript or assembly? NaCl gets closer to the
original starting point (which predates javascript by more than 20 years)

~~~
bcoates
By my count Javascript is around 5 years older than amd64. If we had gone with
native client back then we'd be stuck with pre-SSE x86 or maybe they'd have
been forward-looking and gone with Alpha or Itanium with emulation for
"legacy" systems.

Also, why the false choice between asm.js and NaCl anyway? The article makes a
pretty compelling case for "neither".

~~~
pifflesnort
> _By my count Javascript is around 5 years older than amd64. If we had gone
> with native client back then we'd be stuck with pre-SSE x86 or maybe they'd
> have been forward-looking and gone with Alpha or Itanium with emulation for
> "legacy" systems._

That's not really how NaCL works. Any instruction that can't break out of the
jail can be whitelisted; this includes all versions of SSE.

Additionally, PNaCL can be retargeted at as-of-yet unknown architectures.

The result is that binaries would have been either shipped as PNaCL-only, or
optimized for i386+SSE1 with fallback to PNaCL. As new hardware was shipped,
new binaries could be targeted appropriately.

This seems reasonable to me; default to portability, provide an option for
best-case performance.

~~~
pcwalton
How do you plan to ensure that authors test and ship working and performant
PNaCl binaries if they and their users are always using the native code?

~~~
pifflesnort
How did Apple developers ship working PPC/m68k binaries? Or PPC/x86 after
that, later PPC/x86/x86-64, and armv6/armv7/armv7s on the iPhone?

~~~
pcwalton
Totally different. In all of those cases, the developers have access to
devices that run the hardware, and they have economic incentive to target all
of those devices. Whereas with your suggestion, developers ship and test
native builds for all of the CPUs on the market, _plus_ one extra "portable"
version for posterity, one that no immediate customers will ever use (because
they'll be using the native versions for their architecture instead). I
suspect developers wouldn't even ship the portable version (too much of a
pain), browsers won't optimize it (because nobody will use it), and developers
won't test it (because nobody will use it).

It's like saying that images are no problem for accessibility on the Web,
because designers know to use alt text. Of course they know they _should_ ,
but we all know what the reality is. A backup "portable" version of an app is
like alt text in this way. Some developers would do the right thing; many
won't, and the Web will be de facto locked in to x86 and ARM forever.

~~~
pifflesnort
That's a bit ridiculously alarmist, isn't it? Heck, you could have lead with
that, rather than waiting for me to reply -- you seem to already know what you
wanted to say.

Won't developers have access to PNaCL runtimes? How is this so different than
Apple developers having access to the other target hardware

It comes down to toolchains and the workflow they're optimized for. With
PNaCL, the portable version is the primary target of the toolchain, from which
one generates other native binaries. You can still generate native binaries
separately, but ideally, PNaCL would lead.

If the tools lead naturally in the right direction, then developers do follow.
If you're feeling _really_ worried about it, define a distribution format that
mandates a PNaCL entry.

------
acqq
The author complains about having to write x = 0 in asm.js blocks where it
simply means "here I declare x to be a number and not undefined". He worries
that "if you remove a single + or | the code above will be rejected by the
validator." But it is good: if your goal is to have a really fast code, and
declared the section as such, you don't want any construct that will make it
significantly slower.

Finally, author believes that the "JavaScript" code can be made "as fast" even
without annotating it like in asm.js. He writes "I don't believe that anything
like asm.js is needed to generate highly efficient native code" but of course
he shows nowhere how something like that cab be achieved. Because it can't.
Unless you somehow specify your assumptions in most of the cases you have to
have the run-time checks. Which are slow.

Observe just for example:

    
    
         c = a + b;
    

If you haven't written before a = 0 and b = 0 you have to assume that a and be
can be strings etc. You can have some code to take the int route but you have
to have runtime checks. Now if you even wrote a = 0 and b = 0 and you're doing
the loop in which you have a + b, you can't assume that the result will fit 32
bits. Which you don't need, unless you really want to do 32-bit arithmetic --
there are algorithms where you get the performance advantage by using it.

The asm.js annotations are a really clever way to tell to the JIT what _you_
(the programmer) expect. The sections allow you to get the nice clean pieces
of clean native code, free of a lot of run-time checks. Speed and much more
efficient memory use. Pure goodness.

~~~
Millennium
Correct me if I'm wrong, but wouldn't the hypothetical techniques needed to
enable something like "asm.js without the compiler hint" also come rather
close to solving the halting problem?

~~~
jkrems
The techniques need to enable something like "asm.js without the compiler
hint" exist and are in use today in JIT compilation (at least to some degree).
Since the source code does not generally change and the generated instructions
may, you can make assumptions first and later on rewrite the instructions if
your assumptions don't hold. At least that's how I understand it. If you would
do AOT compilation and ship the instructions, then you may be right about the
halting problem.

~~~
acqq
Checking if assumptions hold must be done regularly in run time. If you
already know which assumptions always hold you have a significant advantage at
the start: simpler faster and more compact code and the chance for better
"global" optimizations. Postponing a lot of decisions to the run time is never
good. Postponing a little can be OK. Here we're in the range of "a lot" that
we can save. Like "in every damn +,-,/" of any two values in the really long
calculations.

------
asb
"Why asm.js is a JavaScript subset?". Simple, because Mozilla wants the
benefits of the (P)NaCl approach but don't want to have to import LLVM. asm.js
allows them to 1) make use of their existing JIT compiler and 2) avoid
defining a new bytecode format (the benefits of this are questionable). asm.js
is ugly, but it doesn't seem that much more ugly than adding a new multi-
megabyte dependency to every browser.

I suppose an interesting question would be how hard would it have been to
standardise on the PNaCl bytecode format and use that as the input to
${FOO}monkey

~~~
drivebyacct2
I've heard plenty of reasons Mozilla doesn't like NaCl, but that sure isn't
one of them...

~~~
asb
I'm just speculating wildly like most other people here are, but you really
think it wasn't a positive for them that they could reuse the JIT they've
invested in and have expertise in rather than relying on LLVM.

~~~
drivebyacct2
I don't want to speak to that. I was more referring to the notion that they
didn't consider it because LLVM is a large dependency. As others have noted,
emscripten uses LLVM, and it's likely that LLVM will be leverage to coerce
other code in asm.js style javascript. Mozilla's reasons for not wanting NaCl
have been spelled out lots of places.

------
jdonaldson
I would imagine that people would rarely _write_ asm.js code, but instead they
would generate it from statically typed languages (TypeScript, Dart, Haxe).

I admit asm is a bit ugly to look at. But, it's backwards compatible, and
provides a way forward for getting some performance out of js in very specific
cases. It's not going to be an all purpose code path for general use, and I
don't think it's going to take attention away from other general js
improvements.

The only thing I'm skeptical about here is whether or not Google chooses to
integrate asm with Chrome (Setting aside what Apple or Microsoft ends up
doing). It runs counter to the work Google has done with Dart. For that reason
alone, I think there's a significant risk it won't gain traction.

I think the creation of "fast" web performance is seen as a huge carrot from
the big tech companies (MS, Adobe, Google, Mozilla). Each is trying to offer
it in different ways, and at the same time pulling developers into their
specific dev tooling ecosystem.

It's a difficult time to pick languages/tooling. I like Haxe because I know
it'll support the platform of whomever wins (asm.js, dartvm, es6, etc.)

~~~
NinjaWarrior
> I would imagine that people would rarely write asm.js code, but instead they
> would generate it from statically typed languages (TypeScript, Dart, Haxe).

Current asm.js is just for C/C++. Those altJS languages can't make use of
asm.js (Haxe->C++->LLVM->Emscripten->asm.js might be possible but I think it's
meaningless).

asm.js is the answer of Mozilla for "the web standards can't handle AAA games"
but I believe this is far from an ideal solution. And I agree with the worry
of the poster that this ugly hack makes JavaScript more ugly, both on the
specs and VMs.

To be honest, I trembled when I saw the Math.imul proposion to see how some
people are so obsessed with JavaScript...

~~~
azakai
> Current asm.js is just for C/C++

There is already asm.js support for lljs, some thoughts on support in things
like JSIL (C#) and Haxe (as you mentioned).

And in principle anything that compiles to LLVM IR or C/C++ would work through
emscripten.

------
apendleton
Without having actually done much to investigate the feasibility of this, it
seems to me like someone could write a compiler infrastructure that would
generate both asm.js and (P)NaCL output from the same lower-level non-JS code,
since you can get to both from LLVM bytecode. Combined with a JS client
library to paper over the differences between the two, developers could just
write one set of low-level code and not care which fast-path execution
strategy the browser implemented, and the asm.js version, along with whatever
polyfill hacks were necessary to make it work, could be served to old browsers
to run the same code slowly.

This is, I guess, not that different from the OP's suggestion to create a
bytecode and define a one-pass transformation of that into JS.

------
dgreensp
There's a valid philosophical objection here, and I found the article
illuminating about the nature of Asm.js.

The strategy of making a static subset of a language that's easy to compile
works great -- if it's targeted at humans! RPython, for example, means you can
write the Python VM in Python, and the SmallTalk VM (or Squeak?) was written
in SmallTalk using the same approach. The point is part of your code base is
in this restricted language instead of C, and you can bootstrap that way.

If this language is just a compiler target and not meant to be particularly
human-friendly (RPython has classes and mixins) then making it a weird subset
of JavaScript is a little more dubious and without precedent that I can think
of.

~~~
acqq
It's definitely not "just a compiler target," not more than the assembly
language in which people still write some code by hand when there's need for
that. The real world example:

<https://github.com/srijs/rusha>

(see the benchmarks -- Firefox 21 uses asm.js) and the source

<https://github.com/srijs/rusha/blob/master/rusha.js>

I don't see that the code got ugly. The calculations needed are the same, the
most obvious differences from the "non-asm.js" code is the "asm.js" and a few
|0 marks. And some of such |0 constructs can improve speed even on the
browsers which don't do full "asm.js". So the engines will get smarter by
recognizing such constructs even without the full support of "asm.js"
segments. It's a win-win already.

~~~
munificent
Right, but your example here is a particularly skewed one. It's a hashing
library. All it does is take integers and do arithmetic on them. Most real-
world application code is not at all like that. Asm.js doesn't even support
_strings_ as far as I know.

~~~
acqq
Asm.js is exactly made for things like that: the pieces of code that don't
depend on "strings" but calculate a lot. And for things like this:

<http://bellard.org/jslinux/>

For "strings" the existing JITers do already the good job. You can just use
JavaScript as is then.

~~~
munificent
Yes, agreed. asm.js is a great fit here. My point was that that fact doesn't
generalize well to other problem areas.

Earlier you said asm.js isn't _just_ a compiler target, but if your program
uses strings, or objects, or closures, or GC, then it's not going to be a good
fit to use asm.js.

------
mappu
In related news, researchers from Mozilla and UC San Diego with support from
Microsoft Research have recently published another approach to typed
JavaScript, named Dependent Javascript or "DJS". This isn't focused on
performance so much as correctness.

1\. <http://lambda-the-ultimate.org/node/4700>

2\. <http://goto.ucsd.edu/~ravi/research/djs/>

------
ajanuary
This seems to assume asm.js came first. Really it's a development build on top
of what things like emacripten were already doing.

There doesn't really seem to be much criticism here of asm.js as a bytecode,
only as a syntax.

------
astrodust
Compiling JavaScript down to asm.js format JavaScript might be messy, but it
might lead to better performance if your compiler is better than the JIT
engine.

I'm still not sure why a compact, concise, standardized bytecode format isn't
being pursued. Perhaps minified, gzipped asm.js encoded JavaScript is as close
as we'll ever get.

~~~
Drakim
> is as close as we'll ever get.

This is the point I think the author and a lot of people are missing. It's not
always about what is the best possible design, instead it is often "what we
will get". Politics, ideology, and timing can often come in the way of "the
best design".

I would love to use NaCl (I was cheering for it up until recently), but if
only Chrome is implementing it then it's about as useful as a screwdriver that
doesn't fit any screws.

asm.js is already a stronger candidate because I can use it right now and it
will work everywhere. Obviously the browser vendors has to create asm.js
specific optimizations for it to be truly great, but that is like fuzzing over
the handle, grip and material of the screwdriver. It fits the screws, it gets
the job done, it actually _works_.

What does it matter how great your technology is if it doesn't work? What does
it matter if NaCl is ten times faster if I can't actually use it? From what I
see, Mozilla isn't very hot on the idea of adopting NaCl, and Microsoft will
probably not even touch it in this millennia.

If a client wants me to produce something, I can't use NaCl, because it won't
actually run in non-chrome browsers (without installing plugins).

To me it appears that the choice is either asm.js or nothing. NaCl just isn't
happening.

~~~
munificent
> asm.js is already a stronger candidate because I can use it right now and it
> will work everywhere.

This is fundamentally not true. We tend to think of "better perf" as not being
breaking the web, but that isn't always the case. Imagine a game written using
asm.js. Plays beautifully at 30fps on Firefox. Great! And it runs on every
browser, right?

Well, if it runs at _three_ FPS on Safari, then as far as the game developer
and the player are concerned, no, the game doesn't run on Safari.

~~~
wycats
Does this mean that Chrome "broke the web" by being so fast while IE6 was
still in circulation?

~~~
munificent
If you're going to use IE6 as the baseline that pretty much every browser was
breaking the web relative to it, including later versions of IE, weren't they?

I don't recall many websites at the time only being effectively usable for
perf reasons in Chrome, but my memory is a bit hazy. Certainly, there were
fewer very JavaScript heavy sites, and most of HTML5 hadn't been created yet.
That meant there were fewer opportunities to build web apps that _required_
fast JS. Also, Chrome wasn't as fast as it is now.

But, yes, if people were building apps then that said "only in Chrome" then
that would imply that to some degree Chrome was breaking the web. Fortunately,
in that case, the other browsers caught up quickly and resolved that tension.

------
aeflash
> It can’t allocate normal JavaScript objects or access normal JavaScript
> properties. No strings. Only arithmetic and typed arrays (a single one
> actually with multiple views).

I think he is missing a core concept here. You _can_ create and modify
strings, just at a lower level. An array of ints can be used as a char array,
which in turn can be used as a string. You just have to interface with it at a
lower level, probably implementing your own C-style strlen/strtok functions.
It will be more complicated, especially if you need to accommodate unicode,
but it is doable. Granted, there is no advantage to abandoning the built-in
string manipulation functions except speed, but you would only use asm.js when
speed absolutely matters.

At a more fundamental level, when you have access to memory through a stack
and/or heap, and can create arrays of ints with which you can do normal
arithmetic and load/store operations, you really can do anything. After all,
that is the entirety of what _actual_ assembler code has to work with. You
just have to make your own abstractions.

~~~
mraleph
When I say "no strings" I mean JavaScript built-in primitive string values. I
will amend the paragraph to make it explicit. It was added because I talked to
people who think that just adding "use asm" on top of their node.js module
will make it go as fast as C++ without realizing that asm.js is a very limited
subset with its own rules.

You can surely represent a JS string as a Uint16Array or Uint8Array, but
copying things in and out of emulated heap into real heap will cause penalty.
You will also have to reimplement a lot of functionality that host JS engine
provides. Trying to implement say a regexp engine in asm.js that would be as
performant as V8's built-in on would be a challenge.

Yes, you can do anything. I don't dispute that. But you have to do it manually
and sometimes you are replicating functionality that already exists in the
host engine e.g. you might implement GC, but it will less efficient than
builtin one.

------
guilloche
Yeah, I have the same bad feeling on asm.js.

If we need c/c++=>llvm=>javascript/asm.js for performance reasons, then why
not just embed llvm inside web brosers? Isn't it much easier, and much
cleaner?

------
coldtea
OK, let's say that with stuff like ams.js we never get true native performance
than say NaCL would give.

Isn't that also a good thing?

I wouldn't want the web as a platform to be that good that it kills all native
desktop applications, essentially turning every computer into something like a
Chrome Book.

Isn't that a real danger with stuff like NaCL?

~~~
GnarlinBrando
> I wouldn't want the web as a platform to be that good

What? Are you so ideologically caught up that you actually wish something wont
get good? It is totally reasonable to to think something isn't the right
approach or a waste of time, or to not like the workflow, etc. But to actually
wish that something wont get good enough to be a general solution even if it
can? How does that make any sense?

~~~
coldtea
> _But to actually wish that something wont get good enough to be a general
> solution even if it can? How does that make any sense?_

It makes a lot of sense because things do not happen in isolation. A "good
enough web platform" could bring a lot of OTHER outcomes too.

I wrote one in my comment already: all computers because Chromebooks,
glorified clients.

That has other consequences: you loose control, you don't own your apps (the
company does, and it can take them from you in an instant, like Google
Reader), etc. Not to mention the privacy implication of ALL apps running in a
web browser, getting their data remotely. Or the implications for companies
and governments locking content, pushing you out, demanding a premium, etc.

~~~
fzzzy
I don't see that those consequences follow, at all. I see a natural evolution
from where we are now to a world where people own their own servers in the
cloud and run all the software on them.

Or, if you really don't want any data to go over the wire, just run all the
web app servers locally.

There was a big swing from the idea that at&t would sell you a terminal that
was connected to a central mainframe, to personal computers that were
distributed, back to everything being centralized because the advantages of
the web were compelling and centralizing things was the natural path. Things
will swing back again to decentralization, but the difference this time is you
will be able to access all of your data from anywhere at any time.

------
nivertech
I find asm.js pointless. If all you need a fast numeric calculations in
JavaScript, the better compiler backend would be WebCL - OpenCL binding to
JavaScript.

~~~
michaelwww
Could you expand on this? It seems like an apples and oranges comparison.

~~~
nivertech
Asm.js only allows numeric operations on emulated heap buffer. You can do much
better with OpenCL on CPU device.

Asm.js intended to be used as a backend for compilers. One of OpenCL use cases
is the same.

Asm.js code pretends to be a JavaScript code, OpenCL does not, but there is
WebCL - a JavaScript binding standard for OpenCL.

~~~
michaelwww
Asm.js is still JavaScript. You can do all kinds of things that JavaScript
can't do by itself if you call native code with a plug in. That's the
difference. No plugin. No installation.

~~~
nivertech
What's the difference between Mozilla deciding to bundle Asm.js with Firefox
vs. Google deciding to bundle WebCL and WebGL with Chrome?

~~~
michaelwww
I refer you to <http://asmjs.org/faq.html> to understand the difference.
Particularly the Question: "Why not NaCl or PNaCl instead? Are you just being
stubborn about JavaScript?"

------
dvt
What bothers me about asm.js is that no one really needs it. I mean don't get
me wrong, Unreal III in Firefox is pretty cool, but very very few developers
will seriously consider writing a production game for the browser. So then
what are we left with?

FFT implementations? OCR? Real-time fluid mechanics? Who does these things in
a browser? What JS needs is to finally standardize WebSockets (across the
board), to seriously consider multi-threading (not this WebWorker nonsense),
to implement optional type checking (like Dart), etc, etc.

The effort that's going into asm.js should go into building better JIT
compilers. We seem to be forgetting that JavaScript is a _web programming_
scripting language, not some general-purpose low-level esoteric programming
language. There are so many improvements JS could make on the web-side of
things (you know, where it's actually used) instead of on the "cool 3D Unreal
III game-programming, bytecode-crunching, Jacobi-simulating"-side of things.

~~~
tree_of_item
The goal of things like asm.js is to make JavaScript a general purpose, low
level programming language. I'm not sure why you consider it esoteric, though.

People don't do those things in the browser because asm.js (or some
alternative) isn't widespread yet. When it is, they will.

~~~
dvt
Exactly. JS was never meant to be a general-purpose language. Using the right
tool for the right job is a fundamental aspect of software engineering. If you
use C for writing web-apps and JavaScript for writing operating systems,
you're doing something very, very wrong.

The irony here is that JavaScript isn't even a very good language, anyway. So
when lambdas are implemented in a language like C++11 (to the chagrin of many
programmers that shun the unnecessary complexities of recent revisions of
C++), that's one thing; but when we're trying to use JS for low-level
programming, that seems very silly.

And as far as your second point is concerned, I beg to differ. Java has been
able to run OpenGL in the browser for ages. Flash can also do hardware-
acceleration. As can Unity3D. 99% of computers have either Flash or Java
installed, and yet, no serious developer (barring maybe a couple of indies)
would seriously consider Java/Flash as a serious platform. I don't think
HTML5/asm.js will change that.

~~~
macspoofing
>JS was never meant to be a general-purpose language.

The original designers and implementers of the Internet, the Web and HTML
probably never envisioned the myriad of ways those technologies would be used
(abused?). So what?

>Using the right tool for the right job is a fundamental aspect of software
engineering.

So tell me, what is the right tool to build a cross-platform application that
runs on every system, without requiring native install (and with every other
benefit of a typical 'web-app')?

>If you use C for writing web-apps ...

WHY?!? How can you even say that in light of the Unreal demo that Mozilla
showcased, where you have a high-performance game running on a standard
browser. Given that, you still see zero potential? I don't know if browser
gaming will take off, but that's irrelevant. If the browser can run a high
performance game, it tells me devs can make use of that processing power to
build any sort of web application that traditionally would have needed to be
native. You don't see the potential in being able to build a web-based
Photoshop or AutoCad?

>The irony here is that JavaScript isn't even a very good language, anyway.

You're right, it isn't, so what? HTTP isn't the best protocol, and neither is
TCP, but try replacing them with any 'superior' protocol. JavaScript, like
HTTP, and TCP is ubiquitous, that's its strength.

>no serious developer (barring maybe a couple of indies) would seriously
consider Java/Flash as a serious platform.

I consider both serious platforms for gaming and otherwise, even with the
knowledge that they will be replaced by HTML/JS on the client.

------
askimto
Looks like the asm.js Jedi mind trick didn't work on someone :)

------
snird
If it is not JavaScript, and it gains it's performance by static typing -
well, we already have a language like that, and it's more production ready
than asm.js - it's Dart.

~~~
mraleph
Dart is not statically typed.

------
drivebyacct2
Isn't he describing Dart in his second to last section?

~~~
mraleph
I am not sure what do you mean. Dart is a dynamically typed language, not a
bytecode. Dart's type annotations don't even have any implications on
performance and not used for optimizations by either Dart VM or dart2js.

~~~
kyrra
Though, you can run the DartVM in "checked" mode which will validate all type
assignments to make sure they match the types annotated in your code.

