By Craig Buckler

Why Google Should Not Give Chrome the Go-Ahead

By Craig Buckler

Google Go Gopher mascot(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:

  1. 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.
  2. 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?

  • lucentminds

    If Google can bring about faster, more efficient browser-based games, apps, or plugins then I say go for it. Shockwave revolutionized the web since it first came out, resulting in Flash media and development have become an industry of their own, and allowing you to write browser apps that can do things the browser/javascript cannot accomplish on it’s own.

    Mostly NaCl and Go could lead to a better competitor of Flash than Silverlight.

  • Brad Montgomery

    I think NaCl and Go is a great idea. Besides competing with Flash/Silverlight, I think this also places Chrome to compete with things offered by Firefox addons. There are tons of possible, useful apps that would complement the browser.

  • Frank Malina

    Shockwave is closed source, Go is BSD. NaCl and Go is a great idea. Once released it will be closer to become standard, Flash will never be a standard due to its licensing.

  • chrelad

    “Google — have fun with NaCl, but please don’t turn the web into a distribution platform for Go-based binary applications!”
    Hmmmm, let’s see how far we can take this:
    Mozilla — have fun with XULRunner, but please don’t turn the web into a distribution platform for XULRunner-based applications!
    Microsoft – have fun with ActiveX, but please don’t turn the web into a distribution platform for ActiveX-based applications! (seriously)
    Sun/Oracle – have fun with Java, but please don’t turn the web into a distribution platform for Java-based applications!
    W3C – have fun with XSL, but please don’t turn the web into a distribution platform for XSL-based applications!
    W3C – have fun with HTTP, but please don’t turn the web into a distribution platform for HTTP-based applications!
    Hmmm, I suppose it is *their* choice to do what they want on the Internet and it certainly is *our* choice whether or not we want to use it.
    To answer your question about whether or not I think Go and NaCI are a good combo… I dunno. I’m still trying to drink in Go itself. It’s a very exciting language from what I’ve seen so far though. Especially interfaces, channels, and how they implemented funcs and visibility 8)
    By the way, NaCI *can* be used with Firefox (
    If Google can get native code to run inside a browser and come up with a standard like NaCI so other browsers can do the same, then cool. If they can get Go to work with that standard, then double cool. If I don’t like it, I ditch it and uninstall the plugin; or, since it’s open source, I could fix what I don’t like about it; or, since they have a bug tracker and a community of people that can fix the bugs for us, we could just file a bug report and wait for it to be fixed.
    I do understand where you are coming from though. As an example, the repercussions of Microsoft releasing IE6/ActiveX are still felt today and I doubt Microsoft will ever hear the end of it. Could Google fall into the same trap by releasing NaCI and everybody writing mission critical applications that rely too heavily on it? Hopefully we as developers have learned our lesson.
    BTW: How do you get line breaks to show up in your post? <br>’s? Nevermind… Got it!
    Nice article, consider your opinion respected :)

  • Pierre Boissonnet

    I would love to have javascript replaced by something like GO. This would enable a single code base for both frontend and backend operations and it could simplify greatly offline / ajax based applications.

  • I would love to have javascript replaced … it could simplify greatly offline / ajax based applications.

    So would server-side JavaScript … that already exists and you wouldn’t need to learn another language!

  • Anonymously

    Blah, what a freaking mess — really not sure why Google didn’t buy Sun or at atleast MySQL and JAVA from them…

  • Anonymous

    “Mozilla is worried that the web could become fragmented if companies eschew web standards in favor of plugin-based solutions.”

    Fragmented in what way? The use of Google Chrome Frame would not eschew web standards, it would *use* those standards to deliver content and/or provide facilities beyond that possible within the standards without forcing lock-in to the extensions.

    I see no harm in diversification of delivery means via the pipe generically nameable as the Internet–especially in cases like this, where extension beyond “standard” is provided by open-sourced means–as long as users are not hobbled or exploited by proprietariness through that diversification.

    “Please don’t turn the web into a distribution platform for Go-based binary applications”? Why not, if doing so *adds* function/facility to the Internet/web that does not detract from its existing toolness? Why think OR when you can think AND?

    As for “processor-intensive applications will certainly run better outside the browser,” that will probably always be true. So, what? What Google is trying to do with Chrome Frame and Go is improve the quality of Good Enough as delivered via a browser. If you want to model weather or globular clusters, better run your code natively.

    I see no Balkanization of the net occurring as a result of Chrome Frame and Go; I see only the net’s further diversification and evolution as a multipurpose tool.

  • Post Anonymously

    Doesn’t this fit right in with the vision of a browser-only OS, running on netbooks and such. I’ve continually read comments similar to: “I’ll never be able to work in the cloud! Try running Photoshop or playing FPS in your browser…”. Well, if your browser has the full attention and resources of the box, and an integrated systems language, why not?

  • Wardrop

    The main thing articles like this highlight, is the fact that web standards are progressing too slow. I don’t blame Google or any other browser developer (with the odd exception) for making such plugins. The point being missed by the W3C, is that web sites and applications aren’t “text documents” any more. HTML, including HTML 5, is not very flexible, nor does it accommodate more advanced web applications. Web apps will always struggle to compete with Desktop applications, unless the W3C (or some other body) adopt a more generic, flexible mark up language, and yes, that means no semantics. Leave semantics to micro-formats are recommendations, it should be the choice of the author to best decide what standards and recommendations should be followed for his web site/application.

    So in summary, web technologies need to focus less on solving particular problems, and instead, simply offer the tools and technologies, and leave developers to use them how they wish. Web standards today is like a “Wizard” dialog in windows, quite effective at solving a very specific problem/task, but where I see web standards needs to do, is towards something more akin to Photoshop, which simply provides the tools, without enforcing particular ways to do things, only making recommendations.

  • Thomas C

    It fits perfectly in the ‘the browser will be the os’ strategy. For some os tasks u have to run native code. I think.

  • Could it be that NaCl would be used to create plugins and addins like Firefox plugins and not client side games?

    I like Chrome. It’s fast and doesn’t crash like it used to but I constantly use:
    – Firebug
    – Web Developer’s Toolbar
    – FireFTP
    – Screengrab
    – Total Validator
    – IE-Tab
    – SEO Book
    – Netcraft Toolbar

    The lack of these plugins prevent me from going to Chrome but if they were available, I might be converted.

  • Could it be that NaCl would be used to create plugins and addins like Firefox plugins and not client side games?

    I suppose it’s possible, but Chrome already has an extensions system. To me, NaCl seems more like ActiveX. It may not have the security issues, but it’s still running as a sand-boxed applet without direct access to the DOM and browser interface (yet).

  • TEwire

    The point that W3C misses is more websites and application aren ext documentsany. HTML, including HTML 5 is not very flexible, it does not adapt to more advanced net’s applying either. Web appendix makes great efforts to compete with desk-top application program forever

  • Craig:

    You may be interested in these related articles:

    Google Chrome is such a big story that, the tech site of The Wall Street Journal, has five stories about the upcoming Google Chrome OS on its homepage today (Thursday, November 19, 2009).

    The titles of two of these articles say much about Google’s plans and self-confidence: “Chrome: The End Of Desktop Apps” and “Google’s Chrome OS: ‘It Just Works.’”

  • Les

    Anything that could or would disrupt web standards and what has been build on that I am against as that is what would lead to a two tier web.

    So, lets show Google what they can do with their “in browser” technology right here, right now. Them -beep- have taken over online search and advertisement and now they want to take over the entire web?

    Would that be possible? Definitely, it’s a grim reality and it has to be stopped.

  • J

    This is just getting plain stupid. You are criticizing everything Google makes, and for idiotic reasons too. You’re saying all this change is bad, when you yell at people using table-based layouts for not changing.

    Sitepoint, I used to always love to read articles here, but you’ve become idiots. Good luck

  • I agree with “J”…

    Enough of the paranoia and idiocy. The article, although inconclusive isn’t bad… It raises so dubious questions and doesn’t provide answers but that in itself isn’t anything new. I’m speaking mostly to the comments with the “hate all that is Google” mentality, especially this comment:

    So, lets show Google what they can do with their “in browser” technology right here, right now. Them -beep- have taken over online search and advertisement and now they want to take over the entire web?

    Why? …Because it’s Google?

    They didn’t take over search… They just do it well. They didn’t take over advertising either. They developed their own online advertising business it to what it is today.

    And besides… Who cares that Potentially, Go could be a good fit for NaCl? You’re going to get bent out of shape because some guy wrote an article on the internet supposing that a tiny web browser with an adoption rate of a fraction of a percentage point might be able to run Applets using a language that others can’t? Really?

  • Sascha

    We have JavaScript and Java for web applications. Why NaCl or Go?

  • Duncan

    The channel/goroutine combination in Go allows relatively clean implementation of concurrent algorithms which distribute naturally across multiple cores. JavaScript has no concurrency support whatsoever and writing synchronisation code in Java is considerably more difficult (and therefore more error prone) than in Go. Goroutines and channels are fairly lightweight and are scheduled onto real threads by the Go runtime. This is in contrast to the operating system threads available to Java, each of which has its own static stack. The Go runtime also handles inter-goroutine dependencies and synchronisation and does deadlock detection.

Get the latest in Front-end, once a week, for free.