Re: Exposing GWT components based on Elemental2 to TypeScript ?

There is a nearly-gwt3-ready vue-gwt library at https://github.com/Axellience/vue-gwt if you'd like to see how that could feel - knowing the author, he wouldn't mind feedback, or even a competing implementation to try thinking differently if you have another direction to try.

Personally, while the templating seems interesting to me (as long as design goals are specified up front, to avoid turning into "oh, its just HTML, with code in it!" like JSP...), the routing and "state" management seems a bit off for my tastes. I'm not prepared to defend this opinion too vigorously though, I have more research to do.

Updated MVP tools will be important, and a few people talked about prototypes in varying stages of completion at the conference, many already using current best practices.

Remember, GWT's architecture is mostly just "maintain a great compiler" - the widgets and other tools mostly came about as a way to deal with the horrible mess that browsers were up until the last 1-3 years. The coming reorganization that will push the "user" library out into their own separate dependencies will help make this clearer to users - using GWT does not mean using Places, or RequestBuilder, or Widget.

--

  Colin Alworth

  colin@colinalworth.com

On Fri, Oct 13, 2017, at 09:44 AM, David wrote:

Yes indeed, JsInterop and Elemental2 are really the building stones of what we can do in the future. So there is already a lot that can be done before J2CL is released and integrated. 

I think it is a good idea that all the components that might be migrated are indeed modernized. When I see how templating or routing is done in Vue.js/React I wonder if GWT should not completely revisit its architecture.

 

On Fri, Oct 13, 2017 at 3:23 PM Colin wrote:

The other aspect is the rest of the ecosystem - what is GWT without Widget/elemental/errai, without the various mvp/c tools, etc?

JsInterop works in J2CL, in nearly exactly the same way as GWT2. All existing JRE emulation in GWT2 also already works. From here, we can start building tools, starting with elemental2, and GWT-compatible annotation processors (like dagger2 instead of Gin).

The work that remains is not just making J2CL and the Closure compiler into a complete set of tooling (which works not only from the command line, but from the supported build tools and IDEs, with all of the expected sourcemap support, etc), but also in making sure that once those tools are ready, that other pieces are ready too. Some aspects of GWT2 like Activities, and the EventBus, are already compatible (though Thomas Broyer went ahead and modernized Event/EventBus further, as may be appropriate for other components), while others like animations, editors, uibinder, rpc, validation, internationalization, etc are all still in varying states of migration to JsInterop and annotation processors, most unstarted.

Some of these are harder than others - I am inventorying work already done and trying to get a very rough outline of remaining work to do, and hope to publish this in about a week. Fnding owners for each unit of work will be important, at least for any tool we hope to still use in GWT3.

On Wednesday, October 11, 2017 at 4:13:12 AM UTC-5, Thomas Broyer wrote:

On Wednesday, October 11, 2017 at 10:43:06 AM UTC+2, DavidN wrote:

Is there any tentative release date for j2cl ? I was not present at the GWTCon, maybe it was mentioned there ? Or is it the typical "It will be released when it is ready" approach ?

It's a Google project, so we'd have to ask Google. But the idea was that it'd be opensourced once it's more stable and really usable; and there's work needed on the build: the build files are currently Blaze-specific (Google's internal build system), and either they'd have to make them Bazel-compatible, or someone else would have to come up with another build tool (Maven or Gradle); and after building it, there's the question of distributing it (into Maven repos), which also somewhat depends on the build tool. The idea is that it shouldn't generate too much frustration for all of you (and us) who are eagerly waiting for it, so it cannot just be a "code drop" that you couldn't even build and run.