Is 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 ...
On Asm.js
21–30 of 185 posts
Re: On Asm.js
#22I 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 how the goal is achieved under the hood. Asm.js or PNaCl are not platform-lock-ins like DirectX or Flash. It's just POSIX + OpenGL with a handful of platform-specific functions, and practically the same code compiles on any other POSIXish + OpenGLish platform.
Re: On Asm.js
#23What 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 problem: Special User Permissions; gate keepers
New problem: Proxies. Websockets. Anti-virus software. On-machine firewalls. Corporate firewalls. "Special" toolbars and plugins that redirect the browser.
The web is not a "software distribution platform". It is not a "distribution platform", because code is retrieved on-demand and run, and there is no simple way to "cache" that locally and re-run it. (Chrome App Store does not count, because it is antithetical to the model you've described). It is not even software in the traditional sense that you mean, because everything is inherently client-server, so most of the app lives on the server or in the cloud.
Re: On Asm.js
#24What 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…
http://www.flohofwoe.net/demos.html, these demos are about 150k to 250k lines of C++ code, and are about 700k to 1.5MB downloads, the same as zipped native executables. I'm also on the team which does a web-based MMO which is running for 3 years now (not done with emscripten though), so I'm aware of the problems :) It's still miles better then closed platforms.
Re: On Asm.js
#25It's very simple - there is no magic here. asm.js is just a "pidgin instruction set architecture", to allow communication between an emerging set of VMs - the browser runtimes - and a compiler backend. (The front-ends are the LLVM front-ends.)
The article is exactly right in saying that it's a way to route around JS. Javascript fanboys should not be praising asm.js, because it's a way to route around them. (Which is fine by me; JS is an abortion of a language that cannot die fast enough.)
I see asm.js as the Revenge of Compiled Languages. Coupled with generic interfaces for accessing underlying graphics and audio hardware, we're just right back where we started with Java applets. Write your apps in whatever language; run in the browser.
Re: On Asm.js
#26This 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.
Re: On Asm.js
#27I'm very impressed by the Epic Citadel demo. But how do you debug a C/C++ program that has been converted to asm.js? Whats the current tooling like?
Usually I'm debugging a native "desktop build" of the code in VStudio or XCode since 99% of the bugs are not emscripten specific. But having said that: browsers are becoming a really good debugging platform as well. emscripten can emit source maps, which kinda lets you directly debug the C++ code in the browser (not as fluent as in a native debugger yet, since only code lines are mapped, not variables, but the potent…
Thanks! I was thinking specifically of bugs that occur in the browser target but not the native build.
Given your experience that "99% of the bugs are not emscripten specific", I'm very impressed with how emscripten can retain the semantics of the native code across the conversion and optimisation process. Obviously thats what any compiler does, but in this case the target environment seems to me to be much more complex than a physical cpu: threads, memory management, etc.
Re: On Asm.js
#28This 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 appcelerator or unity's tools.
5. Flash never had the native performance or hardware acceleration that modern JavaScript has.
6. Don't think Flash ever had the kind of momentum JavaScript has. Like has anyone ever made a derby.js for Flash? A sharejs? Compiled other languages to ActionScript? With source maps to help?
7. Flash avoids all kinds of privacy settings and plugins in your browser. Flash gives you less control.
8. Even Adobe has moved past Flash, these arguments are all done, why haven't you moved on?
Re: On Asm.js
#29What 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…
None of the things you've listed are actually really problems, or have well-known solutions. HTTP caching solves the downloading problem for most classes of application. You can also run apps locally with app-cache and local storage (and in the future IndexedDB), though I'll grant that this isn't absolutely perfect today.
I don't understand your "installation" issue. A user with NoScript knows how to turn it off for a web application they want to use, and generally do so. They just want to retain control over JS execution. AdBlock is not related to actual application delivery, but revenue generation, somewhat orthogonal.
Having to support cross-platform quirks is also something that isn't unique to the web. If you support multiple versions of iOS for your app, you will hit similar issues. Not to mention if you wanted to actually be cross-platform and work anywhere other than iOS with the same app.
Re: On Asm.js
#30Earlier quoted context omitted.
The article links to that article, come on! Don't people read stuff anymore?
The linked website has an horrible animated background picture. Reading the text is almost impossible with IE 11. Screenshot: http://postimg.org/image/46p2krx95/
IE11 is a very promising alpha release of the next "good" IE.