Comment by jdonaldson | Hacker News Reader

Comment by jdonaldson | Hacker News Reader

I would imagine that people would rarely write asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe).

I admit asm is a bit ugly to look at. But, it's backwards compatible, and provides a way forward for getting some performance out of js in very specific cases. It's not going to be an all purpose code path for general use, and I don't think it's going to take attention away from other general js improvements.

The only thing I'm skeptical about here is whether or not Google chooses to integrate asm with Chrome (Setting aside what Apple or Microsoft ends up doing). It runs counter to the work Google has done with Dart. For that reason alone, I think there's a significant risk it won't gain traction.

I think the creation of "fast" web performance is seen as a huge carrot from the big tech companies (MS, Adobe, Google, Mozilla). Each is trying to offer it in different ways, and at the same time pulling developers into their specific dev tooling ecosystem.

It's a difficult time to pick languages/tooling. I like Haxe because I know it'll support the platform of whomever wins (asm.js, dartvm, es6, etc.)

> I would imagine that people would rarely write asm.js code, but instead they would generate it from statically typed languages (TypeScript, Dart, Haxe).

Current asm.js is just for C/C++. Those altJS languages can't make use of asm.js (Haxe->C++->LLVM->Emscripten->asm.js might be possible but I think it's meaningless).

asm.js is the answer of Mozilla for "the web standards can't handle AAA games" but I believe this is far from an ideal solution. And I agree with the worry of the poster that this ugly hack makes JavaScript more ugly, both on the specs and VMs.

To be honest, I trembled when I saw the Math.imul proposion to see how some people are so obsessed with JavaScript...

Current asm.js is just for C/C++.

I think that's a dangerous way of putting it. Asm.js is just a spec and can (and ought to) be emitted by things other than Emscripten.

> Current asm.js is just for C/C++

There is already asm.js support for lljs, some thoughts on support in things like JSIL (C#) and Haxe (as you mentioned).

And in principle anything that compiles to LLVM IR or C/C++ would work through emscripten.

As others have mentioned, I don't see asm.js as being fundamentally tied to C/C++. Please correct me if I'm wrong. Memory management could be addressed in future versions, but even if it is not, there are still ways of getting the performance benefit of asm.js using altjs.

I'd love to be on asm.js with Java. Does Dart really represent all of Google? From what I understand of Google, a project really is only as big as the team that works on it - unless its a CEO mandate, like social features. From that angle, Chrome > Dart by far and its in their best interest to accept relatively simple technological innovations that o

If I have to stay in JS, it's CoffeeScript or Javascript, there's a lot of productivity tools around them already. Having coded years of js, I'm definitely reaching my limit by how often I have to find the damn missing syntactical issue, or deal with custom class systems or not having refactoring support or or or, the list goes on.

> instead they would generate it from statically typed languages (TypeScript, Dart, Haxe)

All of those languages would be terrible for targeting asm.js. asm.js doesn't support GC. Java, C#, Haskell, Smalltalk, all sorts of languages you could imagine wanting to compile to run in a browser would actually be a terrible fit for asm.js.

You'd be much better off compiling to vanilla JS so you can take advantage of the underlying VM's support for GC, dynamic dispatch, strings, etc.

asm.js doesn't support GC... for now. Read the FAQ for more details: http://asmjs.org/faq.html

Even if it never supports GC, it's not out of the question to use historically GC languages like Java. It's just a matter of manually releasing memory through the API. It's a pain, but it's one i would gladly bear for better performance on some specific methods.

What's the point of writing something in Java if you have to do manual memory management and can't use any of the platform library? asm.js makes sense for performance critical code that you would in other languages write in C. So, in a game you could write your game engine or at least your graphics engine in C/C++ and then add a scripting language for logic (JavaScript/Java/Python/Lua/...). You could compile the engine from C/C++ to asm.js and the game logic to JavaScript. But compiling a classical high(est) level, GC collected language that is mostly defined by its standard lib (read: Java) to asm.js seems weird.

Managing memory in Java is not common, but it's not exactly weird either. Off the top of my head, you need to make memory related API calls for dealing with ORMs, object pools, and native externs.

Reply on news.ycombinator.com