5 ms·

Great read. One thing worries me: if we standardize a subset of JavaScript that browsers can execute quicker, won't it cause a decline in the use of fully-featu

Great read. One thing worries me: if we standardize a subset of JavaScript that browsers can execute quicker, won't it cause a decline in the use of fully-featured, human-written JavaScript? Developers may reasonably choose to write all their web code in languages that are compiled to asm.js subset. As a result, we will lose benefits that a scripting language that is human edited and readable gives.

octo_t 13y ago
Surely this could have been a criticism of C? Won't we lose the benefits of an assembly language that is human edited and readable?
- mixedbit 13y ago
  No, because assembler was not shipped to clients, it was compiled anyway to unreadable binary. JavaScript is shipped to clients, you can open and examine it (if it is not obfuscated).
  - ndesaulniers 13y ago
    `ndisasm your_binary | less` done!
MatthewPhillips 13y ago
People still choose to write desktop apps in Java, Python, C# and others despite the existence of C++. Most types of apps do not need the optimizations asm.js allows. Hand-written JavaScript will continue to get faster.
_progger_ 13y ago
How do you expect DOM to be accessed from C++? Do you think it is possible to make an asm.js -> C++ code map for debugging? Or in worse case asm.js -> C++ (somehow) -> Scala debugging?
ndesaulniers 13y ago
Won't C/C++ developers choose to just write inline assembly since it can be faster? Sure, but that's doing things the hard way.
- sampk 13y ago
  You do realize that you're agreeing with his point, right?
JoshTriplett 13y ago
> if we standardize a subset of JavaScript that browsers can execute quicker, won't it cause a decline in the use of fully-featured, human-written JavaScript? Sadly, no. Browsers have an eternal backward compatibility requirement with existing sites, so JavaScript as a directly written language seems unlikely to ever die. On the bright side, efforts like this make it increasingly feasible to write code in languages that don't have to deal with a dozen quirky runtime implementations. Even if you prefer JavaScript, you might soon be able to use a translator that emulates a single consistent fully-featured implementation of the latest ECMA spec on top of whatever crazy substrate the browser provides.
kevingadd 13y ago
This has already happened years ago. Getting optimal performance in V8, SpiderMonkey and other runtimes is only possible if you hit the sweet spot for the engine's various heuristics. There are literally thousands of different ways to hit 'optimization bailouts' in a modern JS runtime and end up dropped into an interpreter or incredibly slow 'safe mode' JIT, where you will see performance penalties of 10-200x (yes, really). Plus these heuristics aren't documented, change frequently, and sometimes have bugs. It's awesome. In this regard, asm.js is an improvement because at least it makes it clear how you end up in the 'fast zone' and it has an offline validator you can use to check your code.
modeless 13y ago
If we don't standardize a subset of JavaScript that browsers can execute quicker, it will cause a decline in the use of websites as developers choose to write native apps instead. Then we will lose all the benefits that the Web provides.
bradleyjg 13y ago
I think you'll see even more use of js to optimized js transformers like closure.
flyinRyan 13y ago
Good, this is exactly what I hope happens. Javascript is a ridiculous language to be the only choice for web programming. Also, as more and more code has to be ran client side, how can I protect my investment for the code I need to not be so easily copy-able?

octo_t 13y ago

Surely this could have been a criticism of C? Won't we lose the benefits of an assembly language that is human edited and readable?

mixedbit 13y ago
No, because assembler was not shipped to clients, it was compiled anyway to unreadable binary. JavaScript is shipped to clients, you can open and examine it (if it is not obfuscated).
- ndesaulniers 13y ago
  `ndisasm your_binary | less` done!

MatthewPhillips 13y ago

People still choose to write desktop apps in Java, Python, C# and others despite the existence of C++. Most types of apps do not need the optimizations asm.js allows. Hand-written JavaScript will continue to get faster.

_progger_ 13y ago

How do you expect DOM to be accessed from C++? Do you think it is possible to make an asm.js -> C++ code map for debugging? Or in worse case asm.js -> C++ (somehow) -> Scala debugging?

ndesaulniers 13y ago

Won't C/C++ developers choose to just write inline assembly since it can be faster? Sure, but that's doing things the hard way.

sampk 13y ago
You do realize that you're agreeing with his point, right?

JoshTriplett 13y ago

> if we standardize a subset of JavaScript that browsers can execute quicker, won't it cause a decline in the use of fully-featured, human-written JavaScript? Sadly, no. Browsers have an eternal backward compatibility requirement with existing sites, so JavaScript as a directly written language seems unlikely to ever die. On the bright side, efforts like this make it increasingly feasible to write code in languages that don't have to deal with a dozen quirky runtime implementations. Even if you prefer JavaScript, you might soon be able to use a translator that emulates a single consistent fully-featured implementation of the latest ECMA spec on top of whatever crazy substrate the browser provides.

kevingadd 13y ago

This has already happened years ago. Getting optimal performance in V8, SpiderMonkey and other runtimes is only possible if you hit the sweet spot for the engine's various heuristics. There are literally thousands of different ways to hit 'optimization bailouts' in a modern JS runtime and end up dropped into an interpreter or incredibly slow 'safe mode' JIT, where you will see performance penalties of 10-200x (yes, really). Plus these heuristics aren't documented, change frequently, and sometimes have bugs. It's awesome. In this regard, asm.js is an improvement because at least it makes it clear how you end up in the 'fast zone' and it has an offline validator you can use to check your code.

modeless 13y ago

If we don't standardize a subset of JavaScript that browsers can execute quicker, it will cause a decline in the use of websites as developers choose to write native apps instead. Then we will lose all the benefits that the Web provides.

bradleyjg 13y ago

I think you'll see even more use of js to optimized js transformers like closure.

flyinRyan 13y ago

Good, this is exactly what I hope happens. Javascript is a ridiculous language to be the only choice for web programming. Also, as more and more code has to be ran client side, how can I protect my investment for the code I need to not be so easily copy-able?