
On Asm.js - scribu
http://acko.net/blog/on-asmjs/
======
safetydank
I feel like PNaCl is the technically superior approach - define a stable set
of LLVM bytecode and build an interface to run it in the browser. But the
uptake is a problem, no other browser maker wants to adopt a big chunk of code
controlled by Google, tailored to run optimally in Chrome.

So asm.js took a beeline - leveraging existing Javascript machinery for
security/JIT and shoehorning a way to run executable LLVM on top of it. The
fact that it's Javascript is just a detail, a legacy of the days when one
vendor (Netscape) was able to push through a standard for running code in the
browser.

In today's fragmented browser landscape I find it hard to believe a consensus
could be reached again. Most of the major browser makers (Google, Microsoft,
Apple) have their own platform agenda to push - in that context asm.js's
compatibility with existing Javascript engines gives it the best chance of
adoption.

But I agree, the hoops that had to be jumped through are a damned shame.

~~~
flohofwoe
From a developer's perspective PNaCl and emscripten is almost the same to work
with, the difference is just a couple of hundred lines of wrapper code (less
then the differences betwenn iOS and Android wrapper code) and you need to
find a higher abstraction layer for threaded code. And if the differences on
the surface are so small, and the performance difference is acceptable as well
(it is IMHO), I don't really care how the goal is achieved under the hood.
Asm.js or PNaCl are not platform-lock-ins like DirectX or Flash. It's just
POSIX + OpenGL with a handful of platform-specific functions, and practically
the same code compiles on any other POSIXish + OpenGLish platform.

~~~
iso-8859-1
You're just considering the game-perspective, where you don't need anything
but GL and sound. What about WebRTC? What about DOM manipulation? You can't do
this from Emscripten very well.

~~~
flohofwoe
It's actually really easy to build C interfaces to any Javascript API or lib.
Since compiled code is just JS you can just directly call from C code into JS
code and vice-versa. Most of emscripten's CRT wrapper is actually implemented
in hand-written JS, as well as the OpenGL-to-WebGL wrapper. For an app which
mainly needs to do DOM manipulation it is probably better to write it mostly
in traditional JS and only implement the performance sensitive stuff in a C
library compiled to JS. Best of both worlds...

------
flohofwoe
What I miss in all those discussions regarding JS, asm.js and PNaCl is that
the web is the best software distribution platform we have by a huge margin,
this is really its overwhelming killer-feature. All the user needs is an URL.
No "downloading", no installation, no special user permissions, no app shops,
no gate keepers, no walled gardens, and everything is automatically multi-OS
and multi-CPU-architecture. The web as a runtime platform may not be ideal,
but the web as a "software distribution platform" rocks. For this I'm even
happy to give up a few CPU cycles. And no platform should be tied to a
specific language. The more choices there are, the better.

~~~
pwang
Have you actually shipped a complex codebase to the web? There are a TON of
major issues which are just as bad:

Old problem: Downloading

New problem: Downloading. Large JS apps have to asynchronously load
potentially very large codebases, _every time the app is loaded_

Old problem: Installation

New problem: Installation. What if the user has NoScript? AdBlock? Mobile
Opera vs. Mobile Safari vs. Chromium vs. IE.

Old problem: Special User Permissions; gate keepers

New problem: Proxies. Websockets. Anti-virus software. On-machine firewalls.
Corporate firewalls. "Special" toolbars and plugins that redirect the browser.

The web is not a "software distribution platform". It is not a "distribution
platform", because code is retrieved on-demand and run, and there is no simple
way to "cache" that locally and re-run it. (Chrome App Store does not count,
because it is antithetical to the model you've described). It is not even
software in the traditional sense that you mean, because everything is
inherently client-server, so most of the app lives on the server or in the
cloud.

~~~
ehsanu1
None of the things you've listed are actually really problems, or have well-
known solutions. HTTP caching solves the downloading problem for most classes
of application. You can also run apps locally with app-cache and local storage
(and in the future IndexedDB), though I'll grant that this isn't absolutely
perfect today.

I don't understand your "installation" issue. A user with NoScript knows how
to turn it off for a web application they want to use, and generally do so.
They just want to retain control over JS execution. AdBlock is not related to
actual application delivery, but revenue generation, somewhat orthogonal.

Having to support cross-platform quirks is also something that isn't unique to
the web. If you support multiple versions of iOS for your app, you will hit
similar issues. Not to mention if you wanted to actually be cross-platform and
work anywhere other than iOS with the same app.

------
captainmuon
Imagine there would be a language that would compile to proper bytecode (not
JS), that would run on a standardized platform which is present on almost
every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait,
that already exists and is called Java.

Java has gotten a bad rep lately due to some high-profile drive-by-malware
bugs. But if the java codebase would have gotten the same intensive care that
the webkit codebase got, this would no longer be an issue.

Many people remember java to be sloooow. When I first came into contact with
it in school, that was certainly the case, but since a couple of years it has
had a modern JIT that could easily rival native code.

Java applets are ugly, sure, but that is largely due to the decades old AWT,
and the poor font support it used to have. With SWT, you can have native
widgets (dunno if they work in Applets, but they are nice on the Desktop), and
with antialiased drawing you can get the same results as with HTML5 canvas.

Java applets (and Flash, and Silverlight) died for marketing reasons, and
political reasons. There were no _unsurmountable_ technical issues. The
outcome is that we are stuck with "worse is better" for the foreseeable
future, only max. 50% to 1% of the possible native performance, and a bunch of
restrictions we only slowly realize what they mean (no sockets, no signed
applications, no anonymous/serverless mashups, less hardware access than we
used to have, suboptimal caching, suboptimal tooling like languages,
debuggers, content creation tools (I haven't seen anything that can replace
Flash for simple vector animations yet) and so on.

~~~
adamtj
Asm.js is not Javascript. It's native code!

It's not a VM bytecode. It's assembly language, and the target machine is your
native CPU. It is sandboxed by the browser. It is present on any computer with
a browser and Javascript, which is more computers than have a browser and Java
plugin, or any other plugin for that matter. Asm.js is less mature that Java,
but it will grow up. It is currently supported by more browsers than Java, so
even if it's crappier right now, it will eventually surpass and replace Java
in the browser.

If you are thinking that asm.js is Javascript or is interpreted, you're
thinking about it wrong. Think about it this way: Take an arbitrary
executable. If you dissassemble it, you have some sort of assembly code. There
are several different assembly language syntaxes, but they're all basically
the same. Asm.js is basically just another assembly language, with two key
differences.

The first difference between asm.js and any other assembly languages is that
the only existing asm.js assemblers happen to assemble executables that are
sandboxed by your browser. You can't do syscalls to use sockets or files or
the Windows registry. You can't fork() or run non-asm.js executables. Still,
if you can live with the "syscalls" that the browser gives you, you can run
native code in any browser. The browser is your operating system.

The second difference between asm.js and other assembly languages is the
really clever part! It is not just assembly. It is both valid assembly
language that can be assembled to native machine code and also valid
Javascript that can be executed by a Javascript VM -- and both ways of looking
at it are _semantically equivalent_!

It's like being able to write a novel where the text is both valid English and
valid Spanish at the same time, and the plot is the same no matter which
language you speak.

So I lied. It is Javascript. But you shouldn't think of it that way. You write
Javascript. Your compiler writes assembly language. Asm.js is assembly. The
Javascript aspect is just a clever backwards compatibility hack. It could have
been specified to have a more traditional and readable assembly language
syntax, but then you'd need plugins and nobody reads assembly anyway. As is,
it's machine code that happens to be able to run on any Javascript VM. This
means you can deploy native machine code to any browser without a plugin. In
the event that your browser is old and doesn't contain an asm.js assembler,
that's ok! Your unmodified native code will still run, albeit more slowly, in
a plain old Javascript VM such as everybody has had for years. Except lynx
users.

The browser as an operating system is currently worse than a Java runtime
plugin in that the browser has less functionality. However, browsers are
currently better in that they have more penetration and a higher velocity of
improvement. Long term, the browser as a full-featured operating system makes
more sense than as a mere scriptable document viewer slash plugin container.

~~~
iso-8859-1
It's assembly language the same way LLVM bitcode is assembly langauge, which
means IT ISN'T. It is also represented in text, which means that it is several
times larger than it needs to be.

Another problem with Asm.js in practice is that it's used with Emscripten
which doesn't define the syscalls you talk about. All the
DOM/WebAudio/WebRTC/etc API's have to be redone in Emscripten's headers. GL
was easy, because WebGL is so close to EGL and friends. But what about DOM
manipulation? Emscripten can't really do this yet.

These two disadvantages happen to be problems solved in PNaCl, which has a
compact bitcode (which doesn't pretend to be JavaScript) and a proper API
(Pepper).

~~~
adamtj
You are technically correct - the best kind of correct! While I was being a
bit loose with my language, I don't think that changes the point.

So maybe it's not an assembly language or a bytecode, but that's a pretty
unimportant distinction. Those are all intermediate representations (IR). A
good browser will JIT your asm.js IR to machine code in much the same way that
a good JVM will JIT your bytecode. An old browser will interpret it more
slowly, but it will still work.

Asm.js may be crappy at the moment, but it will get better. It's an easily
JITtable IR for the web that's already supported in all browsers, even the old
ones. And the security is basically free since that's already being paid for.
Yes, it's a bloated text encoding, but gzip is pretty effective. No, it
doesn't have great compiler support yet, but Emscripten and equivalent will no
doubt have lots of useful headers and emulation and translation libraries very
soon. Asm.js is going to win for the same reason that Javascript won:
everybody already has it.

~~~
espadrine
Nitpick: asm.js is designed for AOT, not JIT, compilation.

A good browser will AOT asm.js, not JIT it.

(In other words: pre-compiled, not compiled on the fly. Consequence:
immediately as fast as a JIT would have… eventually… made it, but initial
pause while compiling.)

------
fidotron
This discussion is missing the simple point that the web is rapidly gaining
all the flaws that Flash used to have, without the nice (for some) editing
environment.

The web really isn't suited for app development at all, as the native mobile
markets have demonstrated, while the viability of it as a document delivery
platform diminishes every time the content gets hidden behind a massive layer
of scripts.

~~~
leokun
> the web is rapidly gaining all the flaws that Flash used to have

False.

1\. Modern JavaScript vms are sandboxed, not native plugins with unending
security holes.

2\. It's nearly all open standards and open source, not proprietary closed
source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium,
blink, webkit.

3\. It works on mobile devices, flash doesn't.

4\. The tools are out there. Check out appcelerator or unity's tools.

5\. Flash never had the native performance or hardware acceleration that
modern JavaScript has.

6\. Don't think Flash ever had the kind of momentum JavaScript has. Like has
anyone ever made a derby.js for Flash? A sharejs? Compiled other languages to
ActionScript? With source maps to help?

7\. Flash avoids all kinds of privacy settings and plugins in your browser.
Flash gives you less control.

8\. Even Adobe has moved past Flash, these arguments are all done, why haven't
you moved on?

~~~
captainmuon
I think there are a couple of misconceptions here:

> 1\. Modern JavaScript vms are sandboxed, not native plugins with unending
> security holes. Flash _was_ sandboxed (just as Java). You were strongly
> restricted in what you could access with ActionScript. Of course, the
> security was poorly executed. I blame it on the fact that it was developed
> in a different time, without the experience and tools we have today, and
> that it was closed-source. Still, native plugins don't have to be inherently
> insecure.

> 2\. It's nearly all open standards and open source, not proprietary closed
> source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium,
> blink, webkit. True, but I'm starting to think "Open Standards" was a huge
> Trojan horse. \- It lead to, or continued, a huge monopolization of
> platforms. Only a few large companies are able to maintain modern browsers
> (see the demise of Opera). This is bad, because they can push politically
> motivated restrictions on their users. (Firefox has a whitelist to only
> allow certain media codecs to play, although the system would support more.
> I could modify the source for myself - I did - but it's of no use, as the
> people visiting my sites won't be able to use it. I don't have the marketing
> power of Mozilla or Google.) \- The "open" "web" platform limits what kinds
> of apps you can write. You can't really write apps without an (accountable!)
> central server. Without sockets, you have no Bittorrent, no P2P, no Tor, no
> Instant Messaging... \- I think it also pacifies people who would otherwise
> be worried about today's locked up platforms. "You can always write a web
> app if you don't get in the app store."

> 3\. It works on mobile devices, flash doesn't. Which was a political
> decision, not a technical one. There used to be thousands of free Flash
> games, that would have ran with minimal porting on mobile devices. But Apple
> couldn't control flash, they wouldn't get their 30% cut from Flash apps, and
> they couldn't censor apps. So they forbid Flash on iOS, and crippled it on
> OS X, which was one of the main reasons for its demise.

> 5\. Flash never had the native performance or hardware acceleration that
> modern JavaScript has. Flash had support for native video playback before
> HTML. It had 2D acceleration for animations before there was canvas, and
> Shockwave Flash had 3D acceleration years before WebGL.

~~~
leoc
> True, but I'm starting to think "Open Standards" was a huge Trojan horse. -
> It lead to, or continued, a huge monopolization of platforms. Only a few
> large companies are able to maintain modern browsers (see the demise of
> Opera).

Free-slash-open-source programs are like banks in this way. In principle, a
bank that fails can always be shut down rather than bailed out, and this is
what justifies the existence of private-sector banks. In principle, an open-
source program can always be forked if you can't persuade the maintainers to
make the changes that you want, and it's always been agreed that this is a
central, essential requirement for a program to be considered free-slash-open.
But some programs are, in practise, TBTF - Too Big To Fork. A program can be
"big" not only by having a large codebase but also through network effects,
such as having vast amounts of client software tied to one of its interfaces.
The big-boy Web browsers are TBTF in both these ways. So if, for example,
you're insulted by Google's decision to knife MathML (as everyone should be),
it's relatively easy to roll a Chromium with MathML inside, but you'd still
effectively be just maintaining a branch, because you'd have no hope of
maintaining "your" browser independently if Google took the whole Chromium
codebase in a direction you didn't like - and more importantly, good luck
getting users to use your browser or developers to create MathML webpages to
support it.

A second example of the phenomenon is the Gnome/KDE mess - _part_ of the
reason that the Linux desktop sucks is that, even if you have a clear idea of
how it could be better, it's still a whole lot of man-hours to spin up an
alternative implementation, get apps customised for it, and so on. In general,
an area is the domain of TBTF to the extent that you have to win a political
persuasion battle or spend a truckload of your own money _before_ you can
produce a viable implementation of your alternative idea.

The solution, to the extent that there is a solution, to these problems is a
technical one: find a way to shrink large programs and/or break them up into
small, reasonably independent ones. (Of course all social/political problems
are technical problems in disguise just as all technical problems are
social/political problems in disguise. ;) ) In the case of the web, this is
why the vertically-integrated Web browser must go away
[https://news.ycombinator.com/item?id=6720793](https://news.ycombinator.com/item?id=6720793)
.

------
pwang
It's very simple - there is no magic here. asm.js is just a "pidgin
instruction set architecture", to allow communication between an emerging set
of VMs - the browser runtimes - and a compiler backend. (The front-ends are
the LLVM front-ends.)

The article is exactly right in saying that it's a way to route around JS.
Javascript fanboys should _not_ be praising asm.js, because it's a way to
route around them. (Which is fine by me; JS is an abortion of a language that
cannot die fast enough.)

I see asm.js as the Revenge of Compiled Languages. Coupled with generic
interfaces for accessing underlying graphics and audio hardware, we're just
right back where we started with Java applets. Write your apps in whatever
language; run in the browser.

~~~
soapdog
pwang, there are some people who actually enjoy coding in JS, believe me I am
one of them.

One cool thing about JS is that you have runtimes for it in computers,
tablets, phones, TVs and most current videogames so you can experiment and
build stuff for a variety of hardware that no other language can reach as
easily (of course you can reach anything with C but it is not easier).

Remember all that could be done in JS two years ago and all we could do now.
Imagine by the end of the next year what we'll be able to.

I don't care if people are using LLVM to cross-compile other languages to the
JS runtime, this kind of approach and research makes better runtimes and both
camps benefit, the people who hate JS can use their fav language and those
that enjoy JS end up with a better runtime.

~~~
m0a0t0
I (not pwang) think it's an abortion of a language because the syntax, scoping
and the language as are a whole is a pain to use. Sure, it runs on pretty much
everything but that doesn't mean it's suddenly enjoyable to use. The only
outstanding feature of JS is that it runs on lots of stuff but it need not be
the only one.

As you say getting other languages to run is a good thing because those who
don't like JS don't have to use it (or indirectly use it with stuff like
Coffeescript).

~~~
soapdog
just to be clear, I don't think that JS reason to be enjoyable is that it runs
everywhere. I do enjoy the prototypical inheritance, I like the scope and the
language in general. I don't like coffeescript but not due to a technical
reason, its about personal taste, I'd rather work in JS. To each their own,
the fact that we have a non-proprietary language that is available everywhere
is a very good thing.

IMHO most people that do not enjoy JS is because they approach it from a
mindset of an OOP programmer. People try to treat it like Java or approach it
like a toy language to cook quick jQuery script then they feel frustrated. I
am not saying that JS is everyones cup of tea but some people like me enjoy
it.

------
endemic
This article neatly sums up my thoughts on asm.js. On the one hand, I really
like the fact that Mozilla is doing a lot to promote Javascript (which I
usually enjoy programming in). On the other, asm.js basically destroys any
reason to write Javascript.

For someone interested in web-based gaming, it really discourages me from
investing in Javascript-based tools, since the future _won't_ be hand-written
Javascript. It's only a matter of time before a tool like Unity includes an
asm.js export target.

~~~
agentultra
That's a good thing.

We spend too much time developing languages instead of environments. Unity is
a good environment for developing games. If your goal is to make a game you
should use Unity (or whatever... GameMaker has an HTML5 export module; use
that). Javascript has nothing to offer you to enhance your productivity and
develop your game.

------
andyjohnson0
I'm very impressed by the Epic Citadel demo. But how do you debug a C/C++
program that has been converted to asm.js? Whats the current tooling like?

~~~
flohofwoe
Usually I'm debugging a native "desktop build" of the code in VStudio or XCode
since 99% of the bugs are not emscripten specific. But having said that:
browsers are becoming a really good debugging platform as well. emscripten can
emit source maps, which kinda lets you directly debug the C++ code in the
browser (not as fluent as in a native debugger yet, since only code lines are
mapped, not variables, but the potential is clear). Some WebGL related
debugging tools are really good in the browser (e.g. Firefox' WebGL shader
debugger or the WebGL inspector browser extension). Especially on OSX which
doesn't have very good debugging tools for desktop GL the browser WebGL
debugging tools are actually better then what's available as native tools (not
as good as PIX or NVIDIA's NSight tool on Windows though).

~~~
andyjohnson0
Thanks! I was thinking specifically of bugs that occur in the browser target
but not the native build.

Given your experience that "99% of the bugs are not emscripten specific", I'm
very impressed with how emscripten can retain the semantics of the native code
across the conversion and optimisation process. Obviously thats what any
compiler does, but in this case the target environment seems to me to be much
more complex than a physical cpu: threads, memory management, etc.

~~~
masklinn
> in this case the target environment seems to me to be much more complex than
> a physical cpu: threads, memory management, etc.

It compiles for a restricted subset of javascript. There are no threads (there
are no threads in javascript itself in the first place), and it works around
memory management (it sets up big typed arrays, and memory allocations are
slices of that)

------
charlieflowers
asm.js is brilliant because of the current situation we are in. However, the
current situation we are in is silly, and can correctly be called a "tragedy
of the commons."

Why? Well, for example, is JavaScript truly the best language we'd be able to
create for browser scripting, or did it win by historical accident? (And I'm
actually a _fan_ of Javascript programming!)

And beyond that, we'd all like something that gives us safe native-speed
rendering control in the "sandbox". Silverlight was meant to, as was
Flash/Flex. But those were proprietary, and we didn't want one company to have
"control of the web." HTML 5 hasn't been what we hoped for.

So basically, we're one big, divided bureaucracy that is not making rational
decisions (what big divided bureaucracy does?).

I guess what might happen is something new will eventually come along (who
knows how long it will be) that actually displaces the web as we know it. It
will be an adoption-tsunami, similar to what the web itself was, and therefore
it will be able to ignore this series of historical accidents that we're
chained to today.

------
ma2rten
I agree, an Unreal Engine compiled to javascript doesn't make sense. It would
make much more sense if it were compiled to some kind of bytecode (like NaCl).
That will ultimately give you better performance, less loading time, etc.

However, maybe there are some libaries which compiled to asm.js are small
enough that they can still run in a browser without asm.js support, e.g. an
compression or an encryption algorithm compiled to javascript. Maybe that is
the sweet spot for asm.js: You are still able to support Safari and IE though
native javascript, but it's faster on Chrome and Firefox.

~~~
ozten
> I agree, an Unreal Engine compiled to javascript doesn't make sense.

That demo runs at 60 FPS in my browser, allowing me to casually spend more
money on more video games. Your objections seem ideological, as opposed to
perf benchmarks, distribution improvements or other quantifiable terms.

Can you expand on why it doesn't make sense?

~~~
CmonDev
Just make sure you don't refresh your browser cache after downloading a couple
gigs of assets.

~~~
flohofwoe
Well that has nothing to do with JS or asm.js, only how the game manages its
assets. The Citadel demo needs to preload all data before it starts which is
very easy to implement but is of course a suboptimal approach to asset
loading, a proper game would only load what's really needed to start (4..5
MBytes max?), and from then on stream everything on demand in the background.
It's about how much new data can be presented to the player per second, not
how big the game data is overall. Asset sharing/reuse, data compression,
procedural generation are all important topics for browser games in general,
not just games running in asm.js.

------
macspoofing
>It means JavaScript has nothing to do with it, it's just the poison we ended
up with, the bitter pill we supposedly have to swallow.

Yeah. That's right. If we could remake the web from the ground up, and had
100% buy-in from all the major parties (corps and devs) to implement and use
the new common standard, JavaScript would not be the central language. But we
can't. So welcome to reality.

------
haberman
On an unrelated note, I absolutely love that site's header animation (like
what you see if you scroll up and/or click "play").

~~~
ohazi
Is _that_ why mobile Firefox kept crashing? Dammit, don't send that stuff to
my phone if I didn't ask for it.

------
Torn
The citadel demo, if anyone's looking for it:
[http://www.unrealengine.com/html5/](http://www.unrealengine.com/html5/)

The article seems pretty doomy regarding asm.js - is it really going to take
off and become an unweildy/frozen standard? Or is it of interest only to
people writing game engines in pure JS / vanilla browser technologies?

~~~
girvo
Honestly, I've got no idea what the OP was trying to say... I think they are
implying that asm.js is _cool_ , but they're annoyed that it's being built on
top of JS rather than from-scratch.

~~~
Ygg2
Second this. I get that they are saying - asm.js is cool, but it's on JS, so
eugh.

Personally I'd love for a really low level language (statically typed, little
if any magic, no-GC, multi-threaded) to work across all browsers, but I don't
think browser vendors can just sit and say - here is the perfect cross browser
language that will make all of net easy.

Perhaps the best strategy is to have low level strict language on top of which
you build more easier to use constructs - which describes IMO both asm.js and
PNaCl.

~~~
acqq
As the writer of the native compilers, I read the article as written from the
kind of the developer who always developed in interpretative languages, who
sees asm.js as "wrong" because "it's not the JavaScript he would write by
hand.

And again. as the writer of the native compilers, I'm absolutely pro asm.js. I
believe it's the best direction that JavaScript optimization can take, solving
more hard problems elegantly. Including the fact that asm.js is a better
representation than most of bytecodes (or even all). Seriously.

~~~
Ygg2
Interesting. Why do you consider that asm.js is a better representation than
most bytecodes?

Don't get me wrong JS is awesome (and so is asm.js) but I think stuff like
static typing and multi-threadedness are JavaScripts Achilles heel.

~~~
acqq
We've already tried native and bytecodes: ActiveX, Java, NaCl, Silverlight.

------
gitaarik
So Asm.js is a strict subset of Javascript, and the author is saying that
Asm.js is only useful when you want to compile a C/C++/Whatever library into
Javascript, and that it's not interesting for Javascript developers
themselves. Then I wonder: why? Can't you write Asm.js code directly (instead
of compiling to it)?

~~~
flohofwoe
You can but it's a bit like writing inline assembly code. The code doesn't
look very nice and you lose LLVM's optimizer passes which kick in before the
JS code generation.

~~~
dirkk0
But you could take Brython or Pythonium and make a Python2asmjs compiler (as I
suggested in their forum:
[https://groups.google.com/forum/#!topic/brython/I7VoZNCiphI](https://groups.google.com/forum/#!topic/brython/I7VoZNCiphI))

This could be a chance to skip JS altogether.

~~~
acjohnson55
That's the great hope. Instead of bringing Javascript to the server side to
have a single-language workflow, you'll be able to bring the non-JS language
of your choice to the client side.

------
vanderZwan
> _" And this is really the biggest contradiction of them all. Tons of people
> have invested countless hours to build these VMs, these new languages, these
> compilers, these optimizations. Yet somehow, they all seem to agree that it
> is impossible for them to sit down and define the most basic glue that binds
> their platforms, and implement a shared baseline for their many innovations.
> We really should aim higher than a language frozen after 10 days, thawing
> slowly over 20 years."_

It's kind of hard to redesign an airplane in flight, and because of the way
the web works, that's a problem that applies to browsers a lot more than some
other pieces of software.

~~~
dgregd
> It's kind of hard to redesign an airplane in flight

It is true that IE6 was 5 years in flight. However that has changed. Google
replaces Chrome plane each 6 weeks.

JavaScript it is new IE6.

I really would like to see Dart in Chrome stable release. Sometime ago I
thought that pure VM, like JVM, would be better. Now I think it is safer to
leave scripts loaded as plain text. Just like HTML, CSS. It is hard to guess
how whole web ecosystem would work with scripts loaded as bytecode.

------
samsquire
Could we combine ASM.js and "native web libraries?" (see
[https://github.com/samsquire/ideas#51-native-web-
libraries](https://github.com/samsquire/ideas#51-native-web-libraries))

Compile some non-Javascript code. Create a package containing the native code.
Serve ASM.js and the native web library.

This package is then installed in the browser and the browser switches to it
when it detects code that is about to be used that matches the installed web
library signature.

If the browser supports native web libraries, it uses that. Otherwise it falls
back to ASM.js.

Either way, we gain performance and we can compile code natively AND to
ASM.js.

------
franole
Windowx XP give me the blue screen of death, with Firefox 25.0.1

~~~
melling
XP is end of life in 5 months so I would expect a lot more problems in the not
so near future.

[http://www.microsoft.com/en-
us/windows/enterprise/endofsuppo...](http://www.microsoft.com/en-
us/windows/enterprise/endofsupport.aspx)

~~~
camus2
like gigantic botnets due to unpatched zero day exploits.

------
theallan
Is it possible to compile Blink and run it using asm.js in Firefox? Then you
could run Firefox inside of the Blink renderer, also in asm.js, and ...

~~~
sanxiyn
One problem is that you can't do runtime code generation with Emscripten. V8
has no interpreter, so you would need a different JavaScript engine.

JavaScript engines can be run using asm.js.
[https://github.com/jterrace/js.js](https://github.com/jterrace/js.js) is a
SpiderMonkey port to Emscripten (with JIT disabled).

~~~
kevingadd
You can absolutely do runtime code generation, you'll just be generating
javascript. If you generate asm.js compatible javascript you'll be effectively
JITting native code on the fly (you're just jumping through some absurd hoops
to do it).

There are some proof-of-concept projects out there that do runtime generation
of JS on the fly for things like recompilation and such in the browser right
now. I believe Shumway [1] does it (recompiling ActionScript VM bytecode to JS
on the fly) and PyPy.js has an experimental JIT too [2]. The runtime library
for my compiler JSIL also does a significant amount of runtime code generation
to improve performance and reduce executable sizes [3].

[1] [https://blog.mozilla.org/research/2012/11/12/introducing-
the...](https://blog.mozilla.org/research/2012/11/12/introducing-the-shumway-
open-swf-runtime-project/)

[2] [http://www.rfk.id.au/blog/entry/pypy-js-poc-
jit/](http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/)

[3] [http://jsil.org/](http://jsil.org/) ;
[https://github.com/sq/JSIL/blob/master/Libraries/JSIL.Unsafe...](https://github.com/sq/JSIL/blob/master/Libraries/JSIL.Unsafe.js#L1254)
and others

------
gotofritz
I don't see the problem with asm. It appears that Chrome and Opera support
them too. It can only be a good thing.
[https://blog.mozilla.org/futurereleases/2013/11/26/chrome-
an...](https://blog.mozilla.org/futurereleases/2013/11/26/chrome-and-opera-
optimize-for-mozilla-pioneered-asm-js/)

It doesn't require requires a plugin install like NaCl

~~~
JetSpiegel
The article links to that article, come on! Don't people read stuff anymore?

~~~
frik
The linked website has an horrible animated background picture. Reading the
text is almost impossible with IE 11. Screenshot:
[http://postimg.org/image/46p2krx95/](http://postimg.org/image/46p2krx95/)

~~~
omeid2
I hate to be that guy, but you're using IE.

On a serious note, you can't really blame people for not supporting a browser
that needs hack for every single version.

Related: [http://www.paulirish.com/2011/browser-market-pollution-
iex-i...](http://www.paulirish.com/2011/browser-market-pollution-iex-is-the-
new-ie6/)

~~~
frik
Ask the JQuery devs, Chrome causes them more troubles than all other modern
browsers combined (IE9+, FF, Safari, etc).

I am well aware of the history and I hate IE < 10 too. I use FF as main
development browser, and beside others of course Chrome and IE 11. The trouble
comes when people only test their website with Chrome. I am using IE 11 as I
have to at my workplace and it has by far the best UX (IMHO). FF still uses
only one process and cannot handle my habit of using dozens or even hundreds
of tabs in an optimal way.

------
snrip
I am surprised that Dart is not mentioned as a comparison in any of the
comments. It is also heralded as a better and more performant Javascript. Is
it because the use-case of ASM more limited? I would imagine that DOM
integration in ASM would be tricky so that would set Dart apart.

~~~
ubernostrum
asm.js is not "a better JavaScript". It's not "JavaScript with better
performance". In most senses that people would use, it's not even JavaScript,
really.

asm.js is not a faster jQuery. It's not for doing yellow-flash alerts, or for
more quickly selecting and manipulating DOM elements.

asm.js is a way to ship traditionally desktop-type software, including
software which was originally written in a language like C or C++ and compiled
into asm.js from that source, to a web browser, to be run in the web browser.

asm.js is (a subset of) JavaScript's syntax, used as a transport/intermediate
representation for that code. It will execute just fine as JavaScript, and
well-optimized JavaScript engines can do quite well with it (hence it is fully
backwards-compatible, if not as fast, in a browser which supports JavaScript
but not asm.js), but the intent is primarily to treat it as an IR, with the
browser performing the final step of compiling that IR to native code before
executing it as native code, rather than executing it as JavaScript.

------
felxh
I definitely recommend poking around the console on this site!

------
ben0x539
UTF-8 is a legacy mechanism now?

------
goggles99
What would it take to get a standards board to approve a common VM for
browsers?

I don't see this ever happening. They would in effect be eliminating
themselves. They would have to find new jobs or even careers.

Once the VM is standardized, what about HTML/JS/CSS. Well who the hell wants
to use those slow moving legacy technologies?

So the standardization now becomes for python, for C#, for scala and lisp
ETC.(and their associated UI frameworks). Not controlled by the W3C at all -
thus their extinction.

It's more than this though. The W3C has an agenda and it is not to advance
technology, it is to slow it down. They want everything moving so slowly that
standards can be followed across the board. They want JS/CSS/HTML to be the
end all not just in the browser, but everywhere. I think that this should be
pretty clear if you follow their trail going back 10-15 years.

It is like a socialist government in a way. The promise is to keep everything
stable and let everyone be on equal footing (equal here because the technology
moves so slowly that nobody can be left behind by it.) They have to kill and
silence many revolutionists who want freedom along the way to do so but
consider themselves justified in doing so. Meanwhile, in a neighboring free
government with limited govt, people flourish. They have more ups and downs
true, and mistakes are made along the way, but after 10 years the free country
is wealthy and flourishing, while the socialist one is stagnant and poor.

Think of the mere opportunity of innovation that would exist if a language
creator could sit down and create a new language and UI framework universally
for browsers in a well established and supported way. This lack of freedom is
stagnating innovation.

Let the people decide. Make a standardized VM and your HTML/JS/CSS stack and
let the people vote with their choice of options that appear.

~~~
siddboots
You are overestimating the power that the standards board has over what
browser vendors choose to include in their software. What you are asking of
them is not really in their power. Besides, if VMs can make the W3C
irrelevant, then they will do so regardless of W3C's approval of any
particular standard.

For what it's worth, we're already very close to the point where "a language
creator can sit down and create a new language and UI framework universally
for browsers".

~~~
goggles99
_You are overestimating the power that the standards board has over what
browser vendors choose to include in their software._

Mozilla and Google already want a VM as evidenced by their work. It would not
take any convincing to get them there.

 _if VMs can make the W3C irrelevant, then they will do so regardless of W3C
's approval of any particular standard._

Now you're underestimating the power of an established standard. For something
to really flourish, enterprise has to adopt it. Without a standard, this will
not happen. This is a bit of chicken and the egg scenario.

