Google Chrome: Why I’m Not Excited

by Gordon. 13 Comments

There is currently a massive amount of buzz around Google’s recently launched browser, Google Chrome. And why not? It’s a new WebKit based browser with a clean minimalist UI and a purportedly super fast V8 Javascript interpreter. To top it off, each webpage executes in its own process and it’s made by Google! It’s the next step in the battle to legitimize web based applications as viable replacements for their desktop counterparts.

Why am I not excited? Adoption rates aside, the big reason is that Chrome’s V8 is not the kind of Javascript engine I would like to see in the next generation of web-browsers. Don’t get me wrong, I fully believe that V8 will be one of the fastest Javascript engines out there, but it’s in its optimizations where the problem lies. When V8 interprets Javascript, it transitions directly from Javascript source code to machine code. There is no intermediate bytecode format! This means that Chrome is designed around Javascript as the be-all end-all language. Chrome isn’t just bad news for Adobe, it’s bad news for developers in general.

In my ideal world, the next generation web-browser will have a generic, standardized bytecode format to which Javascript is compiled, but also such that it will leave the option open for compilers for other languages– a la the good old JVM.  Imagine if you could write the client-side portion of a website using your language of choice, e.g. Ruby, Python, or even Scala (my personal favorite/hobby language). I have high hopes that something like Mozilla and Adobe’s collaborative effort, Tamarin, will turn into this.

As the client-side portion of websites becomes increasingly complex, it also scares me to think that everyone will be monogamously tied to Javascript. Without letting this post turn into a language rant, I am obliged to say that Javascript is in desperate need of better tooling and debugging support; I also feel that Javascript is hard to use and maintain on large, intensive projects, but maybe that’s just me. I realize that the last few sentences sound like cookie-cutter arguments against dynamic languages in general, but I’ll save that for another post.

As of late, as an alternative to Javascript, I have been doing most of my client-side programming in Flash using AS3 and the Flex SDK, not so much for the additional features as for the streamlined development process. AS3 is based on ECMA script, on which Javascript is based as well, but the support for namespaces, optional static typing, and better IDE support (Flex Builder) makes me much more prolific. Let’s also face it: all the major web-browsers are totally dependent on Flash, if not just for serving video, and that’s not going to change any time soon. Google knows this and adds the flash plug-in to Chrome automatically. Ironically, it is Flash and other plug-ins which break Chrome’s pristine process model, since the grandfathered-in plug-in architecture requires less restricted access.

On the bright side however, I have been using Chrome as my default browser for the last couple of days and have had an overall good experience. In terms of UI, it is a nice incremental improvement over other browsers. Combining the search into the address bar more intelligently is extremely convenient and long overdue. I also really like having the tabs on the top of the page.

  • http://www.teamworkcafe.com/ Michal

    I totally agree that JavaScript becoming kind of standard client programming language for the web is bad news for developers. That’s why I’m starting to like Silverlight which does exactly what you’re taling about. There is .NET runtime with MSIL(intermediate language) so you can write silverlight app in c#, vb.net or any other .net language and even in Ruby or Iron Python . That’s a good news for developers! To truly enable rich applications on the web we need replace HTML+AJAX with sometihg more advanced.

    • http://riflethru.com/ dave

      like GWT perhaps?

  • some_random_jerk

    When V8 interprets Javascript, it transitions directly from Javascript source code to machine code. There is no intermediate bytecode format! This means that Chrome is designed around Javascript as the be-all end-all language.

    Hmm… I’m not sure how you’re coming to this conclusion. Anyway, I’m sorry to break it to you but Javascript has pretty much been the de facto standard for client side scripting since the days of Netscape. Chrome has no effect on that one way or the other. It simply makes it faster.

    In my ideal world, the next generation web-browser will have a generic, standardized bytecode format to which Javascript is compiled, but also such that it will leave the option open for compilers for other languages– a la the good old JVM.

    Great idea! Really! That would be really cool. But how do you suppose this would work? Let’s say you have a VM in the browser that runs bytecode. You still need a compiler to create that bytecode. You can’t just decide on a whim that you want to code client side Ruby or something to run in this VM. You need a compiler first and if it’s going to be on the client side it means it needs to be part of the browser. Which languages do you create a compiler for? See? We’re back to square one.

    I suppose you could generate the bytecode server side and the browser just runs that. I’m not sure how I feel about that. It seems less open than what we have now.

  • http://www.teamworkcafe.com/ Michal

    I totally agree that JavaScript becoming kind of standard client programming language for the web is bad news for developers. That's why I'm starting to like Silverlight which does exactly what you're taling about. There is .NET runtime with MSIL(intermediate language) so you can write silverlight app in c#, vb.net or any other .net language and even in Ruby or Iron Python . That's a good news for developers! To truly enable rich applications on the web we need replace HTML+AJAX with sometihg more advanced.

    • http://riflethru.com/ dave

      like GWT perhaps?

  • some_random_jerk

    > When V8 interprets Javascript, it transitions directly from Javascript source code to machine code. There is no intermediate bytecode format! This means that Chrome is designed around Javascript as the be-all end-all language.

    Hmm… I'm not sure how you're coming to this conclusion. Anyway, I'm sorry to break it to you but Javascript has pretty much been the de facto standard for client side scripting since the days of Netscape. Chrome has no effect on that one way or the other. It simply makes it faster.

    >In my ideal world, the next generation web-browser will have a generic, standardized bytecode format to which Javascript is compiled, but also such that it will leave the option open for compilers for other languages– a la the good old JVM.

    Great idea! Really! That would be really cool. But how do you suppose this would work? Let's say you have a VM in the browser that runs bytecode. You still need a compiler to create that bytecode. You can't just decide on a whim that you want to code client side Ruby or something to run in this VM. You need a compiler first and if it's going to be on the client side it means it needs to be part of the browser. Which languages do you create a compiler for? See? We're back to square one.

    I suppose you could generate the bytecode server side and the browser just runs that. I'm not sure how I feel about that. It seems less open than what we have now.

  • Anonymous

    I disagree that a general purpose bytecode engine is key to success. As a language hobbiest, I love the idea. But javascript is “good enough”; and javascript “done right” is a killer feature.

  • jhancock

    I disagree that a general purpose bytecode engine is key to success. As a language hobbiest, I love the idea. But javascript is “good enough”; and javascript “done right” is a killer feature.

  • blasdelf

    You have no idea what you're talking about.

    Chrome is not trying to be the operating system, it's trying to get out of its way. By using a shared-nothing separate process for each tab and plugin, it's letting the Kernel and libc do the job they were designed to do.

    Most modern browsers (especially FF3) are trying to do an operating system's job — scheduling logically independent processes, micro-managing memory allocations, mapping virtual memory, providing an internal windowing system, providing an internal GUI scripting system.

    Chrome does none of these things. It parries them off to the real operating system, where they belong.

  • http://www.brontecapital.blogspot.com John Hempton

    G’day Gordon

    Two things – (a) I am almost certainly related to you, and (b) I blogged about Chrome on my (usually financial) blog…

    http://brontecapital.blogspot.com/2008/09/google-evil-identity-theft-company.html

    Get in touch – and we will chat

  • http://www.brontecapital.blogspot.com John Hempton

    G'day Gordon

    Two things – (a) I am almost certainly related to you, and (b) I blogged about Chrome on my (usually financial) blog…

    http://brontecapital.blogspot.com/2008/09/googl…

    Get in touch – and we will chat

  • guodan
  • Anonymous

    You have no idea what you’re talking about.

    Chrome is not trying to be the operating system, it’s trying to get out of its way. By using a shared-nothing separate process for each tab and plugin, it’s letting the Kernel and libc do the job they were designed to do.

    Most modern browsers (especially FF3) are trying to do an operating system’s job — scheduling logically independent processes, micro-managing memory allocations, mapping virtual memory, providing an internal windowing system, providing an internal GUI scripting system.

    Chrome does none of these things. It parries them off to the real operating system, where they belong.