Comments on: Google Chrome: Why I’m Not Excited http://www.hempton.com/2008/09/google-chrome-why-i%e2%80%99m-not-excited/ Thoughts and rants from a Seattle entrepreneur. Fri, 18 Jun 2010 21:03:03 +0000 hourly 1 http://wordpress.org/?v=3.0 By: guodan http://www.hempton.com/2008/09/google-chrome-why-i%e2%80%99m-not-excited/comment-page-1/#comment-82 guodan Mon, 31 Aug 2009 08:56:43 +0000 http://blog.hempton.com/?p=27#comment-82 <a href="http://www.air-max-shoes.com/Air_Stabb.html" rel="nofollow">Air Stabb</a> <br><a href="http://www.air-max-shoes.com/Nike_Air_Rejuven8.html" rel="nofollow">Nike Air Rejuven8</a> Air Stabb
Nike Air Rejuven8

]]> By: John Hempton http://www.hempton.com/2008/09/google-chrome-why-i%e2%80%99m-not-excited/comment-page-1/#comment-61 John Hempton Sun, 07 Sep 2008 17:24:44 +0000 http://blog.hempton.com/?p=27#comment-61 G'day Gordon<br><br>Two things - (a) I am almost certainly related to you, and (b) I blogged about Chrome on my (usually financial) blog...<br><br><a href="http://brontecapital.blogspot.com/2008/09/google-evil-identity-theft-company.html" rel="nofollow">http://brontecapital.blogspot.com/2008/09/googl...</a><br><br>Get in touch - and we will chat 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

]]> By: dave http://www.hempton.com/2008/09/google-chrome-why-i%e2%80%99m-not-excited/comment-page-1/#comment-58 dave Sat, 06 Sep 2008 12:16:26 +0000 http://blog.hempton.com/?p=27#comment-58 like GWT perhaps? like GWT perhaps?

]]> By: blasdelf http://www.hempton.com/2008/09/google-chrome-why-i%e2%80%99m-not-excited/comment-page-1/#comment-56 blasdelf Thu, 04 Sep 2008 13:34:59 +0000 http://blog.hempton.com/?p=27#comment-56 You have no idea what you're talking about.<br><br>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.<br><br>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.<br><br>Chrome does none of these things. It parries them off to the real operating system, where they belong. 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.

]]> By: jhancock http://www.hempton.com/2008/09/google-chrome-why-i%e2%80%99m-not-excited/comment-page-1/#comment-60 jhancock Thu, 04 Sep 2008 11:50:45 +0000 http://blog.hempton.com/?p=27#comment-60 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. 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.

]]> By: some_random_jerk http://www.hempton.com/2008/09/google-chrome-why-i%e2%80%99m-not-excited/comment-page-1/#comment-59 some_random_jerk Thu, 04 Sep 2008 05:26:06 +0000 http://blog.hempton.com/?p=27#comment-59 > 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.<br><br>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.<br><br>>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.<br><br>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.<br><br>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. > 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.

]]> By: Michal http://www.hempton.com/2008/09/google-chrome-why-i%e2%80%99m-not-excited/comment-page-1/#comment-57 Michal Thu, 04 Sep 2008 04:19:35 +0000 http://blog.hempton.com/?p=27#comment-57 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#, <a href="http://vb.net" rel="nofollow">vb.net</a> 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. 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.

]]>