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…
> I agree, an Unreal Engine compiled to javascript doesn't make sense. That demo runs at 60 FPS in my browser, allowing me to casually spend more money on more video games. Your objections seem ideological, as opposed to perf benchmarks, distribution improvements or other quantifiable terms. Can you expand on why it doesn't make sense?
On Asm.js
81–90 of 185 posts
Re: On Asm.js
#82Earlier quoted context omitted.
The linked website has an horrible animated background picture. Reading the text is almost impossible with IE 11. Screenshot: http://postimg.org/image/46p2krx95/
I hate to be that guy, but you're using IE. On a serious note, you can't really blame people for not supporting a browser that needs hack for every single version. Related: http://www.paulirish.com/2011/browser-market-pollution-iex-i...
I am well aware of the history and I hate IE < 10 too. I use FF as main development browser, and beside others of course Chrome and IE 11. The trouble comes when people only test their website with Chrome. I am using IE 11 as I have to at my workplace and it has by far the best UX (IMHO). FF still uses only one process and cannot handle my habit of using dozens or even hundreds of tabs in an optimal way.
Re: On Asm.js
#83Imagine 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…
It's not a VM bytecode. It's assembly language, and the target machine is your native CPU. It is sandboxed by the browser. It is present on any computer with a browser and Javascript, which is more computers than have a browser and Java plugin, or any other plugin for that matter. Asm.js is less mature that Java, but it will grow up. It is currently supported by more browsers than Java, so even if it's crappier right now, it will eventually surpass and replace Java in the browser.
If you are thinking that asm.js is Javascript or is interpreted, you're thinking about it wrong. Think about it this way: Take an arbitrary executable. If you dissassemble it, you have some sort of assembly code. There are several different assembly language syntaxes, but they're all basically the same. Asm.js is basically just another assembly language, with two key differences.
The first difference between asm.js and any other assembly languages is that the only existing asm.js assemblers happen to assemble executables that are sandboxed by your browser. You can't do syscalls to use sockets or files or the Windows registry. You can't fork() or run non-asm.js executables. Still, if you can live with the "syscalls" that the browser gives you, you can run native code in any browser. The browser is your operating system.
The second difference between asm.js and other assembly languages is the really clever part! It is not just assembly. It is both valid assembly language that can be assembled to native machine code and also valid Javascript that can be executed by a Javascript VM -- and both ways of looking at it are semantically equivalent!
It's like being able to write a novel where the text is both valid English and valid Spanish at the same time, and the plot is the same no matter which language you speak.
So I lied. It is Javascript. But you shouldn't think of it that way. You write Javascript. Your compiler writes assembly language. Asm.js is assembly. The Javascript aspect is just a clever backwards compatibility hack. It could have been specified to have a more traditional and readable assembly language syntax, but then you'd need plugins and nobody reads assembly anyway. As is, it's machine code that happens to be able to run on any Javascript VM. This means you can deploy native machine code to any browser without a plugin. In the event that your browser is old and doesn't contain an asm.js assembler, that's ok! Your unmodified native code will still run, albeit more slowly, in a plain old Javascript VM such as everybody has had for years. Except lynx users.
The browser as an operating system is currently worse than a Java runtime plugin in that the browser has less functionality. However, browsers are currently better in that they have more penetration and a higher velocity of improvement. Long term, the browser as a full-featured operating system makes more sense than as a mere scriptable document viewer slash plugin container.
Re: On Asm.js
#84Imagine 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…
However Snap.svg (snapsvg.io) made by the Raphael creator and backed by Adobe seems to be the best vector animation replacement yet. It is really a mashup of Flash vector and Silverlight declarative style, almost an iteration (you still lose the compiled nature of it and very good compression by default though as it isn't swf -- just like Silverlight). Still nothing has all the features of flash except maybe Unity, minus the vector part, but plugins are looked at in a worse light now.
So we are in this transitionary stage where the new stuff is better but it takes much more work to get it to do the same across all platforms. WebGL, hardware accelerated and and libs that glue those nicely like Three.js or 2D EaselJS and vector libs like Snapsvg will see it through, or further iterations of those. Once WebGL takes hold across all browsers and a couple years we will be in new, more capable hardware accelerated lands. Flash was a big software rendering, CPU hogging bummer at the end.
Re: On Asm.js
#85Earlier quoted context omitted.
> 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…
> Compiled other languages to ActionScript? For the interest of historical accuracy, I must point out that Adobe Alchemy predates Emscripten by years.
A more direct comparison in this case is NaCL - Alchemy-compiled outputs would not work on an old ActionScript VM, while one of asm.js's benefits is that the generated code will work on any javascript runtime, because it's just JS.
Re: On Asm.js
#86Earlier quoted context omitted.
"It would make much more sense if it were compiled to some kind of bytecode (like NaCl)." asm.js is a bytecode. The ".js" is misleading; it's not wrong, but it's misleading. asm.js is actually a bytecode specification that has a syntax that overlaps (but is not a superset of) Javascript, and the semantics of the bytecode overlaps (but is not a superset of) Javascript, but it is not Javascript. It's a bytecode that ha…
How many CPU cores can said "bytecode" utilize at a time? Does it make a difference between value and reference types for optimal performance?
Re: On Asm.js
#87Is it possible to compile Blink and run it using asm.js in Firefox? Then you could run Firefox inside of the Blink renderer, also in asm.js, and ...
One problem is that you can't do runtime code generation with Emscripten. V8 has no interpreter, so you would need a different JavaScript engine. JavaScript engines can be run using asm.js. https://github.com/jterrace/js.js is a SpiderMonkey port to Emscripten (with JIT disabled).
There are some proof-of-concept projects out there that do runtime generation of JS on the fly for things like recompilation and such in the browser right now. I believe Shumway [1] does it (recompiling ActionScript VM bytecode to JS on the fly) and PyPy.js has an experimental JIT too [2]. The runtime library for my compiler JSIL also does a significant amount of runtime code generation to improve performance and reduce executable sizes [3].
[1] https://blog.mozilla.org/research/2012/11/12/introducing-the...
[2] http://www.rfk.id.au/blog/entry/pypy-js-poc-jit/
[3] http://jsil.org/ ; https://github.com/sq/JSIL/blob/master/Libraries/JSIL.Unsafe... and others
Re: On Asm.js
#88What 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…
Have you actually shipped a complex codebase to the web? There are a TON of major issues which are just as bad: Old problem: Downloading New problem: Downloading. Large JS apps have to asynchronously load potentially very large codebases, every time the app is loaded Old problem: Installation New problem: Installation. What if the user has NoScript? AdBlock? Mobile Opera vs. Mobile Safari vs. Chromium vs. IE. Old pro…
Unless you use an old browser, this is not a problem anymore. http://www.w3.org/TR/html5/browsers.html#offline
Re: On Asm.js
#89Re: On Asm.js
#90I 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…
From a developer's perspective PNaCl and emscripten is almost the same to work with, the difference is just a couple of hundred lines of wrapper code (less then the differences betwenn iOS and Android wrapper code) and you need to find a higher abstraction layer for threaded code. And if the differences on the surface are so small, and the performance difference is acceptable as well (it is IMHO), I don't really care…