Google Chrome: "JavaScript Forever!"
,
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.
- Login or register to post comments
- 6578 reads
- Printer-friendly version
(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
noname2 replied on Thu, 2008/09/04 - 5:20pm
in response to: opinali
"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
"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
hannes 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: 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
Zviki Cohen replied on Tue, 2008/09/09 - 7:43am
in response to: 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.