Google's answer to Java, Flash, Windows: Native Client
Rumors have abounded over the years about a Google operating system, perhaps based on the Ubuntu version of Linux widely used within the company, but on Monday the company revealed an open-source project that provides a different answer to the same problem: Native Client.
The reason I've been skeptical about Google releasing an operating system of its own is that the company has such a Web-based view of the world. But Web apps have limits, impressive gains of Google Docs notwithstanding, and Native Client is geared to address those.
"At Google we're always trying to make the Web a better platform. That's why we're working on Native Client, a technology that aims to give Web developers access to the full power of the client's CPU while maintaining the browser neutrality, OS portability and safety that people expect from Web applications," said Brad Chen of Google's Native Client team in a blog posting.
Google has a three-lobed mission: search, ads, and apps. It does well on the first two, but Web-based applications remain rough for most users. Native Client could change that if Google develops the project to maturity, convinces people to install it, and convinces programmers to write for it.
The software plug-in works in conjunction with various Web browsers but lets Web-based applications take advantage of a computer's significant processing horsepower. That puts it in a similar camp as Sun Microsystems' Java, Microsoft's Silverlight, and Adobe Systems' Flash, which, like Native Client, include a "runtime" foundation for running the software.
Although Native Client is just a research project at this stage, the move could have powerful long-term consequences for the battle to create the most compelling foundation for Web-based applications. The technology philosophically meshes with Adobe's hybrid philosophy of running applications both on servers and PCs.
So far, Native Client works on Firefox, Safari, Opera, and Chrome on any modern system with an x86 processor running Windows, Mac OS X, or Linux, Google said.
Stephen Shankland writes about a wide range of technology and products, but has a particular focus on browsers and digital photography. He joined CNET News in 1998 and since then also has covered Google, Yahoo, servers, supercomputing, Linux and open-source software, and science. E-mail Stephen, or follow him on Twitter at http://www.twitter.com/stshank. 
all platforms already have the ability to have native apps that can communicate over networks
this is all retarded platforming.
we don't need more platforms, we need apps that are built for the OS we run, and that if needed happen to communicate remotely
Flash is usually avoided there too, but an enterprise will still stump for a license here and there for internal streaming media.
Java OTOH is alive and well in the enterprise. Most high-end and heavy web apps (Google, etc) use it very heavily.
"Java OTOH is alive and well in the enterprise. Most high-end and heavy web apps (Google, etc) use it very heavily. "
It's also highly exploitable and insecure, which is another reason why enterprises are loath to have Java on their network systems as well.
All of them have issues. Google's past record of leaving things in beta, lack of support, and draconian control over content will not help them here.
I love Google, but I'd rather they concentrate on what they're good at, and not continue to spread themselves too thin...
Bleah.
(unless you think that the old System 7 UNIX is the only OS that should exist lest we 'fragment' the OS space...)
"(unless you think that the old System 7 UNIX is the only OS that should exist lest we 'fragment' the OS space...) "
I was actually leaning more towards IRIX, or perhaps something running on a CBM :)
Here's what I don't get -- Adobe and MS are already working on platforms (Flash, Silverlight) that have (or will soon have) a presence on all major browsers and OSes, and will be capable of running fully function applications inside a browser. And managed code is the way ahead for web apps -- easier to develop for, more secure, able to hide architecture details.
So what's Google even thinking with this approach?
1) Whats about none x86 platforms - mobile files etc. What about x64?
2) There is a reason that Java and .Net work the way they do - managed code in a sandbox. This starts to sound a lot like ActiveX controls to me. Do I really want native code launched in my browser. Nope.
3) What "platform" is exposed to the native code? It is OS specific, or what? Again, Java's VM (and also Silverlight) are cross platform.
What is this NativeClient's unique benefit? Its not at all clear.
This does actually make sense, to give full access to a virtual machine, so apps can write to a HD, and you can transfer between them at *your* desire, not the apps desire.
Facebook Connect crashes Firefox half the time and gets identified as a phishing site since it is not coded by Facebook. Developers have to use the libraries and hook it together themselves. This got Facebook blocked for phishing last week.
Not to mention most of these open in new windows and popup blockers will not open the new windows. What a freakin mess they have all made of what could have been really cool.
- by kapil561 January 9, 2009 3:51 AM PST
- How is this different from Google Gears, i mean the goal is the same, isnt it. what am i missing.
- Like this Reply to this comment
-
(36 Comments)