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 [email protected]
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. -- You received this message because you are subscribed to the Google Groups "GWT Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
