Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

On Asm.js

acko.net

Post reply on HN
Print view View original

51–60 of 185 posts

Re: On Asm.js

#51

Post by captainmuon »

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java.

Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care that the webkit codebase got, this would no longer be an issue.

Many people remember java to be sloooow. When I first came into contact with it in school, that was certainly the case, but since a couple of years it has had a modern JIT that could easily rival native code.

Java applets are ugly, sure, but that is largely due to the decades old AWT, and the poor font support it used to have. With SWT, you can have native widgets (dunno if they work in Applets, but they are nice on the Desktop), and with antialiased drawing you can get the same results as with HTML5 canvas.

Java applets (and Flash, and Silverlight) died for marketing reasons, and political reasons. There were no unsurmountable technical issues. The outcome is that we are stuck with "worse is better" for the foreseeable future, only max. 50% to 1% of the possible native performance, and a bunch of restrictions we only slowly realize what they mean (no sockets, no signed applications, no anonymous/serverless mashups, less hardware access than we used to have, suboptimal caching, suboptimal tooling like languages, debuggers, content creation tools (I haven't seen anything that can replace Flash for simple vector animations yet) and so on.

Re: On Asm.js

#52

Post by jfbastien »

phaker wrote: post #47
safetydank wrote: post #12

I feel like PNaCl is the technically superior approach - define a stable set of LLVM bytecode and build an interface to run it in the browser. But the uptake is a problem, no other browser maker wants to adopt a big chunk of code controlled by Google, tailored to run optimally in Chrome. So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM o…

> So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM on top of it. A big advantage of asm.js over PNaCl is that it's not LLVM. On the other hand PNaCl is very tightly coupled to LLVM. Any time I find myself checking if a some $feature is available in PNaCl, the discussion revolves around what LLVM can or can't do and how LLVM does it, see…

I think you're conflating frontend and back end. As they currently exist both asm.js and PNaCl frontends are LLVM, if just because it's a good C/C++ solution to parse and optimize. The backend is indeed an LLVM subset as of today for PNaCl and not asm.js, but it's a very restricted subset because the complex bitcode definition LLVM has was pruned a lot for PNaCl, both to distance it from LLVM churn and to make it implementable in another VM.

It is definitely possible to implement a non LLVM back end for PNaCl.

The bug you quote is quite the opposite of what you state: Mark was explaining how complex and potentially often varying LLVM's representation of atomics was. There is a need for atomics to express the full breadth of capabilities C11/C++11 has, but it has to be solved in a way that is close to the standard and no more, non of LLVM's quirks and legacy cruft (LLVM predates these standards, launched PNaCl does not). The primitives also have to be packaged portably so that they can be expressed correctly on any hardware targets (this happens to be tricky to get right, especially since Clang usually makes assumptions about the target). I think PNaCl got this one exactly right, but then again I'm the one who implemented this. :-)

Re: On Asm.js

#53

Post by agentultra »

endemic wrote: post #49

This article neatly sums up my thoughts on asm.js. On the one hand, I really like the fact that Mozilla is doing a lot to promote Javascript (which I usually enjoy programming in). On the other, asm.js basically destroys any reason to write Javascript. For someone interested in web-based gaming, it really discourages me from investing in Javascript-based tools, since the future _won't_ be hand-written Javascript. It'…

That's a good thing.

We spend too much time developing languages instead of environments. Unity is a good environment for developing games. If your goal is to make a game you should use Unity (or whatever... GameMaker has an HTML5 export module; use that). Javascript has nothing to offer you to enhance your productivity and develop your game.

Re: On Asm.js

#54

Post by saosebastiao »

captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

I can fully recognize that Java is a fast and powerful language, but it also makes me want to shove huge wooden slivers up my fingernails. That doesn't change despite the truth of your statements.

Re: On Asm.js

#55

Post by calt »

saosebastiao wrote: post #54
captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

I can fully recognize that Java is a fast and powerful language, but it also makes me want to shove huge wooden slivers up my fingernails. That doesn't change despite the truth of your statements.

But what the poster is really thinking of is the JVM. We now have Scala, Clojure, and others that target the JVM as a platform.

Re: On Asm.js

#56

Post by Touche »

calt wrote: post #55
saosebastiao wrote: post #54

Earlier quoted context omitted.

I can fully recognize that Java is a fast and powerful language, but it also makes me want to shove huge wooden slivers up my fingernails. That doesn't change despite the truth of your statements.

But what the poster is really thinking of is the JVM. We now have Scala, Clojure, and others that target the JVM as a platform.

The JVM doesn't run on Android or iOS, and never will. That's a huge chunk of users they can't touch, but the web can.

Re: On Asm.js

#57

Post by thatthatis »

captainmuon wrote: post #51

Imagine there would be a language that would compile to proper bytecode (not JS), that would run on a standardized platform which is present on almost every computer, that is mature, sandboxed, and actually pretty fast. Oh, wait, that already exists and is called Java. Java has gotten a bad rep lately due to some high-profile drive-by-malware bugs. But if the java codebase would have gotten the same intensive care th…

On the web, when one thing just works, albeit slowly; and another thing requires installation but runs quickly; the thing that just works is likely to win.

Unless java gets upgraded to a first class browser component, JavaScript will tend to win. As a product designer, every step I take my user through loses users. Installing java is a big, scary step that I can almost always avoid.

The insurmountable issue is that it requires users to do installation work.

Re: On Asm.js

#58

Post by sanxiyn »

ma2rten wrote: post #45
JoeAltmaier wrote: post #41

Earlier quoted context omitted.

Original Java bytecode was actually worse than compiling to some real language - all the value lifetime and other optimization information was lost, even conversion to native asm produced unoptimized code. Is NaCl any different? I imagine javascript that is jit-compiled could create a pretty good binary?

NaCl is just native machine code with some additional restrictions, AFAIK. It can make use of existing compilers and optimizers. I agree that the binary is probably relatively efficient, but a) only if your code deals with 32bit floating point numbers, b) the binary (erm js file) is probably going to be bigger (hence increased download times) c) the compilation does not come for free.

For file size, see http://mozakai.blogspot.com/2011/11/code-size-when-compiling... Summary: it's comparable, not bigger.

Re: On Asm.js

#59

Post by thatthatis »

safetydank wrote: post #12

I feel like PNaCl is the technically superior approach - define a stable set of LLVM bytecode and build an interface to run it in the browser. But the uptake is a problem, no other browser maker wants to adopt a big chunk of code controlled by Google, tailored to run optimally in Chrome. So asm.js took a beeline - leveraging existing Javascript machinery for security/JIT and shoehorning a way to run executable LLVM o…

> asm.js's compatibility with existing Javascript engines gives it the best chance of adoption.

This is the key. With asm.js the worst case is slow, not totally broken.

Re: On Asm.js

#60

Post by thatthatis »

flohofwoe wrote: post #17

What I miss in all those discussions regarding JS, asm.js and PNaCl is that the web is the best software distribution platform we have by a huge margin, this is really its overwhelming killer-feature. All the user needs is an URL. No "downloading", no installation, no special user permissions, no app shops, no gate keepers, no walled gardens, and everything is automatically multi-OS and multi-CPU-architecture. The we…

This guy gets it.

The browser, html/css/js, is the most ubiquitous common runtime that has ever existed.

A lot of services have an iPhone app, an android app, and sometimes even a desktop program. But if you have a website, you get all of those platforms at once.

Sure you have to do things differently, usually more slowly, but you can do whatever you do on any device with a browser.

Post reply on HN