Great seeing the improvements. I was initially a big skeptic of asm.js, but for high performance c-translated code, it seems good enough now. A 1.5x hit is a concern, but we've been paying these hits on the JVM and other languages for years.

I'm still sad there's no SMP/multithreading yet, but SharedArrayBuffer looks promising. The only thing missing is the fact that for GC'ed languages there's no efficient translation yet (e.g. Java/GWT).

You have a very fast GC'd language right there already, if you don't mind writing javascript. I know it has won me over the years, once you know the pitfalls to avoid.

In this way, the browser is the ultimate platform:

* portable low-level, static code (asm.js translation)

* portable high-level, dynamic code (JS translation)

* interoperability between the two

* single set of APIs

* supported virtually everywhere

In short, it's shit, but it's portable shit, polished with billions of dollars of effort. It's useful, but that doesn't mean it doesn't smell.

When people are eating shit for years, they stop noticing the smell and some even start claiming it has "the good parts" in it.

That would imply the whole thing is shit, which it isn't.

If you know of an odour free platform, the world is waiting.

A platform smelling bad is not a boolean flag. Almost every platform smells less than the web as far as actually using it goes; the web is just ubiquitous and frictionless as far as deployment.

_Worse is Better_

you might like this http://harmful.cat-v.org/software/

"You want it (the browser) to be a mini-operating system, and the people who did the browser mistook it as an application. They flunked Operating Systems 101." -- Alan Kay

There are a lot of people who are very angry about this.

Yeah, and it's unreasonable anger. The browser is flawed in many ways, but it's awesome that we have this universal platform and we should cherish it, rather than moaning about how something "better" should have won.

> we should cherish it, rather than moaning about how something "better" should have won.

There are certainly incentives for which that may be true. There is also the impending, monumental investment of effort into what is necessarily only a local maximum.

It's a bit less "awesome" than most people think.

The point is, now that we've taken something that was originally intended for viewing documents over the network and turned it haphazardly into something we realized that we actually wanted (running applications portably and with frictionless installation), we'd better design something from scratch that does what we want without all the unbearable cruft that comes with browsers, HTML and HTTP.

So what we really wanted was Java?

If applets weren't terrible, maybe.

You're forgetting that having everyone use your new thing is the main feature.

Redesigning everything from scratch, you lose the single thing that was special about it: adoption.

Are there alternative proposals at this point anyway?

That lot of people doesn't really matter. They prefer to complain than to embrace what the browsers offer today.

They can even compile their favorite scripting language for asm.js, but there will always be excuses:

  > But I want native GC
  > But I want native Speed
  > But I want native _________

They'd rather die waiting for the perfect conditions than getting things done.

There is absolutely no reason they (I) can't complain about the effort going into browsers that could be going into a better solution, and still take advantage of the browser at the same time.

If nobody complains about the status quo even when it's awesome, we'll never move out of the current local maximum.

I'm not against complaining, but people often forget that the web is incrementally updating, today's web is different than 2014's web, and different than 2013's web, and absolutely different than 2003's web.

The fact that there aren't perfect conditions today doesn't mean that the conditions won't improve tomorrow.

There's tons of effort going into alternatives, but it has largely gone to waste because those alternatives lack adoption, and probably always will.

Focus on what we have, not what we might have had if history had gone differently.

Reinventing the wheel to fix minor issues is rarely worth the effort.

Experiments are rarely a waste of effort just because they don't turn into something bigger; Focus on what we can have, not what we might have had.

Reinventing the wheel for "minor" issues (or just for fun!) is what gave us Linux, LLVM+Clang, Go/Rust/Nim/etc., Newton's laws, Relativity, etc. Incremental changes are not the only way, nor always the best way, to make progress.

>There are a lot of people who are very angry about this.

Could "woah" or someone else explain this to me? (And please don't make a snarky response, this is a sincere question from a someone who is ignorant of the dynamic at work here.)

The browser, JS, etc. have various flaws and forms of cruft accumulated over the years, and weren't originally designed specifically for the purpose of writing applications.

Of course, alternatives all have flaws and cruft, too, just different ones.

Thanks for your response.

So they are angry because it is a "hack" that actually affects them in some way or it one of those religious things?:

1. "I'm angry 'cause you're doing it wrong."

2. "Because open source"

3. Something only dogs can hear.

4. ???

Well, the web has certain limitations (which are slowly being dealt with, but they exist nonetheless).

I had never heard of the term "sea of nodes" architecture before. Here https://news.ycombinator.com/item?id=8118079 is HN discussion about it.

FIRM is a compiler library, like LLVM. Its difference is that it is written in C, and that it uses sea of nodes.

http://pp.ipd.kit.edu/firm/Features

Am I the only one worried about the implications of asm.js and imminent close-sourcing of the web?

I don't want bytecode in my browser. I barely like having some skiddie's javascript in my browser as it is currently. The fact that I'm about to lose the ability to even understand it is scary to me.

(Yes, I know people compile their JS currently... But that's relatively less convoluted. and can be deconstructed to a degree. This is another level.)

I think the next logical step is only allowing running manually-written scripts in a quirks mode with a big warning message to user.

That would be awesome. If I am forced to a use/transpile-to crappy script language by industry then you should suffer too.

The web is already closed-source. You can read gmail's js but you don't have the right to modify or redistribute it.

Freedom implies openness, but openness doesn't imply freedom.

Gmail's JS is open, but it is not free.

Open source means you have the right to modify and redistribute. If you want to express a different idea use a different term.

Bytecode is easier to decompile than assembly code, and you can expect the output of a decompiler to resemble minified code.

>you can expect the output of a decompiler to resemble minified code.

I doubt that. When your C++ is ran through LLVM's optimizer it's structurally changed to a huge degree.

In this title, 'everywhere' means 'across browsers', not 'throughout all JS execution'.

It almost means the same. Node is using V8 (from Chrome). Not sure if Nashorn has any asm.js optimizations but it will probably get it later if it is important to many organizations. Those are probably the most commonly used js engines out there.

Isn't node many, many versions of V8 behind Chrome? As far as I recall, they're on an out-of-date, unsupported version of V8 and sometimes cherry-pick patches from upstream, but that's about it.