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

41–50 of 185 posts

Re: On Asm.js

#41

Post by JoeAltmaier »

ma2rten wrote: post #40

I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm…

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?

Re: On Asm.js

#42

Post by kayoone »

fidotron wrote: post #26

This discussion is missing the simple point that the web is rapidly gaining all the flaws that Flash used to have, without the nice (for some) editing environment. The web really isn't suited for app development at all, as the native mobile markets have demonstrated, while the viability of it as a document delivery platform diminishes every time the content gets hidden behind a massive layer of scripts.

> The web really isn't suited for app development at all, as the native mobile markets have demonstrated

Mobile markets have also demonstrated tightly controlled walled gardens, where fast iteration, platform independence and openness have been replaced with strict rules and controls by the market controlling entities. Is that really a direction you want to move in?

The web as a platform is still lacking in terms of User Experience, but id argue its catching up quickly and already far ahead in most other areas.

Re: On Asm.js

#43

Post by JoeAltmaier »

neave wrote: post #39
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…

> All the user needs is an URL. No "downloading", no installation, no special user permissions, no app shops, no gate keepers, no walled gardens... Exactly. The humble hyperlink is the most amazing thing about the web. It's simple yet devastatingly powerful. I'm not a snob about the programming languages of the web. I don't care what language I need to learn to create content for the web, or what tools I need to use.…

If by 'free and instant' you mean 'just pay for an ISP/phone carrier and wait for a page to load, or a web-app to spin and spin'.

Re: On Asm.js

#44

Post by logn »

gitaarik wrote: post #31

So Asm.js is a strict subset of Javascript, and the author is saying that Asm.js is only useful when you want to compile a C/C++/Whatever library into Javascript, and that it's not interesting for Javascript developers themselves. Then I wonder: why? Can't you write Asm.js code directly (instead of compiling to it)?

Yes, asm.js shouldn't be making JS devs too excited, because you shouldn't write asm.js code directly. It's best to take a strongly typed languages and then run it through an asm.js compiler. JS isn't strongly typed and many of the optimizations are unavailable to JS devs. I am happy that V8 is continuing to focus on optimizations that serve the JS writers and I hope the language survives because I really love writing it.

Re: On Asm.js

#45

Post by ma2rten »

JoeAltmaier wrote: post #41
ma2rten wrote: post #40

I agree, an Unreal Engine compiled to javascript doesn't make sense. It would make much more sense if it were compiled to some kind of bytecode (like NaCl). That will ultimately give you better performance, less loading time, etc. However, maybe there are some libaries which compiled to asm.js are small enough that they can still run in a browser without asm.js support, e.g. an compression or an encryption algorithm…

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.

Re: On Asm.js

#46

Post by acqq »

Ygg2 wrote: post #15
girvo wrote: post #10

Earlier quoted context omitted.

Honestly, I've got no idea what the OP was trying to say... I think they are implying that asm.js is cool , but they're annoyed that it's being built on top of JS rather than from-scratch.

Second this. I get that they are saying - asm.js is cool, but it's on JS, so eugh. Personally I'd love for a really low level language (statically typed, little if any magic, no-GC, multi-threaded) to work across all browsers, but I don't think browser vendors can just sit and say - here is the perfect cross browser language that will make all of net easy. Perhaps the best strategy is to have low level strict languag…

As the writer of the native compilers, I read the article as written from the kind of the developer who always developed in interpretative languages, who sees asm.js as "wrong" because "it's not the JavaScript he would write by hand.

And again. as the writer of the native compilers, I'm absolutely pro asm.js. I believe it's the best direction that JavaScript optimization can take, solving more hard problems elegantly. Including the fact that asm.js is a better representation than most of bytecodes (or even all). Seriously.

Re: On Asm.js

#47

Post by phaker »

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 [1] for most recent example.

I just can't see how PNaCl could be meaningfully reimplemented. Reimplementing it from scratch would require implementing something bug-for-bug compatible with LLVM. That's a gargantuan task. On the other end of the spectrum, why not just use the original implementation? Then it would work very much like any other plugin. I don't think it's a good solution. It seems the only remaining option is implementing it on top of LLVM. But then you still share all potential limitations (e.g. in portability) and all security issues with all other LLVM-based implementations. It could end up being not that bad -- it means more work on LLVM itself, making it better -- but I'm not sure if that would offset the other problems. How many features that appeared first in chrome or webkit were then reimplemented elsewhere in a different, better way? Do we want to end up with only one browser? No, there are lots of things we wouldn't have if Firefox didn't happen, there are lots of things we wouldn't have if Chrome didn't happen. Do we want to end up with only one PNaCl runtime?

[1]: https://code.google.com/p/nativeclient/issues/detail?id=3475

Re: On Asm.js

#48

Post by captainmuon »

leokun wrote: post #28
fidotron wrote: post #26

This discussion is missing the simple point that the web is rapidly gaining all the flaws that Flash used to have, without the nice (for some) editing environment. The web really isn't suited for app development at all, as the native mobile markets have demonstrated, while the viability of it as a document delivery platform diminishes every time the content gets hidden behind a massive layer of scripts.

> the web is rapidly gaining all the flaws that Flash used to have False. 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. 3. It works on mobile devices, flash doesn't. 4. The tools are out there. Check out appcele…

I think there are a couple of misconceptions here:

> 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. Flash was sandboxed (just as Java). You were strongly restricted in what you could access with ActionScript. Of course, the security was poorly executed. I blame it on the fact that it was developed in a different time, without the experience and tools we have today, and that it was closed-source. Still, native plugins don't have to be inherently insecure.

> 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. True, but I'm starting to think "Open Standards" was a huge Trojan horse. - It lead to, or continued, a huge monopolization of platforms. Only a few large companies are able to maintain modern browsers (see the demise of Opera). This is bad, because they can push politically motivated restrictions on their users. (Firefox has a whitelist to only allow certain media codecs to play, although the system would support more. I could modify the source for myself - I did - but it's of no use, as the people visiting my sites won't be able to use it. I don't have the marketing power of Mozilla or Google.) - The "open" "web" platform limits what kinds of apps you can write. You can't really write apps without an (accountable!) central server. Without sockets, you have no Bittorrent, no P2P, no Tor, no Instant Messaging... - I think it also pacifies people who would otherwise be worried about today's locked up platforms. "You can always write a web app if you don't get in the app store."

> 3. It works on mobile devices, flash doesn't. Which was a political decision, not a technical one. There used to be thousands of free Flash games, that would have ran with minimal porting on mobile devices. But Apple couldn't control flash, they wouldn't get their 30% cut from Flash apps, and they couldn't censor apps. So they forbid Flash on iOS, and crippled it on OS X, which was one of the main reasons for its demise.

> 5. Flash never had the native performance or hardware acceleration that modern JavaScript has. Flash had support for native video playback before HTML. It had 2D acceleration for animations before there was canvas, and Shockwave Flash had 3D acceleration years before WebGL.

Re: On Asm.js

#49

Post by endemic »

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's only a matter of time before a tool like Unity includes an asm.js export target.

Re: On Asm.js

#50

Post by NinjaWarrior »

leokun wrote: post #28
fidotron wrote: post #26

This discussion is missing the simple point that the web is rapidly gaining all the flaws that Flash used to have, without the nice (for some) editing environment. The web really isn't suited for app development at all, as the native mobile markets have demonstrated, while the viability of it as a document delivery platform diminishes every time the content gets hidden behind a massive layer of scripts.

> the web is rapidly gaining all the flaws that Flash used to have False. 1. Modern JavaScript vms are sandboxed, not native plugins with unending security holes. 2. It's nearly all open standards and open source, not proprietary closed source controlled by one company. OpenGL, EcmaScript, W3, Mozilla, Chromium, blink, webkit. 3. It works on mobile devices, flash doesn't. 4. The tools are out there. Check out appcele…

I think the above poster is talking about UX...

> 3. It works on mobile devices, flash doesn't.

False. Many (120000+) Flash apps are actively running with Adobe AIR on App Store and Google Play. AIR is a technology to package SWF as a native app.

> 4. The tools are out there. Check out appcelerator or unity's tools.

Unity can not export for HTML5 yet. Apparently they are working on it but I don't think it's that easy (As for the original article, I DO MIND the initial load time. That will be a big problem for Unity as well).

> 5. Flash never had the native performance or hardware acceleration that modern JavaScript has.

False. plain (non asm.js) JavaScript is slow. Don't trust micro benchmarks. And at least ActionScript is faster than plain JavaScript (http://j15r.com/blog/2013/07/05/Box2d_Addendum). And Flash Player 11+ has Stage3D which utilize GPU acceleration as well as WebGL. For instance, please watch this Facebook game (http://www.youtube.com/watch?v=vBIJVt05jwc). Note that this is a commercial product. Not an experiment. Moreover, the same "Epic Citadel" demo was released for Flash on Mar 2012. One year earlier than HTML5 (http://epicgames.com/news/epic-games-releases-epic-citadel-i...).

> Compiled other languages to ActionScript?

Adobe Alchemy...

Please don't denounce Flash without a knowledge of Flash. I'm already not a user of Flash and currently developing with Unity and Cocos2d-x instead, but I feel I need to advocate Adobe guys from unfair bashing.

Post reply on HN