Next-Gen Web Apps: Google unleashes Native Client into Chrome
techcrunch.com
techcrunch.com
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?
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.
Yes, and in that case perhaps you should not be creating a web app anymore. The web is not the only platform for software development and nor should it be in my opinion.
Unfortunately, this war has been lost, in the minds of developers in general. Nearly everyone seems to think that the web-browser is a modern day X server, and that it's The One True Way to remote out UIs or to distribute apps.
I do wish people would look beyond this and consider some other options and invest some time and energy on some of the other choices, but it just ain't happening for the most part.
Also, the idea that you can just ship a JIT in Native Client and have the performance not hugely regress is unproven. Modern JavaScript JITs are fundamentally based around self-modifying code (look up how PICs work). NaCl penalizes self-modifying code by requiring that it run through a verifier. It would require a lot of engineering effort just to avoid huge JS regressions (like this 2.5x slowdown from a year ago [1]); why not spend that manpower to improve JS engines?
[1]: http://code.google.com/p/nativeclient/issues/detail?id=731
2) For the problems we have today you may be right, but you forget the class of problems that couldn't be done the old way. We can now do them.
3) People will learn not to use MS products? But in all seriousness that will be MS problem.
Anyway it is open source, I doubt Google has chosen a license which MS would object to.
Nah, I don't know. As a user I'm pretty much pissed off when my multicore machine is hitting 100% on 3 of its cores when browsing some blog.
> ActiveX long ago taught us several reasons for why auto-downloading and running native code is a bad idea.
It's not much different to downloading and running JS. Heap Spraying attacks are the simplest you can run against a JS vm. Then there's more advanced attacks that abuse the JITs nowadays found in VMs to generate malicious native code. And I bet not many JS VMs check their generated code for sanity - which NaCl on the other hand does.
That's due to shitty coding by the front-end developer of the blog. With power comes responsibility; writing in C is a lot of power but there are far more opportunities to write shitty code.
You should try NoScript and/or RequestPolicy for that.
I'm really looking forward to this possibility, making the Chrome Webstore as a sales platform even more interesting in the long run.
Edit: Mozilla Rejects Native Code Approach of Chrome's NaCl http://css.dzone.com/articles/mozilla-rejects-native-code
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.
Q. Is Native Client open? Is it a standard?
Native Client is completely open: the executable format is open and the source code is open. Right now Native Client is in its early stages, so it's premature to consider Native Client for standardization.
If it lives up to its promise, and Chrome is the only browser to support it, then it says more about the other browser vendors than anything.
If something is standardized and approved by the W3C or WHATWG, and no other browsers support it, then yeah, come back and we'll chat. But that's not going to happen anytime soon. Until that happens, it shouldn't be inside of a web browser and promoted as web technology.
In fairness, the argument you actually made is 'the browser vendors ought to support something only if WHATWG or W3C approves it', which expands to 'the browser vendors should support something only if the browser vendors collectively want to support it, or if W3C approves it'. But that leads to obvious questions. Why is W3C approval critical for technologies of which the browser vendors collectively disapprove, but of distinctly secondary importance for the technologies they collectively like? And when was the last time the browser vendors shown much sign of meekly accepting W3C-approved technologies of which they disapprove? It seems very much as if the WHATWG HTML coup was not only about adopting features which the browser vendors wanted but which W3C was slow to standardise, but also about stymieing features which the W3C approved of but which the brower vendors don't like (like RDFa, namespaces, and HTML modularisation). So setting the W3C up as an alternative gatekeeper here seems almost as cheeky as advancing the WHATWG.
Of course if you _want_ use of the Web to be tied to particular hardware architectures, then Chrome's push with NaCl is ok. But some people and organizations consider such ties to be a really bad idea.
Doesn't have to be that way It's only supported in Chrome because Mozilla is refusing to implement it for not other reason than... I really don't know what their reasons are. There is even a plugin for firefox. Google has accepted a ton of Mozilla invention even killing some initiatives like O3D in favor of WebGL. And plenty of other such bridging moves. I'm not seeing the love from the other side but I might be reading the situation wrong. I have no internal info as too how the debate went over NaCL.
Also, NaCL is being use by Google for some scientific computing stuff where they put scientific code written by external scientist and run it in Google datacenters. I'm starting to think this could be kickass for cloud apps.
Please explain to me why it should die?
Now to be fair, Mozilla is going to have something similar in potentially WebCL. But it's not exactly the same thing but close.
Probably because NaCl blasts way beyond a leaky abstraction into hard-coded dependency on a specific processor. Mozilla (I'm guessing) wants the web to be a leak-proof abstraction. There are half a dozen different architectures on which one may want to run Firefox (x86/x86-64, PPC, ARM, Sparc, MIPS, etc.). NaCl requires in-depth security analysis and implementation for each platform, plus every web developer would have to compile and test a version of their code for every platform (or, more likely, they'll just support x86, maybe ARM).
PNaCl using LLVM would be slightly better, but WebCL is probably the best approach to number crunching in web apps. Security is also easier at a higher level of abstraction.
It has a whole bunch of tier-2 architectures that are supported but to a lesser extent (e.g. a patch that breaks one of them doesn't automatically get backed out immediately). People are shipping and using Firefox on various of those architectures, including JS jits on at least Sparc and PPC.
Mozilla is a big proponent of WebM.
The DOM? Not sure what you are implying.
Popular ajax web applications were shipped as early as 2000 (Outlook Web Access) and 2002 (Oddpost). The term "ajax" was coined in Feb 2005, around the time of Flickr (2004), Gmail (2004), and Google Maps (2005). But of course the coining of term was a recognition of something that was already happening, not the spark.
The w3c standardized XHR in April 2006, but I think WhatWG may have spec'd it earlier. I can't find the history.
The same thing happened with the DOM, though much quicker. Something you'd recognize as the modern DOM was first shipped by IE 4, in 1997. The first bits of it were standardized by DOM level 1 in late 1998, with most of the rest coming from DOM level 2 in late 2000. The first Netscape implementation was shipped in 2000 (Netscape 6.0).
My point here is that many successful web technologies began just as NaCL is beginning. Technologies have frequently become part of "the open web" through this exact process.
http://en.wikipedia.org/wiki/XMLHttpRequest http://en.wikipedia.org/wiki/Internet_Explorer_5.0 http://en.wikipedia.org/wiki/Ajax_(programming)
The point of my post that you originally commented to was that web technology needs to be supported, cross-browser, to gain a foothold. NaCl will not see that, yet Google is actively promoting it as part of the web (see announcement blog post).
Or all of the Google Gears features that became HTML5 features? Or any number of other examples.
It's the same story with every technology Microsoft tried to embrace, extend, and extinguish. It was Windows and its API that gave them the power, not any programming language or compile target.
In light of that, NaCl is not at all the same beast as ActiveX. It doesn't matter that nobody else is implementing it now, as long as they can implement it, should it one day become strategically important.
If Google has a secret weapon equivalent to the Windows API, it's their suite of cloud services. When you catch them using their browser to lever people onto Gmail and G+, that's when it's time to cry foul.
That said, I wouldn't trust web developers to promptly recompile their apps for new architectures, so the LLVM approach is greatly preferred.
NaCl is not going to have the same ubiquity as the web proper. It's a way to deliver applications over the web, not web sites.
Except they can't, in many cases. Recompiling for a new architecture is rarely trivial.
More importantly, there would be no impetus to recompile for a new arch with low market share, so its users would be just as locked out of NaCl stuff as if it _were_ trivial to recompile.
> so the LLVM approach is greatly preferred.
Except LLVM isn't architecture-agnostic, in general.... just doing LLVM lets you abstract away some aspects of architectures, but by no means all.
> It's a way to deliver applications over the web
Sure. But it would sure suck if you had to get Google to recompile gmail for your new architecture in order for your users to have access to it, as opposed to just writing a JS interpreter or JIT for your architecture!
And gmail and its ilk are _exactly_ what NaCl is trying to target.
Also: this is a dumb thought, perhaps, but was just thinking about why browser sandboxing is so important.
Obviously (on a non-Chromebook at least) people can download and run any app locally, with the download itself often occurring through a web browser.
So why is sandboxing important?
I guess the issue is that you are downloading and running a full app with each page request, and often this download/execute cycle can occur on a script tag that is never explicitly approved by the user, so the frequency and invisibility of executing foreign code is much greater.
This is doubly true if you're talking about a Chromebook, whose administration and security features rest upon the fact that someone can't install stuff locally.
Also, the model of "trust every NaCl executable before you run it" breaks down in this environment...because Google depends on the fact that people must be able to trust clicking links they've never seen before [i.e. that they just searched for].
So it's really extremely important to their bottom line that they nail any security issues with NaCl. This may be different from MS's perception of ActiveX security as a priority.
Just some musings.
As for comparisons to ActiveX, they are completely different. ActiveX was not designed to place any restrictions on the downloaded code at all. In contrast NaCL is designed to completely restrict the downloaded code.
Yes, there can be implementation bugs, just as there are implementation bugs in browsers. But it's a really important difference to say that full local privileges in NaCL is a _bug_ that will be fixed. Whereas full local privileges in ActiveX is a _feature_ that will not be fixed.
At the same time though, sacrificing progress for standardization's sake is most unwanted. It is inevitable that some companies will make some superior innovation, and other companies might not want to adapt that right away, or perhaps they'd like to build something even better. But that's okay.
This kind of leapfrog might be hard for developers because they will have to have different branches of their product, but it is a net win for users because the ones on the "superior" platforms get access to the best technology around and it therefore places pressure on the competition to adopt this new superior technology or move ahead with something better of their own.
Relatedly, I think others in this thread are forgetting why exactly ActiveX was not a good thing.
To me, this is more analogous to XUL: an open-specced, open-source way to do something new in a browser that no other browser vendor ever implements. XUL didn't hurt the web (though it certainly still gives Firefox addons a competitive advantage), and -- at least as long as native client isn't adopted by other vendors -- I don't really see this hurting the web either.
Meanwhile, I'm going to keep writing javascript.
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.
Google I/O 2011: Beyond JavaScript: Programming the Web with Native Client:
while(1) fork();
You should read their research paper for interesting insights.
[1] http://www.chromium.org/nativeclient/reference/research-pape...
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?
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.
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
But you can. https://bugzilla.mozilla.org/show_bug.cgi?id=618692#c1 has a simple example where Java beats gcc -O3 by a factor of 1.5 or so on exactly such a loop. This is not an isolated case, and I fully expect JS JITs to get there for many situations. Unless browsers stop improving them, of course.
"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...
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.
Surely you're more informed than the "many people" you refer to?
Is it a purely definitional argument about what constitutes a "web app"? That raises the question of what exactly "the web" is and who gets to decide, on what basis - but more importantly, who cares? Let's all adopt Native Client apps in the place of web apps and call them something else.
Is it a "standards" argument against NaCl adoption, ie. "Mr. SOCKWG says No!"?
Or is it an argument on technical merit against NaCl adoption? If so, you'll need to spell it out in more detail. Appealing to "Web = Good" is a fair enough starting point, because the Web is Good, but it's not enough here. NaCl advocates (or some of 'em) are presenting an argument about why the Web is good, and how it (or some Web' that isn't the Web - again, definitions in themselves are nothing) could be better. To simply repeat "Web = Good" in reply would be make of the Web a cargo cult - and, one can't help noticing, a cargo cult which just happens to operate very much in the interests of the shrine guardians.
Except perhaps in chromebooks. I could see how they'd be useful there.
There is also open source implementation of Silverlight, but not at par with Microsoft one: http://www.mono-project.com/moonlight
But outside of that, "substantial lag time"? In my opinion the mono team has always been exceptionally fast when it comes to implementing new features in the .NET world. Plus mono has its own tool sets and features that aren't in the regular .NET framework and wont be any time soon.
I am not saying that Mono is the VM I'd like browsers to implement, but my reasons are definitely not related to it not being able to come with the ASP.NET framework.
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)
I feel like we are going back from all these benefits the browserS gave us.
there will be many more chrome-powered devices in the near future, it is already ~15% of the desktop
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.
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.
(Chrome 14.0.835.35 beta-m on Windows)
http://googlechromereleases.blogspot.com/2011/08/chrome-beta...
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.