(Sorry — I could not resist another ‘Go’ pun in the title!)
I recently looked at Google’s Go programming language. At first glance, it seems to be a good option for desktop or server-side web development, but it appears that Google has more ambitious plans.
According to source code comments and interviews with the development team, Go may be integrated within the Google Native Client (NaCl). NaCl is an open-source plugin which allows native 32-bit x86 code to run directly within a web browser. The code is sandboxed, verified, and restricted to ensure it cannot cause any damage to the browser, other applications, or the underlying OS. Although NaCl is experimental, it is already included (but disabled) in the Chrome web browser and Quake has been converted to demonstrate the technology.
Potentially, Go could be a good fit for NaCl. Developers could deploy compiled executables, or even the raw source code, which would run quickly within the browser. Complex games and processor-intensive applications would be possible.
Do We Need More Plugins?
How many plugins do you have installed? Most people will have Flash, Java, Adobe Reader, and perhaps Silverlight or Google Gears. Novice users who click “Yes” to every prompt probably have dozens.
The web’s main attractions are platform independence and instant deployment. Yet the industry’s obsession with moving every desktop application online is provoking plugin development which negates the advantages:
- Relying on a plugin violates platform independence. Creating a Go-based client-side application will almost certainly tie you to Google Chrome since NaCl will never be available for all OS and browser combinations. Many web applications still rely on IE because ActiveX was used — even though Chrome and Firefox have ActiveX implementations.
- NaCl and Go will offer raw speed so games, graphic, and video applications are logical choices. However, complex applications can be hundreds of megabytes in size — instant deployment is unlikely. While I accept NaCl is very clever, processor-intensive applications will certainly run better outside the browser.
Mozilla expressed similar concerns in their recent criticism of Google Chrome Frame. Although Chrome Frame is a niche solution to a known problem, Mozilla is worried that the web could become fragmented if companies eschew web standards in favor of plugin-based solutions.
I’m not saying all plugins are necessarily bad and, in some cases, they provide facilities that will eventually become a browser standard. For example, Flash allows us to view a video today rather than wait a few years for HTML5’s video tag. However, the web and the desktop are different platforms with their own strengths and weaknesses. Although the boundaries are increasingly blurred, is it sensible to use plugins to shoehorn a desktop application into the browser?
If you find yourself becoming increasingly reliant on plugins, perhaps you should consider a redesign so your application exploits web technology. Alternatively, release a desktop application that utilizes web connectivity when necessary.
Google — have fun with NaCl, but please don’t turn the web into a distribution platform for Go-based binary applications!
What do you think? Is NaCl and Go a great idea? Do we have too many plugins or do they improve the browser experience? Should web browsers be used as an application platform if they continually need bespoke improvement?
Craig BucklerCraig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.
