5 ms·

GWT doesn't mandate MVC, and it is not meant to "hide the Web", it states as such in the original mission statement. GWT is three things: a cross compiler to Ja

GWT doesn't mandate MVC, and it is not meant to "hide the Web", it states as such in the original mission statement. GWT is three things: a cross compiler to Javascript, a development environment, and a bunch of libraries that are layered. GWT != HTML Panel. The naming is unfortunate, GWT really should have been called 'j2js' or some such, to emphasize the fact that its most important function is an optimizing compiler (it is not a transpiler) You can build GWT applications that use nothing but HTML templates, low level jquery-like operations, and avoid all of the high level MVC cruft, in fact, many GWT applications, like Google Flights or Google Shopping Express are built exactly this way. I wish the Widget system had never been layered on top (along with MVP) because it gave people a false sense that it was the only way to use GWT, and it was primarily useful for supporting older browser like IE6. There was a justification of 'hiding' some of the Web when you had to bridge IE6 to modern, and many third party JS libraries took similar approaches at the time. The days of IE6 support were painful and once of the reasons for the success of GWT in enterprise is all of those WinXP IE6 desktops. The primary pain of using GWT these days is the compile times, and the overhead of interacting with Javascript (JSNI). Both of these are being solved in GWT 3.0 along with language boilerplate complaints thanks to Java 8. For example, here is an example of GWT using Polymer components effortlessly https://www.youtube.com/watch?v=wFMD1GXR2Tg https://www.youtube.com/watch?v=wFMD1GXR2Tg GWT 3.0 deprecates the old DevMode and replaces it with a fast incremental compiler. It replaces JSNI with a new @JsType interface. It boils away asynchronous callback boilerplate with auto-conversion of Java8 lambdas to JS functions and vice versa. The new DOM apis will be auto-generated as @JsType interfaces by directly reading W3C IDL specs, not hand-written as they are today. And it will be possible to read JsDoc and TypeScript interfaces and extract API interfaces from them. GWT 3.0 will be about lowering the barriers, the friction, between the Web, JS, Native, and GWT code bases, to make polyglot programming as easy as possible. It will also be about hybrid apps, that are part native, part web. See the new Google Sheets 2.0 as an example, it's Java code cross-compiled via j2objc and married with a native UI on iOS, and cross-compiled with GWT and married to Closure UIs on the Web. I'm endeavoring to make things "and" not "either-or", to give developers as much choice to use as little or as much of GWT as they want. As an example, see AngularGWT, which uses AngularJS 'as is' but lets you write Angular controllers, directives, etc in Java, including using JSR303 BeanValidation to do form validation in Angular. https://github.com/cromwellian/angulargwt https://github.com/cromwellian/angulargwt

xpto123 12y ago
Did you ever saw a GWT application that was not done using the GWT hierarchy of widgets, apart from Google Flights or Google Shopping Express? Because I have seen many GWT apps and I never saw GWT being used that way, I can't see how a very large portion of developers completely misunderstood the right way of using a framework. Usually the full GWT ecosystem is used in order to build enterprise apps: templates in UIBinder, GWT widget hierarchy, MVP frequently not always, Editor often, Request Factory often, etc. You mention that the problem is compilation times, but this is not a problem. In Dev mode there is no need for compilation, the compilation happens in the background in the build server whenever a release is needed. What you describe for GWT 3 seems way more complex that just using plain Html, CSS and Javascript with some framework on top. I don't see how all that complexity of compilers and plugins and dev modes can pull it's weight compared to one 100k js file.
- skybrian 12y ago
  It's true that most GWT apps use Widgets. They aren't going away; we have a lot of code built using them and migrating all that code isn't practical. However, we would like to have more modern alternatives available for building a UI, as Ray has been talking about. The projects I'm familar with use GWT-RPC more than RequestFactory, but otherwise your impression matches mine. Compilation time is an issue because Super Dev Mode runs the compiler (in draft mode).
- cromwellian 12y ago
  >Did you ever saw a GWT application that was not done using the GWT hierarchy of widgets, apart from Google Flights or Google Shopping Express? Fights, Hotels, Shopping Express, Wallet, Google Sheets, Collide, Animatron AFAIK, Angry Birds and most PlayN games, I'm on vacation now, but if I was at my desk could probably did up a lot more Google internal ones. Also look for projects using GwtQuery. >You mention that the problem is compilation times, but this is not a problem. In Dev mode there is no need for compilation, the compilation happens in the background in the build server whenever a release is needed DevMode is going away. The NPAPI APIs we used have been taken from us by the browser vendors. Neither Chrome nor Firefox support the ability of DevMode to run anymore. IE will probably continue to work because of how slow they retire older browser versions and APIs. No mobile browser engine not Mobile IE, not iOS Safari, nor Android browsers, supports DevMode. That is, the very majority of the market has locked down plugin APIs (for good security reasons), which unfortunately means the way GWT was inserting the JVM as a JS bridge during development will no longer work. The new path forward is SourceMaps + Fast incremental draft compilation. As for complexity in GWT 3.0, the idea is you just use HTML and CSS, and any JS you want, and SuperDevMode for any Java. As for how the compiler can justify it's existence, that's primary a question of aesthetics for Java developers who prefer their existing tools, and for people who prefer optimized code.

xpto123 12y ago

Did you ever saw a GWT application that was not done using the GWT hierarchy of widgets, apart from Google Flights or Google Shopping Express? Because I have seen many GWT apps and I never saw GWT being used that way, I can't see how a very large portion of developers completely misunderstood the right way of using a framework. Usually the full GWT ecosystem is used in order to build enterprise apps: templates in UIBinder, GWT widget hierarchy, MVP frequently not always, Editor often, Request Factory often, etc. You mention that the problem is compilation times, but this is not a problem. In Dev mode there is no need for compilation, the compilation happens in the background in the build server whenever a release is needed. What you describe for GWT 3 seems way more complex that just using plain Html, CSS and Javascript with some framework on top. I don't see how all that complexity of compilers and plugins and dev modes can pull it's weight compared to one 100k js file.

skybrian 12y ago
It's true that most GWT apps use Widgets. They aren't going away; we have a lot of code built using them and migrating all that code isn't practical. However, we would like to have more modern alternatives available for building a UI, as Ray has been talking about. The projects I'm familar with use GWT-RPC more than RequestFactory, but otherwise your impression matches mine. Compilation time is an issue because Super Dev Mode runs the compiler (in draft mode).
cromwellian 12y ago
>Did you ever saw a GWT application that was not done using the GWT hierarchy of widgets, apart from Google Flights or Google Shopping Express? Fights, Hotels, Shopping Express, Wallet, Google Sheets, Collide, Animatron AFAIK, Angry Birds and most PlayN games, I'm on vacation now, but if I was at my desk could probably did up a lot more Google internal ones. Also look for projects using GwtQuery. >You mention that the problem is compilation times, but this is not a problem. In Dev mode there is no need for compilation, the compilation happens in the background in the build server whenever a release is needed DevMode is going away. The NPAPI APIs we used have been taken from us by the browser vendors. Neither Chrome nor Firefox support the ability of DevMode to run anymore. IE will probably continue to work because of how slow they retire older browser versions and APIs. No mobile browser engine not Mobile IE, not iOS Safari, nor Android browsers, supports DevMode. That is, the very majority of the market has locked down plugin APIs (for good security reasons), which unfortunately means the way GWT was inserting the JVM as a JS bridge during development will no longer work. The new path forward is SourceMaps + Fast incremental draft compilation. As for complexity in GWT 3.0, the idea is you just use HTML and CSS, and any JS you want, and SuperDevMode for any Java. As for how the compiler can justify it's existence, that's primary a question of aesthetics for Java developers who prefer their existing tools, and for people who prefer optimized code.