Hacker News Reader

Comment by voidlogic | Hacker News Reader

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

View on HN

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.

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.

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.

In that sense, like a lot of the 'let's run absolutely everything in a browser', it seems like a waste of energy.

I'd much rather that time and effort were spent on optimizing the web infrastructure for the kind of heavy weight LOB applications that are a) currently being put on the web in a serious way and b) have performance issues than on hypothetically enabling web based CAD programs or AAA video games.

Things like figuring out a solution to the circular reference problem caused by having separate DOM and js garbage collectors. An agreement on a perfomant client side storage scheme. XSS protection for mere mortals. And so on.

"never have to write another line of yucky Javascript again."

GWT existed since 2006: https://developers.google.com/web-toolkit/

And developers have been fretting about serializing stuff you wouldn't think would ever need serializing, ever since.

and now you have two problems.

writing yucky Java and still dealing with yucky JavaScript? :P

I've used it and like it well enough (except for the horrible compile times- which perhaps asm.js can help by simplifying code generation). I'd really like a Go version of GWT.

Have you looked at Dart? It's not that far from Java.

Not really. It's a dynamically typed language that tries to fool the casual user into thinking it's statically typed.

But it has more normal types. I'm betting if asm.js takes off, dart2js could easily output code that uses it. Sure you can write fully untyped Dart code, but their js compiler already does a lot of type inference.

Reply on news.ycombinator.com