3 ms·
I've been building GWT projects like http://beste.st/ http://beste.st/ entirely in Java, so I can share models between my client side code and server side code.
by ajessup 16y ago
I've been building GWT projects like http://beste.st/ http://beste.st/ entirely in Java, so I can share models between my client side code and server side code.
While this way of working is elegant and very powerful, especially when you have lots of shared state and complex server-client interactions, writing everything in Java is quite frankly, a bit of a pain.
This might be a great excuse to finally stop using Java for these sorts of applications and switch to Python.
- squidsoup 16y agoGWT in Scala has made some good progress recently, with parts of the GWT Showcase successfully ported. Unfortunately, the primary developer behind the project is returning to academia, and will have limited time. Hopefully Google GWT devs can get behind this initiative and make Scala a first class citizen. GWT has gone from being a Java to JavaScript compiler and widget set, to a genuine app framework with the 2.1 release. Having Scala as an alternative to Java would go a long way towards attracting new developers to the Google platform. In the future, other JVM language may acquire JRibble backends which would theoretically allow you to write GWT apps in any JVM language. Personally I'm very excited about the prospect of one day writing my GWT apps in JRuby or even Clojure!
- stephen 16y agoI'd love to see Scala/GWT happen as well. Given it's much closer to Java (no new type system, etc.), I think it'd actually be easier to get stab/GWT integration: http://code.google.com/p/stab-language/ http://code.google.com/p/stab-language/ Though that'd also require someone coming along and building a great IDE for stab. As far as writing Javascript apps in JRuby/Clojure via GWT...why use GWT? It's so heavily focused on Java/static type analysis, I'd think you'd be able to make a better/easier Ruby->Javascript translation by just starting anew. The JRuby runtime itself uses reflection/some-day-invokedynamic to shoehorn a dynamic language into a static VM. Besides the fact the JRuby runtime would never get through GWT's no-reflection/nothing-fancy compiler, you're going from ruby dynamic semantics -> Java static semantics -> Javascript dynamic semantics. Seems simpler to skip the static part. Some sort of Ruby's meta class semantics implemented via Javascript's prototype semantics. I imagine the same thing applies with clojure, but I don't know as much about it.