WebAssembly fandom kills Google's Portable Native Client Google says it will stop supporting Portable Native Client in the first quarter of 2018, with some exceptions, because WebAssembly has become more popular. Portable Native Client, which according to Google is abbreviated PNaCL and pronounced "pinnacle," was introduced in November, 2013. It was intended to be an improvement …
...implemented a Web browser inside a WebAssembly yet? I'm sure that would create a black hole somehow...
Whilst part of me quite likes the look of Web Assembly, another part of me is saying, "Oh no, not another client side arbitrary code execution environment". The recent unwinding of operating system ASLR in Javascript is surely a trick that can also be pulled off in Web Assembly, but probably faster. For both JS and WA this is certainly something to be thought about quite carefully...
Nonetheless it seems like a sensible way to allow sane languages to be used as part of Web apps, and is very welcome. Are we going to see the return of the Java applet, done properly?!
It strikes me that there's a whole class of process missing from operating systems. All that these sand boxing technologies are trying to do is stand up a process that cannot do various things (access storage, etc). Surely in this day and age we'd be better off having a sandbox process as an operating system object, not something that a browser has implemented for itself? That would be useful for a whole variety of things, not just Web browsers.
It's not arbitrary code, though.
If you've played about with things like Emscripten, which will soon compile to WebAssembly too, you'll realise that all the usual web-page restrictions apply.
You can't just open random files (you have to virtualise a filesystem), you can't just talk on the open network (you have to be in a trusted zone, or go via WebSockets which greatly limits what you can interact with to - basically - websites which act as intermediaries to pass anything more complicated), you can do sound but it's under the control of the browser tab, you can request webcam and mic access but it can be denied, you can do 3D but it's WebGL subsets, and so on.
Java's problem was that it claimed to be a self-contained and isolated system but from day one you could browse the user's filesystem and select files and it had to replicate the zoning/permissions in it's own plugin rather than let the browsers etc. apply theirs.
The language is still interpreted, permissioned, controlled and even CPU-restricted (so you can't just bring a computer to a halt with a webpage that loops forever, etc.).
With Emscripten (which I'm familiar with, so I'll use as the example here), I can throw a C99 SDL program at it and get something out the other end that'll run in an modern browser. There's very little to change to make it run. But to make it *work* for some actions takes a lot more (intermediate servers to translate WebSocket actions, culling of OpenGL operations back to a subset, specifying a "fake" root filesystem that is populated only in memory from the contents of a web-based seed file and allows no access to the client computer filesystem even so, etc.).
It lets you do some amazing things, and all the compilers are now starting to support WebAssembly as a target architecture, and some wonderful complex actions (e.g. take an SDL OpenGL game and compile it almost directly to a file you can put on a webserver and load in a normal browser) are now quite easy to do. But you're still restricted to the same as any other webpage.
So long as we keep that model and don't make WebAssembly a special-case (like we did Flash, Java, etc.), so long as it's just an interpretable HTML/JS page in a slightly different format, so long as it's treated the same whether Google decide to use it on their front page or you load it up from an email attachment, there shouldn't be a problem.
Meanwhile, I'm actually playing about with getting things to work - because I hate web languages but still love tinkering in C - and enjoying a lot of success. To be honest, to me, the biggest block in using such things is still the restrictions imposed by the browser, which is how it should be. Running 100,000 lines of C99 through a gcc/llvm-based compiler targetting WebAssembly is actually the easy bit.
Program in established and platform-independent languages.
If I can still compile C99 to Win32, Win64, Linux, ARM EABI, LLVM intermediate code, HTML5/Webassembly, etc. then it doesn't matter that the end product might change. That's 18 years - or more - of portability.
If, however, you're required to program in "the latest fad that everyone is using", then it's a no-win game.
The problem comes from people who re-architect everything to take account of, say, HTML5 before the generic portable stuff is brought over, because they "must have" it. Any platform not old enough to have a compiler to it from just about any language isn't one you want to code on. You might HAVE to code on it, but you'll always have the problem of constantly being required to learn things that quickly turn obsolete.
Perl or PHP. Java or C. GDI or Metro. Mac or Windows. Whatever you use, abstract it out and make it portable so that it doesn't matter if someone completely changes the target device. The languages to do that are quite obvious. Basically anything not written last year, and not appearing as a buzzword on social-media-backend-developer job ads for startups.
Is this really about generic web or is it about heavy-weight application distribution?
Should we actually be working on web distribution of "portable-apps" rather than trying to shoe-horn applications into JS?
If JS isn't fast enough on a PC, it certainly won't be fast enough for a tablet, so you've lost your cross-platform-ness.
WebAssembly is a byte code. It's executed via JavaScript only if your browser doesn't support WebAssembly natively, in which case a reference implementation of the WebAssembly machine in JavaScript is available.
So it's different from asm.js as that was just a JavaScript subset. A hypothetical browser could run WebAssembly without a JavaScript implementation.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
