
    Google Goes Native: Offers Sneak Peak at C++ Support in Chromium - Anon84
http://www.readwriteweb.com/cloud/2010/05/google-native-client.php?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+readwriteweb+%28ReadWriteWeb%29&utm_content=Google+Reader
======
chadaustin
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/>

~~~
InclinedPlane
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?

------
abdulhaq
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....

~~~
DrJokepu
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.

------
tzury
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.

------
ShabbyDoo
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?

~~~
MaysonL
_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.

------
blub
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.

~~~
extension
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.

------
tgandrews
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.

~~~
dkersten
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.

~~~
tgandrews
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.

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

------
stcredzero
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.

~~~
colonelxc
From the original sources,( [http://blog.chromium.org/2010/05/sneak-peek-at-
native-client...](http://blog.chromium.org/2010/05/sneak-peek-at-native-
client-sdk.html) ), 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.

~~~
Jun8
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.

~~~
Zev
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?"

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

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

They haven't done it yet.

~~~
DrJokepu
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.

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

~~~
ed
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.)

~~~
sketerpot
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.

------
jrbedard
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...](https://groups.google.com/group/native-client-
discuss/browse_thread/thread/a24776cd7da86fd2)

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

------
ghempton
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.

~~~
stcredzero
Go?

~~~
ineol
Go already works in NaCl

------
WilliamLP
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.

~~~
Batsu
> 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 :)

~~~
stretchwithme
Spaghetti and Android ARE completely unrelated :-)

------
chriseidhof
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.

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

------
proee
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?

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

~~~
FooBarWidget
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.

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

~~~
xtacy
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...](http://nativeclient.googlecode.com/svn/trunk/src/native_client/documentation/nacl_paper.pdf)

~~~
sketerpot
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.

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

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

------
tszming
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....

