GWT 2.0
code.google.comGreat 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.
oops - sorry , my procrastination settings on HN mean that i have to type really fast , meaning no time for proof-reading.
ecosystem, oops.
Yes I have used it a fair bit to write javascript - in some ways it provides the boring bits of stuff around js (like module-like systems, name spaces etc..).
If you like IDEs, IDEA from jetbrains even knows when you are doing inlined JS and assists you as you code.
I thought I would hate GWT by now, but its one of those things that mostly stays out of my way. Would I used it for a new project from scratch? Not sure... maybe. There are lots of other options now for more classic web approaches that dont' require it to be a monolithic ajax app (and jquery is pretty hardened to provide a lot of the glue/lubricant).
One 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.
If you meant server-side , then it really doesn't matter. Its just byte-codes and GWT encourages modular development for client and server-side.
So write your server side in your favourite JVM language and keep your client-side to Java.
Actually, write the server side in any language at all...not just JVM languages! GWT imposes no restrictions on the server side. Using servlets does win you a nice RPC mechanism, but you could use JSON and CPython, if you prefer.
What 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?
> 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.
> Of course, Silverlight and Flash both beat the pants off of Javascript for practically every benchmark.
Last I checked, this is not true.
In my darker days, I spent six months on a contract developing a third party full screen media browser for Windows Media Center Edition. Windows MCE is basically a giant IE window, and your apps are web pages.
The architect benchmarked flash vs javascript at the time, and javascript won hands down for the type of work performed.
Using bubblemark in webkit, I get 58 FPS in flash vs 98 FPS in DHTML.
I wouldn't be surprised if Flash beat Javascript in IE nowadays, but in that case Flash is just faster on some platforms.
Wow ... in bubblemark I get ~60 FPS in Flash, ~90 FPSs in Flash (with cacheAsBitmap) and ~160 FPSs in DHTML (using Chrome). In Firefox 3.0.14 I'm getting 60 FPSs in DHTML, while the speed of Flash is the same.
Chrome's V8 engine is awesome. I never realized it.
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.
> You can use all sorts of languages with Silverlight, including Javascript.
No, you cannot. You can use .Net and language implementations that run on top of .Net. This includes IronRuby (dead?), IronPython, and JScript.
> Silverlight apps can look just as polished as desktop apps. This is not true with DHTML/Javascript.
This is not a feature that consumers care about.
Actually, this isn't true either. Some .NET languages require runtime libraries which are not supported on the Silverlight runtime.
Indeed. From my experience, you must use libraries that are built for Silverlight. You can't use just any old .NET lib in your Silverlight project.
> Silverlight apps can look just as polished as desktop apps. This is not true with DHTML/Javascript.
You should really try MobileMe, or 280slides.
There are a number of other web apps written in Sproutcore and Cappuccino that feel exactly like desktop apps, without an ounce of flash or silverlight.
First time I tried 280slides it was quite sluggish.
Then it works just like my installation of Outlook at work.
"Silverlight will always be much faster"
Anything to back this up?
You can generate faster code with static typing.
Actually, there's a pretty good chance that a good Javascript engine will beat Silverlight (if it doesn't already).
The CLR is not that great. For instance, it can't optimize call-sites of virtual methods ... the JVM does it, Chrome's V8 probably does it too.
And yes, you can use IronPython and IronRuby ... but in case you haven't checked them out ... those are awfully slow (mildly put) compared to the reference or the JVM implementations (go figure).
If you can optimize the call-sites of virtual methods (a problem which isn't solved by static-typing), there's nothing inherent in static typing that guarantees faster code, except the handling of primitives ... numbers mostly, because if numbers are boxed, math is slow. But when you're building a VM from scratch (like what Google is doing with the V8) you can workaround that too (see Lua for a shiny example). Well ... there are other things too, like making classes/interfaces dynamic, but this isn't such a big problem).
What I find interesting about V8 ... even if its designed only for Javascript, the type-system itself is dynamic enough to make V8 a good target for other dynamic languages. And a modified application server could compile something like ...
... to Javascript without much trouble.<script language="ruby"> document.find('div.item').each do |item| item.append("<i>hello world</i>"); end </script>And V8 probably has certain constructs that are executed faster, so you could have a Java to Javascript compiler (like GWT) that uses those static-types that you love to generate faster Javascript.
And with HTML5, you can have your cake and eat it too (assuming Microsoft plays along, or Firefox/Safari/Opera/Chrome become much more popular ... not so hard to imagine given IExplorer's flaws, the army of developers preferring modern browsers and UE's antitrust policies).
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.
Does V8 compile to a bytecode similar to Java?
AFAIK, not any remotely standardized bytecode, no. Of course, there are some data structures in between the strings of characters and the native code, but I don't think there's any talk of guaranteeing anything that would warrant calling them "byte code".
Aside: Lars Bak is the lead developer on V8, and was the lead on HotSpot - http://en.wikipedia.org/wiki/Lars_Bak_(computer_programmer)
Why would Google think such a thing when Silverlight has better tech? Why not build a Silverlight competitor?
Google's Silverlight competitor is HTML 5.
It's called Webkit. And GWT uses it.