Google's dilemma: A faster but fragmented Web?
Google's dilemma: A faster but fragmented Web?
A powerful new Google+ photo app embodies a sticky
situation facing Web developers: embrace the Native Client tech for
high-performance Web apps and risk sites that only work for Chrome users.
Stephen Shankland by Stephen Shankland September 24, 2013 4:00 AM PDT
Google wants a Web that looks very different from
today's. Instead of more or less static sites, perhaps spiced up with a new
comment popping up on your Facebook page, Google wants Web apps that are
indistinguishable in performance and sophistication from native programs like
high-end games or Photoshop.
But Google faces a tough choice: What's the best way to
get to that future?
The promise of the route it's trying to take, a
technology called Native Client, shines in the sophisticated online
photo-editing tools for Google+ that launched this month.
The problem is that Native Client isn't sitting well with
other browser makers, at least one of which prefers an alternative called
asm.js. And without other support, Native Client makes a poor candidate for the
Web standards that Google wants to see prevail.
Google plays a long game: It's willing to invest for
years in projects it believes the world will eventually come to appreciate. But
in the meantime, there's a risk that its choices will mean a Web afflicted with
error messages warning that "This site works only in Google Chrome."
Living up to its potential
Native Client, or NaCl for short, is designed to bring
high-performance software to Web apps. Today's Web software, written in
JavaScript, usually is vastly slower than programs built to run natively on an
operating system.
Some programmers, chiefly game developers, have embraced
Native Client, but the impressively polished and advanced Google+ photo-editing
app is in a different class.
For one thing, it's placed squarely in front of the large
population of Google+ users.
For another, it's built directly into the Web site. That
makes it much more convenient than what Google has done in the past, which is
to make NaCl software available only through its Chrome Web Store. That big
detour means more hassles using NaCl software and thus many fewer users.
In other words, Native Client is starting to live up to
its potential.
But there's a big problem with Native Client: It's not a
Web standard, and even Microsoft these days agrees that standards are the way
to advance Web programming.
Thus, Google is on the horns of a dilemma. The company
could do a lot with NaCl -- build advanced versions of Google Sheets that can
perform heavy-duty calculations, for instance -- but only Chrome and Chrome OS
users would be able to benefit, and the Web would suffer significant
fragmentation.
The people caught in the middle are the programmers. If
they want to tap into Native Client's power, they have to consider whether
they're willing to bring their software only to Chrome users. There's not much
risk if software is only distributed through the Chrome Web Store, but Google
plans to bring Native Client to the broader Web. That means Web developers will
risk confusing or frustrating non-Chrome users -- and if Google should someday
scrap Native Client, it could mean a broken Web site.
Google declined to comment for this story.
Advancing the Web
It's completely ordinary for browser makers to try new
technology on their own with the hope that Web programmers will like it and
other browsers will be persuaded. That's worked well for Google's new SPDY
networking technology, for example, that's now becoming an IETF standard after
others realized its advantages.
But no other browser maker supports Native Client, and
indeed it has mostly faced years of hostility.
The problem with Google's approach: It raises the
possibility that some programmers will embrace it but others won't. That, in
turn, means a part of the Web only works on Chrome, undermining the
universality of the global medium.
Even the Google team that builds the Blink browser engine
at the heart of Chrome has principles at odds with NaCl: "We strive to
ensure that the features we ship by default have open standards" and to
avoid Web compatibility problems stemming from nonstandard technologies.
Brendan Eich, the original creator of JavaScript and now
Mozilla's chief technology officer, prefers an alternative that his team is
building into Firefox: asm.js. With asm.js support, a browser can run a special
subset of JavaScript instructions much faster, and with tools like Mozilla's
Emscripten, programmers can convert their C or C++ software into that subset.
"In raw computation speed asm.js could match Native
Client" for a project like the Google+ photo-editing software, Eich said,
though he declined to comment on the specific case of that particular software
since he wasn't familiar with its actual code.
Speed tests running the same software show asm.js
performance to be "within a reasonable percentage of PNaCL, which is
likely good enough for even computationally intensive apps like Snapseed,"
Eich said. Software also can get a boost by offloading some tasks to a
computer's graphics chip using the WebGL standard, he added.
What is Native Client?
NaCl is a special-purpose environment for running adapted
C or C++ programs in a browser at close to the native speed. It provides
security mechanisms to ensure that people aren't just clicking on a link and
running malware that could wreak havoc on their machines. It can handle
software that's heavily threaded -- meaning different elements run
simultaneously for better performance.
By running programs adapted from their original form
written in the C or C++ programming languages, Native Client reaches close to
the speed of native software on a PC. Google thinks NaCl speeds can approach a
few percent of native-software speed.
Google bolstered Google+ by adapting existing
image-editing software it got from its acquisition of Snapseed developer Nik
Software.
The photo software is impressive. In addition to a
handful of sophisticated, customizable effects filters that go well beyond the
likes of Instagram, it has the highly regarded Nik editing system that lets
people adjust specific areas of an image with control points.
A more recent variation of Native Client called Portable
Native Client (PNaCl) works on devices such as most mobile phones that don't
have the x86 processors that power PCs. With PNaCl, the Native Client idea can
spread to new hardware such as the Samsung Chromebook; it's due to ship with
Chrome 30, which is currently in beta testing.
Native Client uses another open-source Google technology
called the Pepper plug-in application programming interface (PPAPI), which
defines how NaCl and other plug-ins can draw upon the browser's resources.
PPAPI is designed to be a more powerful alternative to the NPAPI that dates
from the bygone Netscape era of browser development.
Pepper, too, faces challenges. For one thing, prevailing
thought in browser development circles considers plug-ins such as Java,
QuickTime, Silverlight, and Flash to be relics of the bygone browser era. Like
NaCl, no other browser maker supports Pepper.
Although Pepper and Native Client aren't standards, it's
possible they could become so in the future. They are both open-source
technologies, meaning that others that wish to implement them or even just
experiment can get off to a running start.
Samsung apparently found Google's technology persuasive
when it comes to the Samsung Smart TV software developer kit, which lets
programmers write apps for the Korean electronics company's televisions.
The Google+ photo-editing app certainly shows a lot more
horsepower than you'll see in most Web apps, so it's a pretty good ambassador
for Native Client. As the Web developer world strives to build an alternative
to platform-specific native code -- programs that only work on one operating
system -- Native Client could have significant appeal.
Native Client could also attract developers once it's
available on the Web at large, not just through sites or apps that are
specifically installed through the Chrome Web Store.
Absent strong developer enthusiasm, it doesn't seem
likely other browser makers will budge anytime soon and reverse their NaCl
opposition. Perhaps Google's project will fuel faster work to build an
alternative, and if it's competitive, Google could change horses the way it
dropped its own O3D software for 3D graphics on the Web in favor of WebGL.
Google does seem wedded to Native Client, though, in part
because of its security protections. It's even considering moving Chrome's
entire browser engine, Blink, into Native Client -- though that would be a
deep-level move that wouldn't affect Web developers' programming choices.
Some at Google have expressed interest in asm.js, but for
now, the Chrome programmers are marching down the Native Client path.
The big question is whether the Web will follow.
Comments
Post a Comment