On an unrelated note, I absolutely love that site's header animation (like what you see if you scroll up and/or click "play").
Is that why mobile Firefox kept crashing? Dammit, don't send that stuff to my phone if I didn't ask for it.
On Asm.js
91–100 of 185 posts
Re: On Asm.js
#92Imagine 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.
The issue is not any particular language but the platforms. Asm.js is an assembly language that gives native-code performance to browsers that's theoretically on-par with the JVMs' JITs.
You can think of asm.js as a bytecode (like JVM bytecode) that all browsers can interpret. Some browsers are now getting JITs for this "bytecode".
You don't write asm.js in the same way that you don't write assembly or JVM bytecode by hand. You write Java or Clojure or Scala or C or Haskell. Your compiler then turns that into either JVM bytecodes or asm.js assembly. And your JVM or browser will JIT that bytecode into native code.
The real issue now is that the JVM is currently a more capable platform, but the browser has broader penetration and arguably better security. Raw performance is becoming a non-issue with asm.js.
Re: On Asm.js
#93I 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…
The other big advantage of PNaCl is that you have the option of distributing it as a signed application that the user downloads once. This is critical for doing in-browser encryption or manipulating sensitive data. You need there to be a trusted runtime that makes this possible, but this can't be done in pure Javascript (where it's too easy to insert malicious code that leaks your keys). It's not enough to simply use a crypto API in the browser either---you don't want the Javascript to touch the data at all (otherwise, it could leak the plaintext). Moreover, unlike Java and Flash, PNaCl code is compiled in such a way that the browser can do just-in-time static analysis to verify that the code cannot escape the runtime. These two features---signed code that's trust-on-first-use and JIT static analysis---make PNaCl a much more desirable runtime than asm.js in my opinion.
Re: On Asm.js
#94Earlier quoted context omitted.
> 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?
Just make sure you don't refresh your browser cache after downloading a couple gigs of assets.
Well that has nothing to do with JS or asm.js, only how the game manages its assets. The Citadel demo needs to preload all data before it starts which is very easy to implement but is of course a suboptimal approach to asset loading, a proper game would only load what's really needed to start (4..5 MBytes max?), and from then on stream everything on demand in the background. It's about how much new data can be presented to the player per second, not how big the game data is overall. Asset sharing/reuse, data compression, procedural generation are all important topics for browser games in general, not just games running in asm.js.
Re: On Asm.js
#95Earlier 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?
asm.js code is just numbers and functions, no JS "objects". Passing a C++ object by reference resolves to passing a pointer just like in native code (a pointer in emscripten-generated code is actually an index into the typed-array representing the heap). A nice side-effect of this is that asm.js code doesn't trigger the garbage collector.
Re: On Asm.js
#96Earlier quoted context omitted.
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…
Interesting. Why do you consider that asm.js is a better representation than most bytecodes?
Don't get me wrong JS is awesome (and so is asm.js) but I think stuff like static typing and multi-threadedness are JavaScripts Achilles heel.
Re: On Asm.js
#97Earlier 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…
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 i…
> 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).
Free-slash-open-source programs are like banks in this way. In principle, a bank that fails can always be shut down rather than bailed out, and this is what justifies the existence of private-sector banks. In principle, an open-source program can always be forked if you can't persuade the maintainers to make the changes that you want, and it's always been agreed that this is a central, essential requirement for a program to be considered free-slash-open. But some programs are, in practise, TBTF - Too Big To Fork. A program can be "big" not only by having a large codebase but also through network effects, such as having vast amounts of client software tied to one of its interfaces. The big-boy Web browsers are TBTF in both these ways. So if, for example, you're insulted by Google's decision to knife MathML (as everyone should be), it's relatively easy to roll a Chromium with MathML inside, but you'd still effectively be just maintaining a branch, because you'd have no hope of maintaining "your" browser independently if Google took the whole Chromium codebase in a direction you didn't like - and more importantly, good luck getting users to use your browser or developers to create MathML webpages to support it.
A second example of the phenomenon is the Gnome/KDE mess - part of the reason that the Linux desktop sucks is that, even if you have a clear idea of how it could be better, it's still a whole lot of man-hours to spin up an alternative implementation, get apps customised for it, and so on. In general, an area is the domain of TBTF to the extent that you have to win a political persuasion battle or spend a truckload of your own money before you can produce a viable implementation of your alternative idea.
The solution, to the extent that there is a solution, to these problems is a technical one: find a way to shrink large programs and/or break them up into small, reasonably independent ones. (Of course all social/political problems are technical problems in disguise just as all technical problems are social/political problems in disguise. ;) ) In the case of the web, this is why the vertically-integrated Web browser must go away https://news.ycombinator.com/item?id=6720793 .
Re: On Asm.js
#98Earlier quoted context omitted.
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…
How is PNaCl not Chromium lock-in? Pepper is defined by the Chromium implementation.
Only if you look at the generated binary. But the source code which created this binary can be compiled to a myriad of other platforms with only minimal changes. You can compile the (mostly) same source code to JS+WebGL, iOS, Android, OSX, Linux (SteamOS), even Windows (but not Windows Store apps), ... The differences between these platforms is about 1% or 2% of lines of code in a typical 3D game. Compared to porting a game to, say the Xbox One or WiiU this is "peanuts".
Re: On Asm.js
#99Imagine 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…
Java's greatest sin for the web was not having the JVM have access to the DOM like javascript.
Re: On Asm.js
#100Earlier 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.
The issue is not any particular language but the platforms. Asm.js is an assembly language that gives native-code performance to browsers that's theoretically on-par with the JVMs' JITs. You can think of asm.js as a bytecode (like JVM bytecode) that all browsers can interpret. Some browsers are now getting JITs for this "bytecode". You don't write asm.js in the same way that you don't write assembly or JVM bytecode b…
Actually asm.js is possible to AOT compile, not just JIT.