Earlier quoted context omitted.
I think Google is actually thinking javascript is going to be the base machine language of the browser. They seem to be investing a lot of effort on the V8 engine. http://code.google.com/p/v8/
Why would Google think such a thing when Silverlight has better tech? Why not build a Silverlight competitor?
GWT 2.0
11–20 of 34 posts
Re: GWT 2.0
#12Earlier quoted context omitted.
> What's the point of this Javascript hacking with suboptimal results? Javascript performance has been making huge leaps in the past few years, and Google is helping to drive that further. Plus, penetration is hard. Javascript availability is practically 100% vs. Silverlight's 20%.
It's not just about speed. But even if you focus on speed, Silverlight will always be much faster. Check out this c64 emulator in Silverlight 3: http://channel9.msdn.com/posts/Dan/Honorable-Mention-MIX09-S...
"Silverlight will always be much faster"
Anything to back this up?
Re: GWT 2.0
#13Re: GWT 2.0
#14Earlier quoted context omitted.
It's not just about speed. But even if you focus on speed, Silverlight will always be much faster. Check out this c64 emulator in Silverlight 3: http://channel9.msdn.com/posts/Dan/Honorable-Mention-MIX09-S...
"Silverlight will always be much faster" Anything to back this up?
You can generate faster code with static typing.
Re: GWT 2.0
#15What I think Google should do is build a Silverlight competitor that is open source. What's the point of this Javascript hacking with suboptimal results?
I think Google is actually thinking javascript is going to be the base machine language of the browser. They seem to be investing a lot of effort on the V8 engine. http://code.google.com/p/v8/
Does V8 compile to a bytecode similar to Java? I know that it does JIT compilation to native code and then caches it for future use. If it happens to have a bytecode representation, we could read the Google tealeaves and conclude that Google sees compiled JavaScript as an ugly steppingstone toward a binary representation of client-side code.
Re: GWT 2.0
#16Earlier quoted context omitted.
> What's the point of this Javascript hacking with suboptimal results? Javascript performance has been making huge leaps in the past few years, and Google is helping to drive that further. Plus, penetration is hard. Javascript availability is practically 100% vs. Silverlight's 20%.
It's not just about speed. But even if you focus on speed, Silverlight will always be much faster. Check out this c64 emulator in Silverlight 3: http://channel9.msdn.com/posts/Dan/Honorable-Mention-MIX09-S...
Exactly, it's not just about speed. It's about a lot of things including market penetration, language usage, and speed. By choosing Javascript, Google automatically wins on the first two points and is making Javascript kick ass in the third.
Market penetration is a -huge- aspect of coding in the browser. It's the reason Flash won't die; Adobe is really, really good at pushing the plugin on people. If people can't run your code, your code doesn't matter.
Language usage is important to developers. Javascript has the benefit of having lots of developers already using it, and requiring -nothing but a browser- to get started with it. Adobe has noticed that being developer friendly is really important, and has been making strides with Flex, making Flash development seem more familiar to traditional devs. Silverlight simply doesn't get it (http://silverlight.net/getstarted/). The platform doesn't matter if you don't have programmers building for it.
Speed is important, but only to a point. Of course, Silverlight and Flash both beat the pants off of Javascript for practically every benchmark. The important thing to remember is that Javascript doesn't need to beat them in a test, it simply needs to be fast enough.
You've mentioned that Silverlight's "tech" is better. I'm not sure what that is supposed to mean.
Google's move to push Javascript makes a lot of sense. Building another Silverlight doesn't make much sense when it is failing in every category that actually matters.
Re: GWT 2.0
#17One thing I would be interested in is some experiences in using the some of the JVM languages (Scala, Groovy, Clojure, Jython) with GWT.
Re: GWT 2.0
#18Earlier quoted context omitted.
It's not just about speed. But even if you focus on speed, Silverlight will always be much faster. Check out this c64 emulator in Silverlight 3: http://channel9.msdn.com/posts/Dan/Honorable-Mention-MIX09-S...
Exactly, it's not just about speed. It's about a lot of things including market penetration, language usage, and speed. By choosing Javascript, Google automatically wins on the first two points and is making Javascript kick ass in the third. Market penetration is a -huge- aspect of coding in the browser. It's the reason Flash won't die; Adobe is really, really good at pushing the plugin on people. If people can't run…
You can use all sorts of languages with Silverlight, including Javascript.
Silverlight apps can look just as polished as desktop apps. This is not true with DHTML/Javascript.
Re: GWT 2.0
#19Great Toolkit if you want to/can utilise the Java Tools echo system and everything else that comes with it and with the newer version the UIBinder allows for declarative UI. I personally haven't used the Code Splitting feature but i can see its uses. A common misconception is that it doesn't allow writing direct JavaScript - it actually does.
> Java Tools echo system Took me a while to figure out what the heck this "echo" is.
ecosystem, oops.
Re: GWT 2.0
#20One thing I would be interested in is some experiences in using the some of the JVM languages (Scala, Groovy, Clojure, Jython) with GWT.
Client side or server side? Because GWT compiles directly from Java to JS so you can't compile Scala using GWT to run in browser.