6 ms·

GWT 2.0

52 points by TFrancis 17y ago

ivenkys 17y ago
Great 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.
- michaelneale 17y ago
  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).
- nearestneighbor 17y ago
  > Java Tools echo system Took me a while to figure out what the heck this "echo" is.
  - DTrejo 17y ago
    ecosystem, oops.
  - ivenkys 17y ago
    oops - sorry , my procrastination settings on HN mean that i have to type really fast , meaning no time for proof-reading.
amichail 17y ago
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?
- teej 17y ago
  > 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%.
  - amichail 17y ago
    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-Show-Off-Contest-Silverlight-Commodore-64-Emulator/ http://channel9.msdn.com/posts/Dan/Honorable-Mention-MIX09-S...
    - robin_reala 17y ago
      "Silverlight will always be much faster" Anything to back this up?
      - amichail 17y ago
        You can generate faster code with static typing.
        bad_user 17y ago
        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 ... <script language="ruby"> document.find('div.item').each do |item| item.append("<i>hello world</i>"); end </script> ... to Javascript without much trouble. 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).
martythemaniak 17y ago
One thing I would be interested in is some experiences in using the some of the JVM languages (Scala, Groovy, Clojure, Jython) with GWT.
- oconnor0 17y ago
  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.
- ivenkys 17y ago
  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.
  - pohl 17y ago
    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.

52 points by TFrancis 17y ago

Great 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.

michaelneale 17y ago
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).
nearestneighbor 17y ago
> Java Tools echo system Took me a while to figure out what the heck this "echo" is.
- DTrejo 17y ago
  ecosystem, oops.
- ivenkys 17y ago
  oops - sorry , my procrastination settings on HN mean that i have to type really fast , meaning no time for proof-reading.

amichail 17y ago

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?

teej 17y ago
> 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%.
- amichail 17y ago
  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-Show-Off-Contest-Silverlight-Commodore-64-Emulator/ http://channel9.msdn.com/posts/Dan/Honorable-Mention-MIX09-S...
  - robin_reala 17y ago
    "Silverlight will always be much faster" Anything to back this up?
    - amichail 17y ago
      You can generate faster code with static typing.
      - bad_user 17y ago
        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 ... <script language="ruby"> document.find('div.item').each do |item| item.append("<i>hello world</i>"); end </script> ... to Javascript without much trouble. 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).

martythemaniak 17y ago

One thing I would be interested in is some experiences in using the some of the JVM languages (Scala, Groovy, Clojure, Jython) with GWT.

oconnor0 17y ago
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.
ivenkys 17y ago
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.
- pohl 17y ago
  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.