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
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.
"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.
Post a Comment