4 ms·

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 s

by 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
  And the SuperDevMode in GWT 3.0, will it be browser-only debugging like the current experimental SuperDevMode? Because if it's browser only, then it would pose a problem for most Java developers, that like you mentioned prefer their existing tools, in this case the IDE-based debugger.
JamesXNelson 12y ago
Note that GWT 3 will see the birth of incremental compiler plus super dev mode, which will actually be FASTER than Dev Mode. I don't know about you, but the dev-mode lag of jumping back and forth between browser and jvm actually makes dev mode painful to use, especially on very large projects that can take many seconds to reload fresh code. As someone who does work a lot on raw js projects using GWT (including Collide, as mentioned by Ray), I can say I'm very happy to see widgets de-emphasized in favor of using html5 features, like web components. When I'm building a view, I rarely care about a widget hierarchy; rather, I just want to construct some html, inject some css, and attach some event listeners. Writing my business logic in java means I can share it with web, android and ios (via j2objc); for that web view, I'm building html, and rarely need the abstractions provided by widgets. If I do need widgets, I usually use a composite with ui binder so I can control the html myself anyway.

by xpto123 12y ago

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
And the SuperDevMode in GWT 3.0, will it be browser-only debugging like the current experimental SuperDevMode? Because if it's browser only, then it would pose a problem for most Java developers, that like you mentioned prefer their existing tools, in this case the IDE-based debugger.

JamesXNelson 12y ago

Note that GWT 3 will see the birth of incremental compiler plus super dev mode, which will actually be FASTER than Dev Mode. I don't know about you, but the dev-mode lag of jumping back and forth between browser and jvm actually makes dev mode painful to use, especially on very large projects that can take many seconds to reload fresh code. As someone who does work a lot on raw js projects using GWT (including Collide, as mentioned by Ray), I can say I'm very happy to see widgets de-emphasized in favor of using html5 features, like web components. When I'm building a view, I rarely care about a widget hierarchy; rather, I just want to construct some html, inject some css, and attach some event listeners. Writing my business logic in java means I can share it with web, android and ios (via j2objc); for that web view, I'm building html, and rarely need the abstractions provided by widgets. If I do need widgets, I usually use a composite with ui binder so I can control the html myself anyway.