11 ms·

Next-Gen Web Apps: Google unleashes Native Client into Chrome

160 points by lobo_tuerto 15y ago

adelevie 15y ago
Is this analogous to using the Android NDK for Android apps?
- mahmud 15y ago
  Opposite. More like FFI/JNI to Bosch/Qemu. Android NDK, and other foreign-function interfaces are a way to de-secure & de-manage secure code: a controlled mechanism for stepping out of the sandbox. Google NaCL, like other virtualizers, is a way to contain inherently insecure code into a (well?) defined sandbox.
- wmf 15y ago
  Yes, in the sense that NaCl allows JS to call C while the NDK allows Java to call C.
chintan 15y ago
GooactiveX
- dstein 15y ago
  That's a very succinct way of putting it. Google is smelling more like Microsoft every day.
- pagekalisedown 15y ago
  I would've gone with GactiveX, which is a bit more pronounceable. :)
- brunnsbe 15y ago
  ActiveX was also the first thing that popped into my mind. However, the whole ActiveX-lesson learnt everyone, not just Microsoft, how bad things can go if the security issues isn't solved when releasing new technology and I think Google has spent a lot of resources on it. My main concern is how this is going to affect us developers in, let say, next five years. Are we going to need to write even more browser specific code when other browsers also will start to support these native clients?
  - zobzu 15y ago
    what you just said basically: if ms implemented it, its wrong etc we all know that if google does the same, it must have been done better and therefore its ok the point tho: the design is broken security wise. google, ms, apple, whoever else implements it, its going to be exploited, heavily specially as soon as chrome becomes n#1 browser (which will happen no matter what - certainly the no-opt-out install with a zillion of popular apps helps with that)
    - brunnsbe 15y ago
      One has to remember that when ActiveX was introduced in Internet Explorer 3.0 the focus on security was a lot lower than in today's browser development.
tiles 15y ago
This, along with Chrome Web Store, are the first major deviances from Chrome the HTML5 browser into Chrome the platform. It's exciting but also unfortunate that we're starting to see a divergence here, when other browsers are unlikely to pick up NaCl for some time (if at all) and the Chrome Web Store being entirely incompatible. Edit: Mozilla Rejects Native Code Approach of Chrome's NaCl http://css.dzone.com/articles/mozilla-rejects-native-code http://css.dzone.com/articles/mozilla-rejects-native-code
- yid 15y ago
  I think they might also see NaCl as helping drive Chrome's growth, when suddenly a browser can do cool stuff that other browsers can't. EDIT: I'm old enough to remember the browser wars, but I really like most of the trends that Google/Chrome have introduced, from auto-updates to revving the JS engine to fallback-capable SPDY.
  - yuvipanda 15y ago
    Let's hope this doesn't devolve into something similar to the madness that was ActiveX.
    - yid 15y ago
      ActiveX's downfall was a lack of security and relatively high complexity (the two are often related). Google, so far, has had quite a good run in those areas.
      - drgath 15y ago
        No, ActiveX's downfall was that it wasn't part of the open-web. If ActiveX had bullet-proof security, it still would have failed because you'd still only have IE supporting it. In NaCl's case, Chrome will be the only browser to ever support it, which means it is just a nicer flavor of ActiveX, and likewise, I hope it lands flat on its face.
        15y ago
gcv 15y ago
Could someone more familiar with the effort comment on whether Google realistically solved the security and trust problems inherent in the approach? I'm assuming that while(1) fork(); is somehow blocked, but native code is a bonanza of attack vectors.
- krasin 15y ago
  fork is not available under NaCl http://code.google.com/p/nativeclient/issues/detail?id=1239 http://code.google.com/p/nativeclient/issues/detail?id=1239
- xtacy 15y ago
  The Native Client paper[1] was published in 2009. The main reason it took so long to be officially released is that it underwent a lot of scrutiny by various security researchers[2], through the Google bounty program. In fact, NaCl has been shipping with Chrome all along; it just needed a flag to enable it (--enable-nacl). You should read their research paper for interesting insights. [1] http://www.chromium.org/nativeclient/reference/research-papers http://www.chromium.org/nativeclient/reference/research-pape... [2] http://code.google.com/contests/nativeclient-security/ http://code.google.com/contests/nativeclient-security/
consultutah 15y ago
This is actually really cool. It is essentially "safe" activex. I wish MS would have done something like this rather than silverlight.
- calvin 15y ago
  The fact that it's anything like ActiveX is what scares me. I'm not looking forward to further fragmentation of web browser capabilities.
  - yuvipanda 15y ago
    With Mozilla explicitly announcing they won't support it (and we all know how Microsoft will react) - I hope NaCl goes on to die a silent death. Except perhaps in chromebooks. I could see how they'd be useful there.
    - robryan 15y ago
      No support is a bit better than sub standard support, although I guess devs could still have to deal with people wanting a NaCl version created in addition to normal web part of a project.
- nitrogen 15y ago
  .Net and Silverlight, were they open and unencumbered standards not exclusively implemented by Microsoft, would be better than NaCl because .net uses a platform-independent bytecode, which avoids leaking the processor type through the abstraction of the browser.
  - srdjanjovcic 15y ago
    CLI and C# are standardized by ECMA (http://msdn.microsoft.com/en-us/netframework/aa569283 http://msdn.microsoft.com/en-us/netframework/aa569283). Besides Microsoft implementation, there open source one (http://www.mono-project.com/Main_Page http://www.mono-project.com/Main_Page). There is also open source implementation of Silverlight, but not at par with Microsoft one: http://www.mono-project.com/moonlight http://www.mono-project.com/moonlight
nxn 15y ago
I was somewhat irritated when Microsoft was pulling stuff like this with IE. But on the other hand, if they ever do make PNaCl, I will gladly disregard every other browser and target all my personal projects specifically for Chrome. The unfortunate thing is that I haven't seen any news or heard of any progress being made on PNaCl in a long time.
- yuvipanda 15y ago
  Indeed - having different compiled versions of your code go over the wire to the client simply because they're on a different architecture seems so... backward.
andrewf 15y ago
I just switched to the Chrome beta stream, and NaCl still seems to be disabled by default. Is this what others are seeing? (Chrome 14.0.835.35 beta-m on Windows)
- abraham 15y ago
  Looks like 14.0.835.35 is the correct version. http://googlechromereleases.blogspot.com/2011/08/chrome-beta-channel-update.html http://googlechromereleases.blogspot.com/2011/08/chrome-beta...
njharman 15y ago
Meh, very few apps are cpu constrained. For vast majority targeting html5/javascript and it's mindboggingly huge installed base is a bigger win.
- leon_ 15y ago
  > Meh, very few apps are cpu constrained. Maybe on the server side. Client side is a different story. My machine is regularly hitting 100% usage when browsing some fancy JS-driven blogs.
- cageface 15y ago
  This could, at least in theory, make it possible to deliver on the web a serious competitor to Photoshop, for example. I don't see that happening any time soon in Javascript.
  - ootachi 15y ago
    You assume wrong. Modern tracing or type-inferring JITs are heavily optimized for the kinds of tight loops you see in image processing.
    - cageface 15y ago
      All the heavy lifting in apps like that is done in SIMD.
      - ootachi 15y ago
        Which doesn't require NaCl. https://bugzilla.mozilla.org/show_bug.cgi?id=644389 https://bugzilla.mozilla.org/show_bug.cgi?id=644389
- nitrogen 15y ago
  Meh, very few apps are cpu constrained. One must be very careful making statements like this. The only reason you're not seeing CPU-constrained webapps is because they aren't being created, because they would be constrained by the CPU. For example, I'm writing an app that would be significantly better if I could do fast client-side processing of data. Eventually I plan to use WebGL shaders, but I don't know if GLSL shaders can actually do what I need to do. Your second sentence, however, is reasonable.
asadotzler 15y ago
Native Client apps aren't "web apps" any more than Silverlight, Flash, and Java apps are "web apps".
- wmf 15y ago
  Many people consider anything that appears in a browser window to be "the web"; if you want to convince us otherwise, at least give a reason.
  - drgath 15y ago
    I agree that people consider anything that appears in a web browser is a "web app", but that doesn't make it right. ActiveX, Java Applets, Silverlight, Flash, and NaCL are not "web apps." People also think "Internet" is analogous to "World Wide Web." A "web app" is something that is built using open standards that has oversight by a standards committee that is either the W3C or WHATWG.
    - tomjen3 15y ago
      No it is not, unless somebody has taken a trademark on "web app". A "Web app" is whatever is generally understood when people say "Web App".
      - drgath 15y ago
        Feel free to peruse through WHATWG's specification for "Web Applications", or "Web Apps" for short. There is a standardized, very explicit definition of what that term means. http://www.whatwg.org/specs/web-apps/current-work/complete/ http://www.whatwg.org/specs/web-apps/current-work/complete/
        magicalist 15y ago
        I've read it and I don't seem to recall any normative sections defining "Web Application" :)
  - 15y ago
chrisdes 15y ago
We need to use a specific version of NaCl SDK for each Chrome version. See http://http://code.google.com/chrome/nativeclient/docs/running.html http://http://code.google.com/chrome/nativeclient/docs/runni... Knowing how quickly the Chrome version changes and automatically most of the times, it will be very difficult to keep up.
- abarth 15y ago
  This is the first release with a stable ABI: "Applications compiled with version 0.5 of the SDK will work in Chrome 14 and future versions of Chrome." http://code.google.com/chrome/nativeclient/docs/releasenotes.html http://code.google.com/chrome/nativeclient/docs/releasenotes...
zmmmmm 15y ago
The danger here is that we'll see Google lessen its focus on the speed and efficiency of V8 and instead start falling back on NaCl in their own apps. We seem to be at a particularly dangerous juncture right now where all the major desktop OSes are running on x86 processors. Thus a scheme like NaCl can easily take off and then, once we are dependent on it, it can lock us in to specific processors and platforms instead of the dream of the web - running anything anywhere.
- yid 15y ago
  Not a problem -- if NaCl exceeds V8 in development, we just compile Javascript directly to NaCl (using tools that will certainly be devised).
  - nitrogen 15y ago
    How would precompiled JavaScript help? NaCl provides a subset of the processor's capabilities. V8 has access to everything, and is already compiling Javascript to native code. The only way you could exceed V8's performance is by writing a better JavaScript compiler than V8 -- no small task. Anything you can do with JavaScript-[as-yet-unwritten compiler]-NaCl, Google can do with JavaScript-V8-native code.
- cageface 15y ago
  Unlikely. First, thanks to mobile, x86 is far less dominant than it was even a few years ago. Second, Google can't afford to deliver a second-class experience to users not using Chrome. They don't have the kind of market share it would take to get away with that.
- nextparadigms 15y ago
  NaCl is supposed to work on ARM chips, too. I think you need like just a line of code to enable it for ARM machines. Google I/O 2011: Beyond JavaScript: Programming the Web with Native Client: http://www.youtube.com/watch?v=WgbK0ztUkDM http://www.youtube.com/watch?v=WgbK0ztUkDM
  - 15y ago
Animus7 15y ago
Without PNaCl, this feels nothing but regressive, for at least three reasons: 1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains? 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant. 3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it?
- yid 15y ago
  So what you're saying is that you want a JS-to-NaCl JIT compiler (presuming NaCl is faster than V8).
  - Animus7 15y ago
    No, I don't see how JITting JS to NaCl would address any of those issues.
    - yid 15y ago
      > 1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains? If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5. If you can get by with V8+HTML5, and NaCl offers a speed advantage, a JIT compiler will allow you to have the common denominator as well as the improved speed. If you can get by with V8+HTML5 and NaCl isn't a speed advantage, well.... > 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant. But it's always nice to have more speed anywhere. If NaCl is faster than V8, a JIT compiler will allow you -- again -- to have your common denominator and a higher level of performance. 3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it? Lets assume that implementations can be made secure with enough time and money, two things that this project is endowed with. I presume you're implying that Microsoft would mess up the implementation, making it a nightmare for devs everywhere. With browser shares being as egalitarian as they are, a JIT compiler would put the onus of a correct implementation on the vendor.
cyrus_ 15y ago
This is a huge win for developer choice on one front -- choice of client language. Now you can use pretty much any language you want to write your client logic as long as a suitable binding to the DOM via the Pepper API has been developed. Not to mention the ability to write truly performant code (V8 is nice and all but you can't beat native code in tight loops -- media manipulation apps like Photoshop come to mind.) Mono 2.10 already ships with support for NaCl, so you can already use a whole bunch of nice languages over the CLI that way. It'll be interesting to see where this takes the Moonlight project though, since it has similar goals. With Microsoft seemingly downplaying or abandoning Silverlight, so is this the end of the line?
- hencq 15y ago
  Mono with support for NaCL sounds interesting. Does that mean though the browser will have to download Mono every time it encounters a web app that's written in e.g. C#? Or will it only have to download the C# bytecode? On a slight tangent, I've always wondered why Java (or other JVM languages) couldn't make a comeback on the client side. Instead of having Applets that run sort of isolated from the browser, you could just expose the DOM.
  - nikcub 15y ago
    You could host Mono once at a single URL and then include it. It will be cached by the browser just like any other resource. Unlike javascript libraries, there will be more of an incentive to use a single CDN/hosting point, since the package is likely to be a bit larger
  - MatthewPhillips 15y ago
    Presumably it would be a stripped down version of Mono. The .NET Micro Framework is about 300k, for example.
  - cyrus_ 15y ago
    On your second question, they've tried that with things like JavaFX Script. Not sure why there isn't uptake.
- 15y ago
trueduke 15y ago
Mac OS already has its Native Client : the App Store...
- tensor 15y ago
  This is cross-platform and sandboxed. The App Store is just a publishing mechanism.
  - bzbarsky 15y ago
    NaCl isn't exactly cross-platform. At the moment it only works on 3 hardware architectures at most, and that only if you put in some special effort....
jamesu 15y ago
Personally i think this is great for running existing C codebases in the browser, the prime example being games. Good news for say... the chromebook.
ck2 15y ago
Wow one of the reasons for 3rd party browsers has now come full-circle (activex). This combined with how Chrome like to hide things from users so they don't worry their little minds about it (status bar, url bar http, etc.) is a major disaster waiting to happen.
oemera 15y ago
I hope this trend will stop this instant. Why should we develop a Chrome App which only runs in Chrome (cross platform though) ? With existing technologies you can target way more people with all kind of browsers. (Ok there are browsers which are hard to optimize for) I feel like we are going back from all these benefits the browserS gave us.
- nikcub 15y ago
  Think of Chrome as just another OS platform target - in the same way iOS, Windows and OS X are. there will be many more chrome-powered devices in the near future, it is already ~15% of the desktop
- stanleydrew 15y ago
  You don't have to use it. I am really confused by the sentiment in this thread. If you want your web app to be cross platform then don't use nacl. You will be no worse off than you were yesterday before having read this article.
zobzu 15y ago
Google unveils.. ActiveX
StavrosK 15y ago
Everything else aside, I love how the library to complement NaCl is called Pepper.
robgough 15y ago
Are there any examples around to take a look at? I can't seem to find any.
mikecaron 15y ago
I've got beta v 14.0.835.35 beta-m installed but the native client examples don't work for me. Is there something I have to do to enable the NC?
- krasin 15y ago
  What does http://krasin.github.com/naclwtf/ http://krasin.github.com/naclwtf/ say?
Hisoka 15y ago
Good news for consumers. Horrible news for developers. OK.. let's see, we gotta make an iPhone app, an Android app, a web app, one for the Blackberry, maybe one for Windows Phone, and ooh.. a Facebook app! Now a Chrome app..
grimen 15y ago
Ouch. I start to think of Microsoft and Apple. :( So far Google been outpacing my expectations on driving web technologies forward - all this for later go back to the "native client" approach Microsoft had in late 90s (thy stopp believing in HTML/JS). Does this mean MS was right back in '99? I'm really confused about Google's vision of how the web will work in 10 years from now. Anyone with insight in there?

160 points by lobo_tuerto 15y ago

adelevie 15y ago

Is this analogous to using the Android NDK for Android apps?

mahmud 15y ago
Opposite. More like FFI/JNI to Bosch/Qemu. Android NDK, and other foreign-function interfaces are a way to de-secure & de-manage secure code: a controlled mechanism for stepping out of the sandbox. Google NaCL, like other virtualizers, is a way to contain inherently insecure code into a (well?) defined sandbox.
wmf 15y ago
Yes, in the sense that NaCl allows JS to call C while the NDK allows Java to call C.

chintan 15y ago

GooactiveX

dstein 15y ago
That's a very succinct way of putting it. Google is smelling more like Microsoft every day.
pagekalisedown 15y ago
I would've gone with GactiveX, which is a bit more pronounceable. :)
brunnsbe 15y ago
ActiveX was also the first thing that popped into my mind. However, the whole ActiveX-lesson learnt everyone, not just Microsoft, how bad things can go if the security issues isn't solved when releasing new technology and I think Google has spent a lot of resources on it. My main concern is how this is going to affect us developers in, let say, next five years. Are we going to need to write even more browser specific code when other browsers also will start to support these native clients?
- zobzu 15y ago
  what you just said basically: if ms implemented it, its wrong etc we all know that if google does the same, it must have been done better and therefore its ok the point tho: the design is broken security wise. google, ms, apple, whoever else implements it, its going to be exploited, heavily specially as soon as chrome becomes n#1 browser (which will happen no matter what - certainly the no-opt-out install with a zillion of popular apps helps with that)
  - brunnsbe 15y ago
    One has to remember that when ActiveX was introduced in Internet Explorer 3.0 the focus on security was a lot lower than in today's browser development.

tiles 15y ago

This, along with Chrome Web Store, are the first major deviances from Chrome the HTML5 browser into Chrome the platform. It's exciting but also unfortunate that we're starting to see a divergence here, when other browsers are unlikely to pick up NaCl for some time (if at all) and the Chrome Web Store being entirely incompatible. Edit: Mozilla Rejects Native Code Approach of Chrome's NaCl http://css.dzone.com/articles/mozilla-rejects-native-code http://css.dzone.com/articles/mozilla-rejects-native-code

yid 15y ago
I think they might also see NaCl as helping drive Chrome's growth, when suddenly a browser can do cool stuff that other browsers can't. EDIT: I'm old enough to remember the browser wars, but I really like most of the trends that Google/Chrome have introduced, from auto-updates to revving the JS engine to fallback-capable SPDY.
- yuvipanda 15y ago
  Let's hope this doesn't devolve into something similar to the madness that was ActiveX.
  - yid 15y ago
    ActiveX's downfall was a lack of security and relatively high complexity (the two are often related). Google, so far, has had quite a good run in those areas.
    - drgath 15y ago
      No, ActiveX's downfall was that it wasn't part of the open-web. If ActiveX had bullet-proof security, it still would have failed because you'd still only have IE supporting it. In NaCl's case, Chrome will be the only browser to ever support it, which means it is just a nicer flavor of ActiveX, and likewise, I hope it lands flat on its face.
      - 15y ago

gcv 15y ago

Could someone more familiar with the effort comment on whether Google realistically solved the security and trust problems inherent in the approach? I'm assuming that while(1) fork(); is somehow blocked, but native code is a bonanza of attack vectors.

krasin 15y ago
fork is not available under NaCl http://code.google.com/p/nativeclient/issues/detail?id=1239 http://code.google.com/p/nativeclient/issues/detail?id=1239
xtacy 15y ago
The Native Client paper[1] was published in 2009. The main reason it took so long to be officially released is that it underwent a lot of scrutiny by various security researchers[2], through the Google bounty program. In fact, NaCl has been shipping with Chrome all along; it just needed a flag to enable it (--enable-nacl). You should read their research paper for interesting insights. [1] http://www.chromium.org/nativeclient/reference/research-papers http://www.chromium.org/nativeclient/reference/research-pape... [2] http://code.google.com/contests/nativeclient-security/ http://code.google.com/contests/nativeclient-security/

consultutah 15y ago

This is actually really cool. It is essentially "safe" activex. I wish MS would have done something like this rather than silverlight.

calvin 15y ago
The fact that it's anything like ActiveX is what scares me. I'm not looking forward to further fragmentation of web browser capabilities.
- yuvipanda 15y ago
  With Mozilla explicitly announcing they won't support it (and we all know how Microsoft will react) - I hope NaCl goes on to die a silent death. Except perhaps in chromebooks. I could see how they'd be useful there.
  - robryan 15y ago
    No support is a bit better than sub standard support, although I guess devs could still have to deal with people wanting a NaCl version created in addition to normal web part of a project.
nitrogen 15y ago
.Net and Silverlight, were they open and unencumbered standards not exclusively implemented by Microsoft, would be better than NaCl because .net uses a platform-independent bytecode, which avoids leaking the processor type through the abstraction of the browser.
- srdjanjovcic 15y ago
  CLI and C# are standardized by ECMA (http://msdn.microsoft.com/en-us/netframework/aa569283 http://msdn.microsoft.com/en-us/netframework/aa569283). Besides Microsoft implementation, there open source one (http://www.mono-project.com/Main_Page http://www.mono-project.com/Main_Page). There is also open source implementation of Silverlight, but not at par with Microsoft one: http://www.mono-project.com/moonlight http://www.mono-project.com/moonlight

nxn 15y ago

I was somewhat irritated when Microsoft was pulling stuff like this with IE. But on the other hand, if they ever do make PNaCl, I will gladly disregard every other browser and target all my personal projects specifically for Chrome. The unfortunate thing is that I haven't seen any news or heard of any progress being made on PNaCl in a long time.

yuvipanda 15y ago
Indeed - having different compiled versions of your code go over the wire to the client simply because they're on a different architecture seems so... backward.

andrewf 15y ago

I just switched to the Chrome beta stream, and NaCl still seems to be disabled by default. Is this what others are seeing? (Chrome 14.0.835.35 beta-m on Windows)

abraham 15y ago
Looks like 14.0.835.35 is the correct version. http://googlechromereleases.blogspot.com/2011/08/chrome-beta-channel-update.html http://googlechromereleases.blogspot.com/2011/08/chrome-beta...

njharman 15y ago

Meh, very few apps are cpu constrained. For vast majority targeting html5/javascript and it's mindboggingly huge installed base is a bigger win.

leon_ 15y ago
> Meh, very few apps are cpu constrained. Maybe on the server side. Client side is a different story. My machine is regularly hitting 100% usage when browsing some fancy JS-driven blogs.
cageface 15y ago
This could, at least in theory, make it possible to deliver on the web a serious competitor to Photoshop, for example. I don't see that happening any time soon in Javascript.
- ootachi 15y ago
  You assume wrong. Modern tracing or type-inferring JITs are heavily optimized for the kinds of tight loops you see in image processing.
  - cageface 15y ago
    All the heavy lifting in apps like that is done in SIMD.
    - ootachi 15y ago
      Which doesn't require NaCl. https://bugzilla.mozilla.org/show_bug.cgi?id=644389 https://bugzilla.mozilla.org/show_bug.cgi?id=644389
nitrogen 15y ago
Meh, very few apps are cpu constrained. One must be very careful making statements like this. The only reason you're not seeing CPU-constrained webapps is because they aren't being created, because they would be constrained by the CPU. For example, I'm writing an app that would be significantly better if I could do fast client-side processing of data. Eventually I plan to use WebGL shaders, but I don't know if GLSL shaders can actually do what I need to do. Your second sentence, however, is reasonable.

asadotzler 15y ago

Native Client apps aren't "web apps" any more than Silverlight, Flash, and Java apps are "web apps".

wmf 15y ago
Many people consider anything that appears in a browser window to be "the web"; if you want to convince us otherwise, at least give a reason.
- drgath 15y ago
  I agree that people consider anything that appears in a web browser is a "web app", but that doesn't make it right. ActiveX, Java Applets, Silverlight, Flash, and NaCL are not "web apps." People also think "Internet" is analogous to "World Wide Web." A "web app" is something that is built using open standards that has oversight by a standards committee that is either the W3C or WHATWG.
  - tomjen3 15y ago
    No it is not, unless somebody has taken a trademark on "web app". A "Web app" is whatever is generally understood when people say "Web App".
    - drgath 15y ago
      Feel free to peruse through WHATWG's specification for "Web Applications", or "Web Apps" for short. There is a standardized, very explicit definition of what that term means. http://www.whatwg.org/specs/web-apps/current-work/complete/ http://www.whatwg.org/specs/web-apps/current-work/complete/
      - magicalist 15y ago
        I've read it and I don't seem to recall any normative sections defining "Web Application" :)
- 15y ago

chrisdes 15y ago

We need to use a specific version of NaCl SDK for each Chrome version. See http://http://code.google.com/chrome/nativeclient/docs/running.html http://http://code.google.com/chrome/nativeclient/docs/runni... Knowing how quickly the Chrome version changes and automatically most of the times, it will be very difficult to keep up.

abarth 15y ago
This is the first release with a stable ABI: "Applications compiled with version 0.5 of the SDK will work in Chrome 14 and future versions of Chrome." http://code.google.com/chrome/nativeclient/docs/releasenotes.html http://code.google.com/chrome/nativeclient/docs/releasenotes...

zmmmmm 15y ago

The danger here is that we'll see Google lessen its focus on the speed and efficiency of V8 and instead start falling back on NaCl in their own apps. We seem to be at a particularly dangerous juncture right now where all the major desktop OSes are running on x86 processors. Thus a scheme like NaCl can easily take off and then, once we are dependent on it, it can lock us in to specific processors and platforms instead of the dream of the web - running anything anywhere.

yid 15y ago
Not a problem -- if NaCl exceeds V8 in development, we just compile Javascript directly to NaCl (using tools that will certainly be devised).
- nitrogen 15y ago
  How would precompiled JavaScript help? NaCl provides a subset of the processor's capabilities. V8 has access to everything, and is already compiling Javascript to native code. The only way you could exceed V8's performance is by writing a better JavaScript compiler than V8 -- no small task. Anything you can do with JavaScript-[as-yet-unwritten compiler]-NaCl, Google can do with JavaScript-V8-native code.
cageface 15y ago
Unlikely. First, thanks to mobile, x86 is far less dominant than it was even a few years ago. Second, Google can't afford to deliver a second-class experience to users not using Chrome. They don't have the kind of market share it would take to get away with that.
nextparadigms 15y ago
NaCl is supposed to work on ARM chips, too. I think you need like just a line of code to enable it for ARM machines. Google I/O 2011: Beyond JavaScript: Programming the Web with Native Client: http://www.youtube.com/watch?v=WgbK0ztUkDM http://www.youtube.com/watch?v=WgbK0ztUkDM
- 15y ago

Animus7 15y ago

Without PNaCl, this feels nothing but regressive, for at least three reasons: 1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains? 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant. 3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it?

yid 15y ago
So what you're saying is that you want a JS-to-NaCl JIT compiler (presuming NaCl is faster than V8).
- Animus7 15y ago
  No, I don't see how JITting JS to NaCl would address any of those issues.
  - yid 15y ago
    > 1) JS is awesome precisely because of the common denominator. But because Chrome said so, devs should go back to triple-testing everything and dusting off their assembly debugger toolchains? If you absolutely need the flexibility or speed that NaCl offers, then by definition you can't get by with just V8 and HTML5. If you can get by with V8+HTML5, and NaCl offers a speed advantage, a JIT compiler will allow you to have the common denominator as well as the improved speed. If you can get by with V8+HTML5 and NaCl isn't a speed advantage, well.... > 2) With more and more happening on cloud servers, JS engines being mature, and clients just getting faster, the need for that ultimate level of performance feels ever more irrelevant. But it's always nice to have more speed anywhere. If NaCl is faster than V8, a JIT compiler will allow you -- again -- to have your common denominator and a higher level of performance. 3) ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea. And even if Google manages to keep their implementation airtight and standards-conforming, what happens when NaCl takes off and Microsoft takes a crack at it? Lets assume that implementations can be made secure with enough time and money, two things that this project is endowed with. I presume you're implying that Microsoft would mess up the implementation, making it a nightmare for devs everywhere. With browser shares being as egalitarian as they are, a JIT compiler would put the onus of a correct implementation on the vendor.

cyrus_ 15y ago

This is a huge win for developer choice on one front -- choice of client language. Now you can use pretty much any language you want to write your client logic as long as a suitable binding to the DOM via the Pepper API has been developed. Not to mention the ability to write truly performant code (V8 is nice and all but you can't beat native code in tight loops -- media manipulation apps like Photoshop come to mind.) Mono 2.10 already ships with support for NaCl, so you can already use a whole bunch of nice languages over the CLI that way. It'll be interesting to see where this takes the Moonlight project though, since it has similar goals. With Microsoft seemingly downplaying or abandoning Silverlight, so is this the end of the line?

hencq 15y ago
Mono with support for NaCL sounds interesting. Does that mean though the browser will have to download Mono every time it encounters a web app that's written in e.g. C#? Or will it only have to download the C# bytecode? On a slight tangent, I've always wondered why Java (or other JVM languages) couldn't make a comeback on the client side. Instead of having Applets that run sort of isolated from the browser, you could just expose the DOM.
- nikcub 15y ago
  You could host Mono once at a single URL and then include it. It will be cached by the browser just like any other resource. Unlike javascript libraries, there will be more of an incentive to use a single CDN/hosting point, since the package is likely to be a bit larger
- MatthewPhillips 15y ago
  Presumably it would be a stripped down version of Mono. The .NET Micro Framework is about 300k, for example.
- cyrus_ 15y ago
  On your second question, they've tried that with things like JavaFX Script. Not sure why there isn't uptake.
15y ago

trueduke 15y ago

Mac OS already has its Native Client : the App Store...

tensor 15y ago
This is cross-platform and sandboxed. The App Store is just a publishing mechanism.
- bzbarsky 15y ago
  NaCl isn't exactly cross-platform. At the moment it only works on 3 hardware architectures at most, and that only if you put in some special effort....

jamesu 15y ago

Personally i think this is great for running existing C codebases in the browser, the prime example being games. Good news for say... the chromebook.

ck2 15y ago

Wow one of the reasons for 3rd party browsers has now come full-circle (activex). This combined with how Chrome like to hide things from users so they don't worry their little minds about it (status bar, url bar http, etc.) is a major disaster waiting to happen.

oemera 15y ago

I hope this trend will stop this instant. Why should we develop a Chrome App which only runs in Chrome (cross platform though) ? With existing technologies you can target way more people with all kind of browsers. (Ok there are browsers which are hard to optimize for) I feel like we are going back from all these benefits the browserS gave us.

nikcub 15y ago
Think of Chrome as just another OS platform target - in the same way iOS, Windows and OS X are. there will be many more chrome-powered devices in the near future, it is already ~15% of the desktop
stanleydrew 15y ago
You don't have to use it. I am really confused by the sentiment in this thread. If you want your web app to be cross platform then don't use nacl. You will be no worse off than you were yesterday before having read this article.

zobzu 15y ago

Google unveils.. ActiveX

StavrosK 15y ago

Everything else aside, I love how the library to complement NaCl is called Pepper.

robgough 15y ago

Are there any examples around to take a look at? I can't seem to find any.

mikecaron 15y ago

I've got beta v 14.0.835.35 beta-m installed but the native client examples don't work for me. Is there something I have to do to enable the NC?

krasin 15y ago
What does http://krasin.github.com/naclwtf/ http://krasin.github.com/naclwtf/ say?

Hisoka 15y ago

Good news for consumers. Horrible news for developers. OK.. let's see, we gotta make an iPhone app, an Android app, a web app, one for the Blackberry, maybe one for Windows Phone, and ooh.. a Facebook app! Now a Chrome app..

grimen 15y ago

Ouch. I start to think of Microsoft and Apple. :( So far Google been outpacing my expectations on driving web technologies forward - all this for later go back to the "native client" approach Microsoft had in late 90s (thy stopp believing in HTML/JS). Does this mean MS was right back in '99? I'm really confused about Google's vision of how the web will work in 10 years from now. Anyone with insight in there?