5 ms·

GWT is still a very viable option for writing JavaScript applications, if not actually the best one. It is one of (or the?) first transpiling tools and very mat

GWT is still a very viable option for writing JavaScript applications, if not actually the best one. It is one of (or the?) first transpiling tools and very mature and feature rich (transparent RPC/serialization, obfuscation/deobfuscation, IDE integrated debugging, i18n, resource bundling, code splitting, JavaScript interoperability, etc.). The author seems to have a bit of a bias (Dart's designers "ate too much Java for breakfast"), but Java is rock solid, and being able to write the entire application, from the client and the domain model on down to the backend, is a major boost. GWT also has a vibrant community (see f.ex. the GWT.create() event across US and Europe: http://gwtcreate.com/ http://gwtcreate.com/) and lots of invention and development going on, with a huge new release (2.7) coming up. See my game project for an example of GWT in action: http://www.webworks.dk/html5engine http://www.webworks.dk/html5engine

cromwellian 12y ago
You can see asmjs vs flash vs GWT vs Dart vs hand-written JS vs JavaVM vs compiled C for Box2D here: https://plus.google.com/111111598146968769323/posts/e2yJn3QAPSQ https://plus.google.com/111111598146968769323/posts/e2yJn3QA... You can see a chart of size and performance here: https://plus.google.com/+BrandonDonnelson/posts/DSUgfWefyR3 https://plus.google.com/+BrandonDonnelson/posts/DSUgfWefyR3 GWT won on size across the board and beat everything but C on performance. Of course, this benchmark, like most, is biased. It uses a lot of polymorphism, and GWT does exceptionally well at removing polymorphic dispatch statically.
- mraleph 12y ago
  > It uses a lot of polymorphism Are you sure? I have never looked at Java implementation of Box2D used in this benchmark, but Dart version is definitely not that polymorphic in its hottest function which corresponds to this Java one: https://github.com/jbox2d/jbox2d/blob/76fa2602a6abcbc557c9d50fc4dce578f4585d40/jbox2d-library/src/main/java/org/jbox2d/dynamics/contacts/ContactSolver.java#L336 https://github.com/jbox2d/jbox2d/blob/76fa2602a6abcbc557c9d5... It looks like mostly a bunch of floating point math to me with not that many calls out. Another interesting thing I noticed now is that Java version has all vector math inlined manually, while in Dart version it is not the case (at least not entirely if I remember correctly - we want to write high level code and let optimizer do what it can).
  - cromwellian 12y ago
    No, I'm not sure. I profiled the hand-written JS function one time and noticed a lot of time spent in polymorphic methods. Also, this coincided with an optimization in GWT to improve hidden class V8 optimizations and speed went up by 300%, so it seemed related to polymorphism. The vector math does look like an apples-to-oranges comparisons. Simple methods like cross-product will inline in GWT as well. The biggie seems to be the elision of the temporary, we'd need something like C++'s return value optimization to get rid of that. I'll try rerunning the bench by adding calls to cross-product to see how it fares. Actually for us, we weren't as interested in comparing the speed to Dart as much as comparing it to the JVM version. The slowdown there is on the order of 50% which isn't bad. In the original thread on G+ I noted there's no way this can be considered an apples-to-apples comparison because they're not running the same code (the port's from Box2D differ), but Joel's whole Box2D benchmark suite kind of rests on this.
    - mraleph 12y ago
      > I'll try rerunning the bench by adding calls to cross-product to see how it fares. btw, if you have a moment I would really appreciate if you tell me how to reproduce +Brandon Donnelson results. It's hard to figure out from those photos which version of GWT should I get from where and what to compile with it. I was not sure if I supposed to check out Joel's code AS IS or I should get it from some other place, etc.
      - cromwellian 12y ago
        It's been a while, but you'll probably need to built a custom version of GWT using this patch (https://gwt-review.googlesource.com/#/c/8590/ https://gwt-review.googlesource.com/#/c/8590/) as we had to roll back the V8 optimization due to a catastrophic performance regression in IE11. Then you'll need my fork of Joel's repository here: https://github.com/cromwellian/bench2d https://github.com/cromwellian/bench2d I'm not sure they were upstreamed into his. Brandon's results were culled from the informal results I posted in Joel's G+ thread (which he independently verified). From the thread you can see I was quite disbelieving myself and not at all ready to plant a flag, I even implemented a verification in the GWT version to ensure that the final resting state of the system converged to what it was supposed to. Some very tiny patches to GWT (adding dummy random unique properties to prototypes, an optimization to HashMap.put/ArrayList.get, etc) have lead to 300-500% speedups in our benchmark server, meanwhile really complex ones actually slowed things down, or did nothing. For example, I added asmjs output to GWT (where possible in method bodies, not a truly strict-check), I also implemented an optimization which auto-converts Java classes to typedarrays where possible, e.g. class Vec3 { float x, y, z; // getters and setters } Would require the class into a bag of static methods and rewrite the field accesses into indexes into a typed array. This turned out not to be a win when benchmarked on Box2D, probably for other reasons. :(
- azakai 12y ago
  The second link only shows perf numbers for some of the options, compared to GWT, but it's clear from the first link - which lacks GWT - that GWT would lose not just to C and the JVM, but also to asm.js, CrossBridge, and PNaCl. Overall GWT is a decent performer, but not near the top. It is however nice that GWT can beat standard JS by a small amount.
  - cromwellian 12y ago
    I lumped Emscripten/Asmjs in with the "C" benchmarks. The JVM verson of JBox2D 2.3 actually performs on par with asmjs (Firefox 27 numbers when this was taken). JVM went from 5ms (jbox2d 2.2) vs (jbox 2.3) 3ms, so that puts the GWT version at about 50% (~6ms). It might be possible to locate a few hot methods and instrument just those with asmjs assertions and see if it has any effect. I don't know how Firefox reacts to something that's "half-way" asmjs (asserts types on math expressions, but still uses objects with fields instead of typedarrays), but FTLJIT and Turbofan are claiming they'll make use of them even in the non-strict case. We'll see. Right now I'm spending most of the my time implementing Java8 lambdas, Promises, and all that good stuff that removes the "tax" of java boilerplate so I don't have much time to explore it, but given how early Turbofan seems to be, waiting might be good anyway.
btown 12y ago
I recall that my first introduction to GWT was Google Wave... sadly, while it was groundbreaking in showing how you could write complex, testable code that ran both in the browser and on the server, Wave wasn't a great showcase for GWT's performance characteristics. Now, with Node.js and its relatively stable module system filling that isomorphic+maintainable gap, it's unclear what GWT brings to the table unless you have reasons to use Java (like a team with a lot of expertise in it, or a legacy codebase, for instance). I'm curious to hear if GWT's compiler can do significant performance optimizations on modern JIT JS engines, as compared to well-written Javascript that follows roughly the same module/class structure.
- cromwellian 12y ago
  There are couple of reasons to use GWT: 1) already attached to Java language and toolchain 2) code sharing with Server, Android, etc (see Google Inbox) 3) Optimized compiles (Closure can also do the same for JS) Modern JIT JS engines do remove the need for most performance optimizations, but GWT and Closure Compiler have never really biased towards runtime performance, they have almost exclusively focused on code size. GWT does do some optimizations that help with performance, but most web apps are not bottlenecked by raw Javascript performance. However for mobile apps in particular, especially those on slow networks all over the world, shipping smaller code will matter for latency, startup time, memory usage, etc. Subjective perception of speed in web browsers is very often a function of DOM complexity, and excessive style recalc, layout, paint. You could reduce the JS execution to zero and still end up with an app that feels laggy as hell. I don't recommend people switch to GWT unless they have a reason to use Java. You can implement a lot of these optimizations on whatever language you like. My philosophy is to use whatever you feel most comfortable in. I'm kind of tired of 2 decades of language wars in the tech community. I work on GWT because I used it for my own startup several years ago and needed to make patches to the project to improve it, and now I just like working on the compiler because it is an interesting problem space. Personally, if I was writing non-Web apps, Rust looks to me like an exciting language. I'm more on the side of "more typing" as opposed to less (Go), and for non-Web apps, I like to work on games, and there, I want absolute best performance. Outside of C/C++, Rust looks to be the best new game in town (ok, I've heard good things about D). Swift, I don't trust as being too proprietary and wedded to Objective-C semantics. Now, I wonder who's going to write a Rust-to-JS compiler? :)

cromwellian 12y ago

You can see asmjs vs flash vs GWT vs Dart vs hand-written JS vs JavaVM vs compiled C for Box2D here: https://plus.google.com/111111598146968769323/posts/e2yJn3QAPSQ https://plus.google.com/111111598146968769323/posts/e2yJn3QA... You can see a chart of size and performance here: https://plus.google.com/+BrandonDonnelson/posts/DSUgfWefyR3 https://plus.google.com/+BrandonDonnelson/posts/DSUgfWefyR3 GWT won on size across the board and beat everything but C on performance. Of course, this benchmark, like most, is biased. It uses a lot of polymorphism, and GWT does exceptionally well at removing polymorphic dispatch statically.

mraleph 12y ago
> It uses a lot of polymorphism Are you sure? I have never looked at Java implementation of Box2D used in this benchmark, but Dart version is definitely not that polymorphic in its hottest function which corresponds to this Java one: https://github.com/jbox2d/jbox2d/blob/76fa2602a6abcbc557c9d50fc4dce578f4585d40/jbox2d-library/src/main/java/org/jbox2d/dynamics/contacts/ContactSolver.java#L336 https://github.com/jbox2d/jbox2d/blob/76fa2602a6abcbc557c9d5... It looks like mostly a bunch of floating point math to me with not that many calls out. Another interesting thing I noticed now is that Java version has all vector math inlined manually, while in Dart version it is not the case (at least not entirely if I remember correctly - we want to write high level code and let optimizer do what it can).
- cromwellian 12y ago
  No, I'm not sure. I profiled the hand-written JS function one time and noticed a lot of time spent in polymorphic methods. Also, this coincided with an optimization in GWT to improve hidden class V8 optimizations and speed went up by 300%, so it seemed related to polymorphism. The vector math does look like an apples-to-oranges comparisons. Simple methods like cross-product will inline in GWT as well. The biggie seems to be the elision of the temporary, we'd need something like C++'s return value optimization to get rid of that. I'll try rerunning the bench by adding calls to cross-product to see how it fares. Actually for us, we weren't as interested in comparing the speed to Dart as much as comparing it to the JVM version. The slowdown there is on the order of 50% which isn't bad. In the original thread on G+ I noted there's no way this can be considered an apples-to-apples comparison because they're not running the same code (the port's from Box2D differ), but Joel's whole Box2D benchmark suite kind of rests on this.
  - mraleph 12y ago
    > I'll try rerunning the bench by adding calls to cross-product to see how it fares. btw, if you have a moment I would really appreciate if you tell me how to reproduce +Brandon Donnelson results. It's hard to figure out from those photos which version of GWT should I get from where and what to compile with it. I was not sure if I supposed to check out Joel's code AS IS or I should get it from some other place, etc.
    - cromwellian 12y ago
      It's been a while, but you'll probably need to built a custom version of GWT using this patch (https://gwt-review.googlesource.com/#/c/8590/ https://gwt-review.googlesource.com/#/c/8590/) as we had to roll back the V8 optimization due to a catastrophic performance regression in IE11. Then you'll need my fork of Joel's repository here: https://github.com/cromwellian/bench2d https://github.com/cromwellian/bench2d I'm not sure they were upstreamed into his. Brandon's results were culled from the informal results I posted in Joel's G+ thread (which he independently verified). From the thread you can see I was quite disbelieving myself and not at all ready to plant a flag, I even implemented a verification in the GWT version to ensure that the final resting state of the system converged to what it was supposed to. Some very tiny patches to GWT (adding dummy random unique properties to prototypes, an optimization to HashMap.put/ArrayList.get, etc) have lead to 300-500% speedups in our benchmark server, meanwhile really complex ones actually slowed things down, or did nothing. For example, I added asmjs output to GWT (where possible in method bodies, not a truly strict-check), I also implemented an optimization which auto-converts Java classes to typedarrays where possible, e.g. class Vec3 { float x, y, z; // getters and setters } Would require the class into a bag of static methods and rewrite the field accesses into indexes into a typed array. This turned out not to be a win when benchmarked on Box2D, probably for other reasons. :(
azakai 12y ago
The second link only shows perf numbers for some of the options, compared to GWT, but it's clear from the first link - which lacks GWT - that GWT would lose not just to C and the JVM, but also to asm.js, CrossBridge, and PNaCl. Overall GWT is a decent performer, but not near the top. It is however nice that GWT can beat standard JS by a small amount.
- cromwellian 12y ago
  I lumped Emscripten/Asmjs in with the "C" benchmarks. The JVM verson of JBox2D 2.3 actually performs on par with asmjs (Firefox 27 numbers when this was taken). JVM went from 5ms (jbox2d 2.2) vs (jbox 2.3) 3ms, so that puts the GWT version at about 50% (~6ms). It might be possible to locate a few hot methods and instrument just those with asmjs assertions and see if it has any effect. I don't know how Firefox reacts to something that's "half-way" asmjs (asserts types on math expressions, but still uses objects with fields instead of typedarrays), but FTLJIT and Turbofan are claiming they'll make use of them even in the non-strict case. We'll see. Right now I'm spending most of the my time implementing Java8 lambdas, Promises, and all that good stuff that removes the "tax" of java boilerplate so I don't have much time to explore it, but given how early Turbofan seems to be, waiting might be good anyway.

btown 12y ago

I recall that my first introduction to GWT was Google Wave... sadly, while it was groundbreaking in showing how you could write complex, testable code that ran both in the browser and on the server, Wave wasn't a great showcase for GWT's performance characteristics. Now, with Node.js and its relatively stable module system filling that isomorphic+maintainable gap, it's unclear what GWT brings to the table unless you have reasons to use Java (like a team with a lot of expertise in it, or a legacy codebase, for instance). I'm curious to hear if GWT's compiler can do significant performance optimizations on modern JIT JS engines, as compared to well-written Javascript that follows roughly the same module/class structure.

cromwellian 12y ago
There are couple of reasons to use GWT: 1) already attached to Java language and toolchain 2) code sharing with Server, Android, etc (see Google Inbox) 3) Optimized compiles (Closure can also do the same for JS) Modern JIT JS engines do remove the need for most performance optimizations, but GWT and Closure Compiler have never really biased towards runtime performance, they have almost exclusively focused on code size. GWT does do some optimizations that help with performance, but most web apps are not bottlenecked by raw Javascript performance. However for mobile apps in particular, especially those on slow networks all over the world, shipping smaller code will matter for latency, startup time, memory usage, etc. Subjective perception of speed in web browsers is very often a function of DOM complexity, and excessive style recalc, layout, paint. You could reduce the JS execution to zero and still end up with an app that feels laggy as hell. I don't recommend people switch to GWT unless they have a reason to use Java. You can implement a lot of these optimizations on whatever language you like. My philosophy is to use whatever you feel most comfortable in. I'm kind of tired of 2 decades of language wars in the tech community. I work on GWT because I used it for my own startup several years ago and needed to make patches to the project to improve it, and now I just like working on the compiler because it is an interesting problem space. Personally, if I was writing non-Web apps, Rust looks to me like an exciting language. I'm more on the side of "more typing" as opposed to less (Go), and for non-Web apps, I like to work on games, and there, I want absolute best performance. Outside of C/C++, Rust looks to be the best new game in town (ok, I've heard good things about D). Swift, I don't trust as being too proprietary and wedded to Objective-C semantics. Now, I wonder who's going to write a Rust-to-JS compiler? :)