Google Goes Native: Offers Sneak Peak at C++ Support in Chromium | Hacker News Reader

Google Goes Native: Offers Sneak Peak at C++ Support in Chromium

readwriteweb.com

95 pointsAnon8452 comments

Google's Native Client is the most exciting thing to happen to the web in a long time. IMVU has always talked about porting our client to the web, but the existing technologies just aren't good enough: Unity3D doesn't support software rendering, Flash is too slow, JavaScript is too slow... Native Client would let us continue to use our SSE-optimized rendering code, securely, without requiring a download.

A colleague was playing around with the NaCl SDK and he said the example app is Quake. Within a day or so, he had an in-browser demo running 9 instances of Quake, with sound, all at the same time.

All this noise about HTML 5 and video codecs? With Native Client, the web app could include whatever codec it wanted.

Ever notice that a simple 2D game such as Farmville runs at 15 frames per second, even on a machine that can play Crysis or Supreme Commander? With Native Client, we'll start to see these types of truly rich experiences on the web.

I'm sorry, Flash, but the web is changing without you...

Edit: I see there is a lot of concern about security. NaCl uses x86 segment restrictions to build a sandbox for untrusted x86 code. Google ran a contest to try to poke holes in it: http://code.google.com/contests/nativeclient-security/

Yeah I gotta say, from my point of view, coming from the games industry, this development seems pretty awesome.

It's looking more and more like we are entering a new age of web/browser innovation. Google, Mozilla, Apple and sometimes Opera are in a browser arms race, each pumping up the speed and capabilities of html/css/javascript to heights not many people imagined they could go 5 or 10 years ago. And with stuff like native client and soon LLVM support I think we're going to see an explosion of innovation as people discover what's possible with the new web.

Long ago some crazy folks managed to cram most of the guts of a processor onto a single integrated circuit, allowing the creation of a crude yet functional general purpose computer with a single printed circuit board and a few commodity support components. This enabled the creation of "personal" computers that were cheap enough and small enough for nearly anyone to own. At first they were far, far less capable than the mainframes and mini-computers of the day, and written off by many professionals as merely toys. But the nature and simplicity of their construction as well as the expanded potential user and developer base enabled for a faster rate of evolution than old style computer systems. At first micro-computers could only run native code, then people started writing simple interpreters and compilers, then developers created command line operating systems, just as had happened for mainframe computers decades ago, the micro-computer was simply playing catch up. But micro-computer development caught up extraordinarily quickly, and then began to surpass mini-computers and mainframes (as the rate of evolution didn't change after having caught up). Mini-computers quickly died out as specialized micro-computers began to take over their old roles.

Will things be the same for the web? In 5 or 10 years will we see web based applications and games more advanced than photoshop, visual studio, and Halo today?

This is a great idea, to have a full powered language running in a VM in the browser. All we need now is to have a more developer-friendly language with a richer VM and framework, like Java.

Err....

Native Client (as the name suggests) is not a VM, it executes x86 machine code (with some limitations to ensure security) directly on the CPU.

My friend is the author of JNext library (http://jnext.org/) which is the same concept implemented for all major browsers.

When he got an email from Mountain View which offered him a Job and working on a similar project it was clear Google is pushing hard into this direction.

The number of network-effect reasons why an end user should care what OS he runs continues to diminish. This is bad for Microsoft, but good for Apple and everybody else. Microsoft attempted to sandbag the browser because it foresaw this endgame, and it knew that its business model is based on a precarious positive feedback loop consisting of Windows, Office, and a very large install base. This feedback loop is broken when one no longer needs Windows to run most available software, collaborate with others, or find supported hardware.

At first, Google's offerings look, as another poster said, like spaghetti flung at a wall in hope that some will stick. I think there's a more cohesive strategy behind it, and it's all about building a platform on top of Windows (and other operating systems) to cut off Microsoft's air supply. Google's cloud printing initiative is a perfect example of this -- if a site's back-end can generate printer-ready content and allow a user to print it locally from a netbook/tablet/phone/whatever, that takes away a major reason to keep a Windows desktop sitting around at home connected to a printer. A user can just buy a Wifi-enabled printer if he cares about dead-tree artifacts.

I'm working now on a GWT application. Why, other than for its own internal purposes, would Google invest so much in this tool? It allows a new generation of in-house corporate apps requiring fast user interaction (think call center) to be built for the browser instead of the obvious Windows-centric alternatives like Visual Basic. One less reason for a Fortune 500 company to deploy 10K Windows desktops. Perhaps a call center could be run on a bunch of ChromeOS appliances?

Look at the initiative to introduce Gb-to-the-home. Google certainly wins if Youtube becomes like a TV network, but the lack of bandwidth also requires users to use home servers to house their content locally. Although appliances for this are certainly becoming more common, many consumers likely use a Windows machine to serve up their content to their TVs.

If I had more time, I'd write about other stuff Google's doing and how I think it ties in to the "layer on top of the desktop" strategy. While a rising cloud/network tide will float all non-Microsoft boats, how does Google justify paying for all the water required? Is the ROI there to support such a subsidy?

t first, Google's offerings look, as another poster said, like spaghetti flung at a wall in hope that some will stick.

It's beginning to look more and more like a Jackson Pollock painting... or maybe a Jackson Pollock exhibition.

So the browser is becoming a VM that can transparently download things off the web... Companies will totally control the software this way.

SaaS is the biggest lock-in, but no one seems to be complaining.

It seems that people have no problem with lock-in if it means convenient solutions or as long as it stays convenient.

The problem isn't lock-in, it's lock-out. Closed source desktop software and file formats can lock you in as tight as any web app, but at least they don't spontaneously change or disappear entirely.

In either cases, the issue comes down to data portability. If you can get at your data, in a reasonably convenient format, you're not locked in. This can and should be provided in any application model and I am relieved, as of late, to see awareness of this spreading fast.

It's a plugin - meaning that we limit the users to using a subset of browsers (those with supported plugins) and forcing them to upgrade it when we want to use the latest features. This is NO worse than flash, it's just you write the apps in C/C++/Go rather than ActionScript.

I don't see the benefit; all I see is another Flash/Silverlight wannabe that puts more reliance on the user understanding their system/installed programs. This is not the future.

Except that you have much greater choice of language. Honestly, I dislike client-side web programming because it forces me to use Javascript, even when Javascript may not be the most appropriate language. This would let me choose one of a large range of languages. Definitely a step up.

Secondly, isn't the point of this that it sandboxes native code? That means you can, potentially, have code running much much faster than Flash can.

More choice and better performance = win IMHO.

Better for us as developers but as for the user of the product (the person paying for/using it) it is not good. We are meant to have the problems and not just pass them to the users.

What problems are you referring to? Surely the problems can't be much worse than what you'd have with Flash anyway.

Merge this with Android, to enable highly optimized games and data-intensive applications that run on all Android platforms. Heck, have the OS implemented with this.

Perhaps they will. webOS just release their PDK to allow this. http://developer.palm.com/index.php?option=com_content&v...

Google can't let Palm get the upper hand, can they? ;)

Android has had an NDK for a while, maybe 8 months: http://developer.android.com/sdk/ndk/index.html

You can code in C and C++ but not with nice javascript bindings like native client has.

I really don't think there's that much integration going on at Google. Maybe eventually but for now, from the outside, it really feels like they're trying to go into many somewhat unrelated directions and hoping some interesting paths reveal themselves and if they converge then so much the better.

From the original sources,( http://blog.chromium.org/2010/05/sneak-peek-at-native-client... ), it seems that this is only x86/x86-64 compatible, wheras most android deployments run on ARM. I don't know how they hope to get around that, as mobile devices seem to be tied closely to the future to the web.

I remember reading somewhere from the NativeClient developers that they have thought about ARM, but just didn't focus on it yet. Of course ARM probably requires some significant new code because you can't use the same barrier technology as x86/x86-64 (or so I think).

It's fairly easy to port Android to x86 platforms, in fact we have some working in our lab. The target here would not be mobile devices but set-top-boxes. It's known that Google is working on an Android STB; however, it seems Chrome OS would be another good choice.

The issue isn't "Can Android run on x86" but "Can the shiny new features Google is developing run on Android phones that already exist?"

That has changed. Native Client now supports ARM:

http://blog.chromium.org/2010/03/native-client-and-web-porta...

They're also working on what they consider the Right Thing: instead of sending instructions for a particular processor, send LLVM bytecode and have the client finish the compilation.

LLVM in the browser == client-side Haskell... Thanks Google!!

"From what we see, Google is planning on enabling additional compilers and plans to support LLVM in time."

They haven't done it yet.

Google provides a modified version of binutils that can create Native Client binaries. This should be enough to compile from any programming language to Native Client binaries.

As for LLVM: I believe the main challenge here is modifying the LLVM JIT compiler to produce Native Client-friendly machine code.

Is there any information about how the native plugins installation process will look like for the end user?

I believe there isn't an install process. But you could always fire up a nightly to test ;)

My guess is this won't see mainstream distribution until they've removed the x86 instruction dependency. I think the shipping version will use LLVM bytecode rather than x86 machine code. (this has been hinted at, too.)

You're probably right about their desire to get rid of the x86 dependency. Distributing LLVM bytecode really is a better way; it'll allow NaCl pages to be viewable on ARM-using devices as well as x86-using PCs without needing to provide separate binaries. As the makers of Android and Chrome OS, Google probably would like to avoid locking ARM out.

The NaCl code itself should ideally be part of the browser, though there will be plugins available. As for code that is to run with Native Client, why should there even be a plugin installation process, any more than you have to install Javascript code on random web sites? Everything runs in a sandbox, so the user shouldn't need to worry about it.

They also hint that the Native Clients could eventually work in IE/Firefox. But they will rely on open-source contributions to port NPAPI/Pepper to those browsers..

https://groups.google.com/group/native-client-discuss/browse...

"A subset of our current functionality works in Firefox, for example (though it's currently missing some important parts, like 3D)"

I wish they would have started with LLVM or some other bytecode rather than x86 but this is a huge step towards having other languages in the browser.

Go?

Go already works in NaCl

Guess what. They support LLVM too! http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf

I understand the reasoning behind wanting LLVM but targeting x86 first actually makes a lot of sense. It differentiates this project from Silverlight, JavaFX, and Flash for one thing. But going as low-level as possible is a great way to start the platform and ensure that it's secure and free from cruft at the very bottom. It gives them a solid basis to begin adding on the abstraction layers like LLVM and binaries for other CPUs without settling on any one technology.

Is this their way of conceding that nobody is really serious about making rich graphical apps in JavaScript?

Also, Google sure throws a lot of spaghetti on the wall to see if something will stick, don't they? From this to Chrome OS to their JavaScript stuff to Android to Go and on and on.

> Also, Google sure throws a lot of spaghetti on the wall to see if something will stick, don't they? From this to Chrome OS to their JavaScript stuff to Android to Go and on and on.

You make it sound like they aren't related :)

Spaghetti and Android ARE completely unrelated :-)

JavaScript + Go/NaCl seems like a pretty sweet stack

This makes a lot of sense in combination with Chrome OS. Once we have an OS that's just a browser, we can still run high-performance apps. If I would switch to Chrome OS today, there's quite some things that I'd be missing, and NC can help making the transition a lot easier.

Guess I need to start brushing up on C/C++ now

This seems like a neat idea, however what are the chances of other browsers supporting this? Since IE is still the dominant browser, I don't see many companies wanting to go for this since it would isolate all non-chrome users.

How does Google plan to spread adoption of this technology?

Didn't we all think that ActiveX was a bad idea? Why is Google reinventing it?

It isn't ActiveX. ActiveX is basically OLE/COM components in the web browser and allows execution of arbitrary code. Code has full access to the Win32 API and full access to the system. Native Client on the other hand is sandboxed at the CPU instruction level.

What about security? Do they have a layer enforcing the sorts of constraints that javascript is currently restricted by?

Much better security architecture. If you're technically inclined, you should read their paper about the NaCl architecture. http://nativeclient.googlecode.com/svn/trunk/src/native_clie...

Indeed, the point of NaCl is that it's not going to be another ActiveX-style security nightmare, so people might actually use it. That will be great.

Anyone has a link to a NPAPI/Pepper interface in another language than C++?

Hah, I'm going to port WebKit to NaCl SDK. :)

Let's hope this can be an open standard, otherwise Steve don't like it.

http://www.apple.com/hotnews/thoughts-on-flash/

..HTML5, the new web standard that has been adopted by Apple, Google and many others, lets web developers create advanced graphics, typography, animations and transitions without relying on third party browser plug-ins (like Flash). HTML5 is completely open and controlled by a standards committee, of which Apple is a member....

Reply on news.ycombinator.com