He is a entrepreneur and a software architect from Tel Aviv, Israel. He is also a technology freak with about 20 years experience working with computers. He is currently working on his first private initiative in the area of software development tools. His vision is to maximize the abilities of software developers by providing pragmatic tools that enable them to get fast results. Zviki has posted 36 posts at DZone. You can read more from them at their website. View Full User Profile

Google Chrome: "JavaScript Forever!"

09.04.2008
| 13334 views |
  • submit to reddit
It seems like every possible blogger wrote something about Google Chrome, so why should I be different? I'm looking at it from the developer perspective. I mean, the technical side, the process separation and JavaScript engine, is really what's interesting here. UI wise, it looks a lot like a bunch of features form other browsers, which is surprising considered Google stated it is trying to do "something else". It is possible to do "something else": check out the latest videos from Mozilla labs for some examples.

Google wants your JavaScript web applications to run fast, stable and secure and to feel much like desktop applications. You achieve that by downloading a different runtime engine (you can call it browser, but that name is totally obsolete). That sounds like the next generation RIA technologies: Microsoft Silverlight, Adobe Flash/Air and Sun's JavaFX. Google are sending a clear message: "we have a lot riding on JavaScript and we're not looking for a replacement anytime soon". 

The main differentiator between JavaScript and other RIA technologies will be reduced to the visual complexity. Google are separating themselves from the herd by sticking with the clear and functional design approach. IMHO, it is a matter of personal preference. However, I will not be surprised to find future GWT releases providing more visual enhancements out of the box. GWT can walk hand in hand with Chrome and we might expect future releases of GWT to be "Chrome optimized".

Silverlight/AIR/JavaFX can coexist with Chrome/JavaScript, but they have to be justified. This justification just became that much harder.

From http://blog.zvikico.com/

Published at DZone with permission of its author, Zviki Cohen.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Osvaldo Doederlein replied on Thu, 2008/09/04 - 9:48am

Google will obviously keep all their stuff - from GMail to GWT - compatible with all browsers. But their JavaScript-heavy apps will run much faster on Chrome, and perhaps also Firefox's upcoming Tamarin, or other browsers that join the race for high-performance JS runtimes... it's a win-win race for Google:

- If market leaders (MSIE) drag their feet in JS speed, they will keep losing market share to Chrome and other competing browsers.

- But if they compete, eventually all browsers will run JS very fast - and all other RIA platforms will lose as result.

Check http://groups.google.com/group/strongtalk-general/topics for some interesting posts on V8 (StrongTalk is a strongly-typed, high performance variant of Smalltalk). V8 is written by some of the same Self and Animorphics hackers who designed HotSpot. Most impressive is the fact that V8 is in a very early stage, compared to a mature optimizing VM like HotSpot. It's missing a ton of important tricks, like advanced IR optimizations. V8 humiliates other JS engines, but that's partially because all other JS runtimes suck ass. But they have the architecture to go MUCH farther. I think in a couple years, V8 may be competing with Java at least for dynamic code, e.g. V8+Javascript ~= HotSpot+Rhino+Javascript or HotSpot+JRuby, etc. Of course the JVM will always be faster for code written in "lower-level" languages (static-typed, class-based, primitive types...) like Java. But if the current trend towards dynamic languages continues, this is irrelevant. Good for me that I don't do any client-side development, because I despise dynamic languages in general and JavaScript in particular; in my POV, progress is something like Scala, not Javascript. Well, but that's just me, other people have different tastes, for example Bear Grylls eats worms... ;-)

On the multi-process model, see my opinion here: https://www.blogger.com/comment.g?blogID=20975090&postID=5118564676598909305&pli=1. In short I think Chrome is on the right track. This is an important trend, see for example Sun's new Java PlugIn which runs the JVM in a separate process from the browser, which results in multiple advantages.

Casper Bang replied on Thu, 2008/09/04 - 11:29am

I think you are right. Google is well underway of undermining the RIA market, just as I thought JavaFX's fight to the top couldn't get any harder, this happens. My my, it shall be an interesting battle over the next few years.

noname2 noname replied on Thu, 2008/09/04 - 5:20pm in response to: Osvaldo Doederlein

"V8 humiliates other JS engines, but that's partially because all other JS runtimes suck ass."

This is based on what? Tracemonkey is currently the fastest Javascript engine, faster than V8. Firefox 3.1 will have it.

"Of course the JVM will always be faster for code written in "lower-level" languages (static-typed, class-based, primitive types...) like Java."

And this claim is based on what? I suggest you read some research about tracing and JITs etc.

 

Osvaldo Doederlein replied on Thu, 2008/09/04 - 8:36pm in response to: noname2 noname

"Tracemonkey is currently the fastest Javascript engine, faster than V8. Firefox 3.1 will have it."

Sorry, all recent JS benchmarks that I saw (incuding independent ones) didn't include Tracemonkey, so I just though it was still too early in development. Now I found Brendan's blog with Mozilla's answer to Chrome's benchmarks. Good stuff, since I've been a Mozilla browser user since it was barely usable.

I hope FF3.1's development cycle is quick... one nice thing in FF's JavaScript support is its attempt to evolve the language (JS 1.8).

"And this claim is based on what? I suggest you read some research about tracing and JITs etc."

I've been doing that kind of research since JDK1.1, thanks. And I stand back this claim very comfortably. Today, dynamic-typed languages force compilers and runtimes to do an insane amount of extra work for stupid, trivial things like adding two integers without a monster overhead. And yes, I've been tracking very closely all progress in this area too. Still, there's no magic. Even Java, which performance is highly competitive with C/C++ for most apps, shows important tradeoffs (memory footprint) and is still smoked in specific scenarios - low-level algorithms that depend on things from unsigned ints to unchecked arrays to SIMD libraries / extensions. Wake me up when you have, say, a good software MPEG decoder written in JavaScript. I'll be happy enough with one that competes with a pure-Java decoder, not with a native or GPU-accelerated one. (I'm not saying that this is not possible - I'm just saying the state of the art compiler technology is not there yet, and won't be there any time soon.)

Rainer Eschen replied on Sat, 2008/09/06 - 12:18pm

Well, I can't recognize that a faster implementation of Javascript will help the most important problem with browser frontend development: The ergnonmics of the presentation. Flex is still the best answer to this ;-).

hannes ficker replied on Mon, 2008/09/08 - 4:31am

Somewhat off-topic, but:

Why do people keep spelling Javascript "JavaScript"? AFAIK, Javascript's name is "Javascript", not "Java Script" or "Java-Script" (for a good reason, I think), so there is no reason to spell it using CamelCase, is there?

 No offense + sorry for being picky, I simply think it's wrong and keep wondering why you see it so very often in textes as well as in APIs....

Osvaldo Doederlein replied on Mon, 2008/09/08 - 7:41am

@Rainer: A high-perf Javascript could be critical for "pure-Web RIA apps" when combined to other developments, like Canvas and SVG support. For example, check the Canvascape demo. The performance delta from Firefox 3.0.1 to Google Chrome (and probably FF3.1/TraceMonkey too) is VERY noticeable; on Chome, it seems to be as fast as the browser's refresh cycle, not bound by JS code anymore. On a T7250 dual-core CPU, FF uses ~50% CPU (i.e. saturates one core) while Chrome won't go above 20%. Based on this test, I'd say that a full port of Wolfenstein3D (or even a more advanced shooter) is already possible in that platform... and also, of course, most 'flashy' apps out there. ;-)

Rainer Eschen replied on Mon, 2008/09/08 - 1:01pm in response to: hannes ficker

[quote=asdfasdf]

Somewhat off-topic, but:

Why do people keep spelling Javascript "JavaScript"? AFAIK, Javascript's name is "Javascript", not "Java Script" or "Java-Script" (for a good reason, I think), so there is no reason to spell it using CamelCase, is there?

[/quote]

I think the Trademark is written JavaScript, to tell the people that there was something comparable to Java. Well, the old Netscape 2.0 days. Over the time the most people skipped the camelcase for easier writing. Today, both are used ;-).  

Springsteam Blog - Next Generation Java Development

Rainer Eschen replied on Mon, 2008/09/08 - 1:05pm

@Osvaldo No discussion about that. But, I talked about real dektop presentation. This is the pure flex based on flash programming side. It makes no sense to me to use Javascript/DHTML in Flex. Nice feature, but useless when you already use a Java JSF, etc.

Zviki Cohen replied on Tue, 2008/09/09 - 7:43am in response to: hannes ficker

[quote=asdfasdf]

Somewhat off-topic, but:

Why do people keep spelling Javascript "JavaScript"? AFAIK, Javascript's name is "Javascript", not "Java Script" or "Java-Script" (for a good reason, I think), so there is no reason to spell it using CamelCase, is there?

[/quote]

 I'm curious: do you have anything substantial to support this claim?

Take a look at the Wikepedia entry (not that it's a definitive source) - JavaScript is a trademark registered by Sun. On their Trademark Page it appears as JavaScript. Even in Mozilla's official JavaScript reference, it appears as JavaScript.

Deon Snider replied on Sat, 2011/10/08 - 3:40am

wholesale management software from SIMMS Software is the heart of the integrated supply chain management system. Designed with the distribution executive in mind, our distribution Inventory wholesale management software is a powerful and modern sales and logistics system which incorporates the latest concepts and business processes.

Deon Snider replied on Fri, 2012/06/08 - 7:09am

It seems like every possible blogger wrote something about Google Chrome, so why should I be different. I'm looking at it from the developer perspective. I mean, the technical side, the process separation and JavaScript engine, is really what's interesting here. UI wise, it looks a lot like a bunch of features form other browsers, which is surprising considered Google stated it is trying to do "something else". It is possible to do "something else": check out the latest videos from Mozilla labs for some examples. Denny Yum`s Chinese N Sub

Deon Snider replied on Sun, 2013/05/12 - 3:40pm

 Always looking for a power outlet for your power hungry mobile devices? Have the peace of mind that you will never run out of battery power wherever you are. Our selection of battery packs - power banks, battery cases, external batteries - have been carefully selected to offer you the most versatile power solution on the go.

External Battery Travel Charger

Deon Snider replied on Thu, 2013/08/15 - 11:45pm

For a more Siri-like experience in the browser, the Speech API supported in Chrome starting with version 25 adds to the browsers previously existing support for HTML Speech Input standard introduced in version 11. Unlike HTML5 Speech Input, the new API enables scripted speech output and user input for forms, dictation, and device control. ecift 

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.