Re: [gwt-contrib] Re: future of jvm dev mode
Synchronous communication is the deal-breaker. Browser vendors really don't like synchronous I/O (because it makes the UI hang) so they're trying to get rid of it. The closest thing might be a remote debugging API, but we would also need it to be reentrant due to calls from JavaScript to Java and back again. And if you take over the debugging API it's pretty hard to debug. On Tue, Apr 16, 2013 at 12:10 AM, Leif Åstrand wrote: > I think sticking to ESR releases of Firefox could be a good approach for > keeping up with the release schedules. Even though it's not 100% trivial to > set up a system where you run the release channel and ESR at the same time, > it is still quite manageable and you only need to do it once. > > I do also believe that we are approaching the moment where it would be > possible to do JVM dev mode without a plugin in the browser. My experiment > at https://github.com/Legioth/devmodejs shows that there are only two > essential features missing from Firefox: Weak references ( > http://wiki.ecmascript.org/doku.php?id=strawman:weak_references) to > enable garbage collection in the JVM and some way of doing synchronous > websocket communication (or some other synchronous communication method > that does not require a new HTTP request for each round trip). > > -- > -- > 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. > 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
I think sticking to ESR releases of Firefox could be a good approach for keeping up with the release schedules. Even though it's not 100% trivial to set up a system where you run the release channel and ESR at the same time, it is still quite manageable and you only need to do it once. I do also believe that we are approaching the moment where it would be possible to do JVM dev mode without a plugin in the browser. My experiment at https://github.com/Legioth/devmodejs shows that there are only two essential features missing from Firefox: Weak references (http://wiki.ecmascript.org/doku.php?id=strawman:weak_references) to enable garbage collection in the JVM and some way of doing synchronous websocket communication (or some other synchronous communication method that does not require a new HTTP request for each round trip). -- -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
On Mon, Apr 15, 2013 at 8:48 PM, Ray Cromwell wrote: > Another downside of DevMode maintenance is all the hacks needed in the > codebase around isScript()/@GwtScriptOnly and other magic JVM stuff. > Many of those hacks are there for both performance and debugging (ie, where the JS version is a more complicated implementation to get decent performance when compiled to JS), and not all of them are just because of slow boundary crossings. So, I suspect by doing away with them you would simply make everything slower. > 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. > So it sounds like they each have their place. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
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 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 >> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. > 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 google-web-toolkit-contributors+unsubscr...@goo
Re: [gwt-contrib] Re: future of jvm dev mode
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 > > > 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
On Sat, Apr 6, 2013 at 2:05 PM, Stephen Haberman 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: future of jvm dev mode
> Hm maybe our app isn't large enough (~150 KLOC and growing) but we > found DevMode to work pretty well in Firefox. Reloading the app is a > matter of seconds and if you restart FireFox from time to time you > can workaround the current memory leak. Agreed, that is how I use it now. > 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. > So before you deprecate the current DevMode you should proof to > everyone that you have something new that works equally well or > better than the current DevMode. This is a very good point. I have random assertions that "hey, it will be awesome!" but that doesn't say much. I have a very (very) small spike that I can go back and revisit, and hopefully soon share, but it will take more help than just me. Maybe we could get a provisional "*if* the prototype works well, then maybe GWT 3.0 (whenever that is) drops DevMode". > I was really impressed and if something like that would be possible > with GWT..well..then GWT will be sexy again. 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.). - Stephen -- -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: future of jvm dev mode
Hm maybe our app isn't large enough (~150 KLOC and growing) but we found DevMode to work pretty well in Firefox. Reloading the app is a matter of seconds and if you restart FireFox from time to time you can workaround the current memory leak. Of course maintaining DevMode plugins is annoying but honestly I think we don't need a DevMode plugin for every new browser version, especially if new browser versions are released every month. 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. Also I was super exited about SDM but once it has been released I was pretty disappointed about its performance. Our app recompiles in ~35 seconds which means its pretty useless to us (except for mobile development where you dont have DevMode). It seems like it heavily depends on caching and as soon as you have 3rd party GWT libs or even GWT proper features that do not use incremental generators you really slow down SDM. Not to mention that debugging inside the browser is really annoying compared to what you get using any IDE. So before you deprecate the current DevMode you should proof to everyone that you have something new that works equally well or better than the current DevMode. As long as you dont have that, you should not treat the current, (for a lot of people) well working DevMode as deprecated. Nowadays I would never say that GWT 3.0 will not have the current DevMode on board as you simply don't know how browsers evolve and how well your ideas work out for a new dev mode. It might be very likely that GWT 3.0 still needs the current DevMode because there is still no viable alternative. Side note: A few days back I tried IntelliJ's/PhpStorm's LiveEdit feature for HTML/PHP/CSS/JS development along with its ability to connect to Chrome/Firefox for remote JS debugging. I was really impressed and if something like that would be possible with GWT..well..then GWT will be sexy again. If you haven't tried it.. try it! -- J. -- -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
