5 ms·

And the Web SQL initiative failed, for just this reason; SQL itself does not define enough to write portable SQL, so they just had to say "well, SQL as implemen

by lambda 13y ago

And the Web SQL initiative failed, for just this reason; SQL itself does not define enough to write portable SQL, so they just had to say "well, SQL as implemented by SQLite as of this particular version", and that was pretty much a non-starter. Web SQL had even got a little more buy in from multiple vendors (Safari, Chrome, and Opera), but due to the problems with it Mozilla and Microsoft refused to implement it. The same is likely to happen to PNaCL. It will probably survive for a while in Chrome, as it may be useful for writing ChomeOS specific apps, but it will never be adopted by any of the other browser vendors. ASM.js runs just fine in other browsers, the only difference is that they don't implement the stricter subset and same optimizations as Firefox does, so it's a lot more likely to catch on, as people can write cross-platform ASM.js right now.

rybosome 13y ago
Correction: you can write cross-platform PNaCl code; there's a project called pepper.js that compiles the PNaCl application using emscripten. To quote the GitHub README: "Native Pepper applications can now be run in Chrome, Firefox, Internet Explorer, Safari, and more." This leaves them in roughly the same place; write code that will be heavily optimized for one of the browsers, then include a compatibility layer that will make it runnable in all of the others. Without making an argument as to which underlying approach is better, I see no clear upper-hand from the perspective of compatibility. What somebody needs to do now is define another language that compiles to both PNaCl and asm.js-suitable languages, and offer a deployment mechanism that correctly uses one or the other when in a browser-optimizable situation. Nothing beats too many standards like adding another standard to unify them. ;)
- kevingadd 13y ago
  Is it really cross-platform PNaCl code if making it cross-platform requires converting the PNaCl LLVM IR into an actually-portable language (Javascript) using asm.js technology and a reimplementation of Pepper? That sounds more like someone went to the trouble of writing an emulator/translator for a foreign platform, treating PNaCl the same way they'd treat old game consoles or ARM for android simulators.
- lambda 13y ago
  Yeah, and you can also run Linux in a browser and run Chrome within that and then everything will be portable everywhere. Except, well, for performance. One of the big differences between ASM.js an PNaCl is that ASM.js just exposes ordinary standardized Web APIs, while PNaCl gives you the Pepper API, which is basically an entirely Chrome specific API. That means that rather than just using Emscripten and compiling with two output targets (PNaCl and ASM.js) which call the same APIs, you need to do a wrapper layer on one or the other (emulating PNaCl with standard Web APIs, or vice versa, or having some other intermediate layer that abstracts over both). The whole point of ASM.js is to leverage existing standardized infrastructure, while PNaCl just exposes what's convenient to expose in Chrome, while likely being considerably more expensive for other browser vendors to implement. This is a lot like Filter Effects in IE. Rather than specifying a reasonably portable syntax, they defined something that was build specifically on some random subset of DirectX filters, and pretty much impossible to implement anywhere else without implementing a large amount of DirectX. While other browsers eventually released most of the same things in a portable manner, there was a while where you had to either implement both or use some kind of wrapper of one over the other. While I think that it's a good thing that Google has spent time experimenting with and building NaCl and PNaCl (in general, you need ad-hoc single engine experimental implementations that people can play around with in part to figure out what will actually work for authors and is actually implementable, like canvas was, or various CSS3 effects over the years), it's a standardization dead end, and it would be nice if they would spend their effort on trying to extract something that could be standardized from it and ASM.js, rather than enabling it for web pages so it'll become another single-vendor technology that leaves others as second-class citizens. This kind of vendor lock in is out of line with promises of openness and supporting standards that Google has made in the past, and especially concerning since they're selling hardware that only runs Chrome. Between locking people in to a single browser on that platform, and a single browser if they target PNaCl (with maybe second-class support for other browsers via Emscripten and pepper.js), this is starting to remind me of what a certain other company did when they had the sleek, fast new browser that was trouncing the big buggy slow incumbent.
- yetanotherphd 13y ago
  >there's a project called pepper.js that compiles the PNaCl application using emscripten. That made me laugh. You write code that is supposed to compile to native code, only to have it compiled to javascript instead. It's a crazy world we live in.
  - pjmlp 13y ago
    It is the hipster world, where an application created to show documents has been subverted into a virtual machine.

by lambda 13y ago

rybosome 13y ago

Correction: you can write cross-platform PNaCl code; there's a project called pepper.js that compiles the PNaCl application using emscripten. To quote the GitHub README: "Native Pepper applications can now be run in Chrome, Firefox, Internet Explorer, Safari, and more." This leaves them in roughly the same place; write code that will be heavily optimized for one of the browsers, then include a compatibility layer that will make it runnable in all of the others. Without making an argument as to which underlying approach is better, I see no clear upper-hand from the perspective of compatibility. What somebody needs to do now is define another language that compiles to both PNaCl and asm.js-suitable languages, and offer a deployment mechanism that correctly uses one or the other when in a browser-optimizable situation. Nothing beats too many standards like adding another standard to unify them. ;)

kevingadd 13y ago
Is it really cross-platform PNaCl code if making it cross-platform requires converting the PNaCl LLVM IR into an actually-portable language (Javascript) using asm.js technology and a reimplementation of Pepper? That sounds more like someone went to the trouble of writing an emulator/translator for a foreign platform, treating PNaCl the same way they'd treat old game consoles or ARM for android simulators.
lambda 13y ago
Yeah, and you can also run Linux in a browser and run Chrome within that and then everything will be portable everywhere. Except, well, for performance. One of the big differences between ASM.js an PNaCl is that ASM.js just exposes ordinary standardized Web APIs, while PNaCl gives you the Pepper API, which is basically an entirely Chrome specific API. That means that rather than just using Emscripten and compiling with two output targets (PNaCl and ASM.js) which call the same APIs, you need to do a wrapper layer on one or the other (emulating PNaCl with standard Web APIs, or vice versa, or having some other intermediate layer that abstracts over both). The whole point of ASM.js is to leverage existing standardized infrastructure, while PNaCl just exposes what's convenient to expose in Chrome, while likely being considerably more expensive for other browser vendors to implement. This is a lot like Filter Effects in IE. Rather than specifying a reasonably portable syntax, they defined something that was build specifically on some random subset of DirectX filters, and pretty much impossible to implement anywhere else without implementing a large amount of DirectX. While other browsers eventually released most of the same things in a portable manner, there was a while where you had to either implement both or use some kind of wrapper of one over the other. While I think that it's a good thing that Google has spent time experimenting with and building NaCl and PNaCl (in general, you need ad-hoc single engine experimental implementations that people can play around with in part to figure out what will actually work for authors and is actually implementable, like canvas was, or various CSS3 effects over the years), it's a standardization dead end, and it would be nice if they would spend their effort on trying to extract something that could be standardized from it and ASM.js, rather than enabling it for web pages so it'll become another single-vendor technology that leaves others as second-class citizens. This kind of vendor lock in is out of line with promises of openness and supporting standards that Google has made in the past, and especially concerning since they're selling hardware that only runs Chrome. Between locking people in to a single browser on that platform, and a single browser if they target PNaCl (with maybe second-class support for other browsers via Emscripten and pepper.js), this is starting to remind me of what a certain other company did when they had the sleek, fast new browser that was trouncing the big buggy slow incumbent.
yetanotherphd 13y ago
>there's a project called pepper.js that compiles the PNaCl application using emscripten. That made me laugh. You write code that is supposed to compile to native code, only to have it compiled to javascript instead. It's a crazy world we live in.
- pjmlp 13y ago
  It is the hipster world, where an application created to show documents has been subverted into a virtual machine.