Emscripten and asm.js: C++'s role in the modern web
kripken.github.io
kripken.github.io
- asm.js code runs faster then Java code running through the Dalvik VM on Android (https://blog.mozilla.org/javascript/2013/08/01/staring-at-th...)
- porting and cross-compiling code to JS with emscripten is (arguably) easier then setting up and working with the Android NDK
- the new Javascript LLVM backend in iOS8 Safari runs asm.js code very well, and Safari on iOS8 adds WebGL support
- the web is a the only open software distribution platform without gate keepers (seriously, this is starting to get ridiculous: https://developer.apple.com/app-store/review/guidelines/)
- web apps don't need all the code-signing and certification hoopla that native mobile apps need to go through
- app shops are becoming saturated and have the same or worse visibility problems as the web even though they are 'curated'
- you don't pay the 30% platform tax on the web (or rather: you're free to choose your store front-end)
- in the end, most successful mobile games need so little CPU and GPU performance that it really doesn't make a difference whether they run native or in BASIC, WebGL or Metal
I think that the advantages that a single centralized app-shop offered in the past over the web have already or will erode very fast once they have to manage a very high number of apps, basically modern AOLs but with shitty search engines. The open web is the only way out, even if it just means that multiple, decentralized app shops will be built on which compete with each other.
[edit: formatting]
Mobile web usage went from 20% to 14% according to flurry from 2013 to 2014.
That trend could be reversed with a new movement towards the web, but it seems like it would take quite a trend reversal.
We're stuck with apple- and google- based rent seeking platforms.
http://www.flurry.com/bid/109749/Apps-Solidify-Leadership-Si...
They are working on it, but it is late.
https://github.com/w3c/manifest
(I should note that technically, AppCache + bookmarking provides installable web apps, but nobody seems to want to program with AppCache, and bookmarking doesn't really feel like installing an app, which it should.)
CherryMusic - https://github.com/devsnd/cherrymusic SABnzbd - http://sabnzbd.org/
Desktop applications with a Web Based UI I think is the way to go. I love Desktop applications, but being able to just open a browser and use an app from my phone or tablet, regardless of whether they're iOS or Android, or whatever is better than developing a full blown native application that doesn't work "everywhere". There's more applications like that, but I leave that fun to others.
At least we have the Service Workers spec[0] coming soon, though, which should solve the problem.
Also, I think it's been shown that the overhead of encryption isn't that expensive these days.
Heer you can find Comodo PositiveSSL Wildcard at $58.36/Year.
For example, we could package web apps in .apk/.jar package, so they can run like native apps without worrying about missing a resource during offline. JS engine can have more freedom optimizing the code and cache the result.
There is no need to install web app like Chrome Web Store does. All we need is bookmarking and implicit app cache (with smart caching policy). Most people don't use more than 100 apps on regular basis, so 1GB app cache is enough for most people. One major mistake with installable web apps like Chrome Web Store is they often come with security permissions, which defeats major value of web, security and privacy.
Offline can be done with smart API design. For example, browser can let web apps create cache files that sit next to cached .apk and share the same lifespan, then web apps can use sqlite to work with such files for storage. It is essentially the same model as Android/iOS native apps. All these can be done without any app install or security permission. The only risk would be you will lose data if an app is purged during offline, therefore it doesn't have chance to sync the state back to server. If you really about data loss, browser can support pinned apps, so they never get purged by caching policy. That pretty much solves the fundamental problem with web app model.
PS: the usability of JavaScript, web APIs and performance are separate issues. That would also need to solved.
You mean that's a good thing? I'd prefer a clear signing process for software to a web service running its backend on some random server where it's impossible for me to establish trust.
For example, see how Firefox OS handles it: https://developer.mozilla.org/en-US/Marketplace/Options/Pack...
They still have ad networks and other backend services that the apps communicate with.
Those conspire to sell your personal info to the highest bidder (or exploit you in some other creative manner) and have no incentive to do nice by you.
The browser vendors are gate keepers. They decide what your code can and can't do inside the very restrictive javascript sandbox.
1. They are a group of vendors instead of a single vendor that can do whatever it wants, and
2. They don't have arbitrary rules that they apply inconsistently, which we see on app stores sometimes
ASM.js might not be the perfect solution, but it has the huge advantage of being compatible with all major browsers. Practicality beating purity is a common pattern in Web's history.
[1] http://www.chromium.org/nativeclient/pnacl/introduction-to-p...
That way we get maximum performance on the hardware we're targeting (not the "lowest common denominator" of common bytecodes), an ability to run self-modifying code if we want to send a JIT down the wire...
The LLVM phase is really an alternative to the existing DFG JIT, and more precisely to the final phase thereof: the front of the DFG JIT is still used up to CPS optimisations, then it branches right before codegen: DFG generates its code directly while FTL converts DFG to SSA, applies SSA optimisations, converts to LLVM IR and passes the IR to LLVM for codegen.
C++'s role in the modern web is that every relevant browser since 1998 is written in it. It does not need JS wankery to be relevant, thank you very much.
I didn't have a clue about Emscripten; looks really really useful so that I don't have to think too much about writing in other languages and can write EVERYTHING in C++. That'd be great.
Or any good examples of writing the whole webpage with C++ somehow? All the current examples I've seen utilize webgl canvas and handle the interaction there. How about interaction with a regular HTML interface ?
I myself have modified an emulator to run aswell.
"The ffmpeg.js file is around 24.1 MB or so. It ends up being around 6.1 MB gzipped.
The ffmpeg-all-codecs.js file is around 27.5 MB or so. It ends up being around 6.9 MB gzipped."
EDIT: With a fast connection it´s actually not so bad. https://video-funhouse.herokuapp.com/
I imagine it would be possible to generate a smaller version selecting only a subset of features/codecs.
Has someone tried it ?
Wouldn't it make more sense to market it as llvm-ir-to-javascript compiler? That way it would be more attractive to users of any language with a llvm frontend.
I would image that the major target for something like this will be in doing ports of old games to the browser. Anything other than that would seem like a non-starter.
I'm not sure why a developer would take the long road to write a c++ app with the intention of eventually converting it to javascript. Also, If your a company has the expertise you would be basically open-sourcing something that is closed source. So the business logic doesn't make sense unless you don't stand to make money on the code.
Maybe i'm not being imaginative enough.
From my perspective, reading optimized builds is practically the same as reading assembly. In my opinion, it'd be easier to work from an unstripped mac/linux binary (i.e. with function symbols) than from optimized emscripten output.
(1) the web as "just another platform" next to desktop, game consoles and native mobile apps, the advantage here is that you can use the same code base for all platforms and only need a small percentage of platform specific code (about 2% platform specific code from my experience)
(2) cross-compile existing C/C++ middleware libs for use in "traditional" JS web apps, this has been demonstrated for physics engines (bullet), but would also work for pathfinding, AI, and other specialized libs
If you're concerned about opening up your precious source code by cross-compiling to JS, restoring the original code is just as complicated as restoring from a compiled binary, since the JS code has been generated from LLVM bitcode, and is additionally minified. You're basically getting a big, opaque ASCII blob out of an emscripten compile.
The only disadvantage of cross-compiled code is that you get a certain static size overhead for parts of the C/C++ runtime that gets compiled into the generated Javascript file which is somewhere between 100 and 300 kByte. This overhead gets (relatively) smaller the more complex the application is, and emscripten/LLVM is very aggressive about dead code removal.
So, a small web page which just wants to use some WebGL effects doesn't make much sense to write in C++, but once you start to write a real game and use JS libs like three.js (currently at 424kByte minified), the size advantage of manually written JS quickly disappears.
Or is it in the pipeline?
Also, most of the work on it is actually the API and libraries, not the core language, which would have been necessary either way.
It's not open, it's locked to legacy languages.
emscripten is pretty cool technology, the paper presenting the tech (http://davideglintine-new.googlecode.com/hg/docs/paper.pdf) is actually a really easy read. Cool stuff.
I hope it doesn't become a norm to try and write "normal" websites in C++, though things like games do seem to be easier
WTF happened to usability?
Slides are meant to support a talk. Putting everything on the slides, while it does let you just read from them, gives a bad UX for the talk attendees. Posting proper (ie, supporting) slides -- like these appear to be -- online, gives a bad UX for the online readers. Leaving in transitions and progressiveness just makes it that much worse.
So what's up with places line HN posting links to online slide decks? They're a seriously lousy way to communicate. Put some thought into what's appropriate for the audience -- not just who sees it, but also how they get it.
I am really betting on Apps, for setting the web straight for interactive documents.
As for Prezi, I had to search for it. No idea it existed.
No thanks, I rather use Powerpoint as well.
Now you have separate processes for each tab.
Still, considering that the underlying browsers are implemented in C++, I don't think anyone is under the impression that this is some kind of wonderful security feature.
In practice it's similar to the way NACL/pNACL can sandbox code due to the limited instruction set & validation guarantees.
Really? That doesn't match my experience -- the full Firefox test suite is run through ASAN on every check-in. (See the "Linux x64 ASAN" results at https://tbpl.mozilla.org/?tree=Mozilla-Inbound, for example).
So I'd be interested to know what you base this claim on.
I've talked to the person who implemented the LSAN support, and he says that the LSAN leaks being suppressed are not particularly large.
I also know a person who has recently been running the main test suite through Valgrind. (We do smoketests with Valgrind on every checkin, but not the full suite because it's too slow.) He found a few undefined value errors, which ASAN cannot detect, and which are getting fixed, but no UAFs as far as I know.
As an outsider, it sure doesn't seem to be getting as much traction as asm.js or have compelling advantages, though.
I think developers have a tendency to underestimate how important it is to integrate well with your environment, start up quickly, and have a good deployment story. asm.js nails these things.
Compiler -> Bytecode -> Normal JS/ASM.js is the long term strategy for asm support in JSIL, since it will depend on currently-experimental asm features and using asm+polyfills on all browsers would have obscenely bad performance characteristics.
The ultimate goal is to deliver functionality to users. Users don't give a damn what the platform is. They want application functionality which is as easy to access as typing an easy to remember name in an address bar. The means of achieving this goal taken by developers have been convoluted in the extreme. Each step has its own 'reasonable argument' defending the decision made, but it still adds up to madness.
I wouldn't characterize it as such. The reality is, we are pretty effin lucky the Web turned out the way it did. It does it what it does very well. I mean we have an open platform that every major tech company is on-board with, that isn't controlled, wholly, by any single one of them, a platform that works on almost every capable device out there. Those same companies cannot agree on anything else and are openly hostile to each other in every other space, except this one. It could have been worse. And future versions of JavaScript are looking pretty good too!
I'd prefer that HTML/CSS was better designed for building web-applications (right now it's a Frankenstein that doesn't know whether it wants to be a UI toolkit or markup for text). I'd prefer a language like Dart or Python to power web-pages, instead of JavaScript. But oh well.
>The ultimate goal is to deliver functionality to users. Users don't give a damn what the platform is.
And that's part of the reason why JavaScript sticks around. Users don't care, and you can get far with JavaScript.