Another downside of DevMode maintenance is all the hacks needed in the codebase around isScript()/@GwtScriptOnly and other magic JVM stuff. There are still lingering bugs in HostedModeClassRewriter around SingleJsoImpls and generics. I agree that there is nothing that works as smoothly and JVM roundtripping, and even if an incremental SDM mode could have equal or superior reload performance, there is still the issue of IDE integration.
On the other hand, for debugging integration with JS, and using GWT code in contexts like Chrome extensions, SDM is a lot nicer. It's also way nicer for stuff like games, where the invocation overhead becomes large for stuff like canvas and webgl. On Sat, Apr 6, 2013 at 5:04 PM, Brian Slesinsky <[email protected]> wrote: > As far as I know, there is no schedule for GWT 3.0, or 2.6 for that > matter. I was thinking perhaps we should continue with smaller maintenance > releases, 2.5.2 and so on. It seems to fit our current working style where > we are making gradual changes, not landing major new features. But arguably > Java 7 support is a big enough step to make it 2.6. > > I have a migration plan for getting Google onto Super Dev Mode and it's my > top priority. Certainly Super Dev Mode performance is an issue and I plan > to tackle that; our largest GWT apps won't be able to use Super Dev Mode > without some significant gains. I've put essentially no work into > performance issues; it's all about compatibility so far. > > Besides running applications, there is also the issue that GWTTestCase > runs in dev mode by default. Production mode is significantly slower to > start, and GWTTestCase is too slow already. That would have to be fixed. > Perhaps our effort to speed up the GWT compiler will bear some fruit here, > and I am thinking about how to implement a Super Test Mode. > > It's unclear how long the migration will take will take. Until that > happens I will continue to make Firefox releases. At some point we may > switch to the Firefox ESR track, or perhaps someone else can take over > making Firefox plugin releases from me. If Firefox actually releases > SourceMap support (and there are some signs of this), then that would make > Super Dev Mode more feasible on Firefox. > > Other than Firefox, "classic" Dev Mode isn't a big support burden so I > don't think we need to be in a hurry to drop it. But if we decide to > support any new browsers, it will only be in Super Dev Mode. > > - Brian > > On Saturday, April 6, 2013 12:17:32 PM UTC-7, John A. Tamplin wrote: > >> On Sat, Apr 6, 2013 at 2:05 PM, Stephen Haberman >> <[email protected]>wrote: >> >>> > For me it would be totally fine to have a plugin for FF15 and then >>> >> > for FF20 and the next for FF25 which would reduce your maintaining >>> > work. Same for Chrome. >>> >>> I hold off on updating FF as well, but I believe a lot of users got >>> antsy about "oh noes! the latest FF isn't supported, GWT is deadz!" >>> before Brian got on top of the FF plugin process. >> >> >> FF clearly wants to get rid of all binary plugins, yet they also have no >> interest in exposing the sort of hooks we would need to use pure-JS >> plugins. Chrome has some issues, but with the fork of WebKit, perhaps the >> identity and performance issues can be addressed -- at least part of the >> reluctance about doing anything more came from the convoluted path from JS >> code to V8. >> >> I know it takes a lot of effort to keep the FF plugins up to date (I did >> it for a while myself), but I think that cost is less than the cost of >> losing a usable DevMode. >> >> >>> Totally agreed. I think that should be our goal--getting to GWT to the >>> point where it can integrate sexily with today's/tomorrow's web >>> developer tool chain (JS debuggers, etc.). >>> >> >> I think the problem is that the technology to make SuperDevMode even >> close to as useful as debugging in the JVM doesn't exist yet, and it's not >> clear when it will exist. I have no problem working towards that goal, but >> in the meantime you can't be talking about ditching what works great now. >> SDM is nice, but it still feels like the limited experience of debugging a >> JS app rather than having the tools available for debugging in the JVM. >> >> -- >> John A. Tamplin >> > -- > -- > http://groups.google.com/group/Google-Web-Toolkit-Contributors > --- > You received this message because you are subscribed to the Google Groups > "Google Web Toolkit Contributors" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "Google Web Toolkit Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
