Hacker News Reader

Comment by mixedbit | Hacker News Reader

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.

View on HN

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.

> 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.

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.

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?

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).

`ndisasm your_binary | less` done!

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.

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.

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?

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?

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

Reply on news.ycombinator.com