Re: Suggesting a new mode: instant in-place changes of GWT Javascript code?

97 views
Skip to first unread message

Paul Robinson

unread,
Aug 2, 2012, 8:58:53 AM8/2/12
to google-we...@googlegroups.com
Search for "super dev mode". It's available now in GWT 2.5RC1

Paul

On 01/08/12 15:23, Dieter K wrote:
> Dear all,
>
> This is hopefully starting a discussion that results in a GWT feature request. Maybe/probably this was suggested before and is currently in the works or it was rejected -- then I would like to learn about the reasons.
>
> Ok, here it goes:
>
> We have the 'development mode', which allows us to make changes to the Java code and review while the application while running. Still it is horribly slow, especially for things like graphics where one often prefers to directly use production mode -- even though the compilation step is equally time-consuming. I want to suggest a new 'mode' that fuses the instant code changes of 'development mode' with the speed of 'production mode'.
>
> The Eclipse Java compiler is able to perform an 'instant and continuous in-place modification' of the Java byte-code while the users edits the Java sources. It does not re-compile everything, just the changed part in a single .class file. I think this concept should be easily transferable to the GWT Javascript compiler. The GWT Javascript compiler doesn't have to be able to modify any kind of JS code in-place -- just the code it generated itself. Maybe one could even 'decorate' the generated JS or split it up in several files to make this atomic in-place modification easier to implement. The in-place modifiable JS does look anything like the JS generated for the GWT 'production mode'. Still, it is valid JS.
>
> Most of a GWT projects code is contained in several unmodifiable jar files. There is only a small amount of Java-source code that can be actively edited. It should be quite easy and performant to build a model that allows in-place modifications of the generated JS in real-time while the user edits the Java sources. A browser refresh could be done at any point since the JS is always up-to-date.
>
>
> Cheers,
> Dieter
>

Dieter K

unread,
Aug 3, 2012, 2:42:35 PM8/3/12
to google-we...@googlegroups.com
I read https://developers.google.com/web-toolkit/articles/superdevmode -- I am not sure if this is 100% what I had in mind but it is progress. At least we are directly using Javascript. Anybody knows how long this recompilation-step takes? I was hoping for an instant refresh by modifying JS in-place...but maybe for some reason it is not technically possible.

Jens

unread,
Aug 3, 2012, 3:36:57 PM8/3/12
to google-we...@googlegroups.com
I read https://developers.google.com/web-toolkit/articles/superdevmode -- I am not sure if this is 100% what I had in mind but it is progress. At least we are directly using Javascript. Anybody knows how long this recompilation-step takes? I was hoping for an instant refresh by modifying JS in-place...but maybe for some reason it is not technically possible.

Googles design goal was less then 10 seconds for nearly all projects (unless they are really really really big). But currently it seems like there are issues with some GWT code generators that can cause compilation to take longer than that. For some numbers take a look at the discussion: https://groups.google.com/d/topic/google-web-toolkit-contributors/RApHAZBy348/discussion

Jens

unread,
Aug 3, 2012, 3:40:47 PM8/3/12
to google-we...@googlegroups.com
In general, if you can modularize your app into fairly small "development modules" you can get pretty good results with SuperDevMode when only developing on a single small module and not on entire application.

-- J.

Dieter K

unread,
Aug 10, 2012, 1:05:38 PM8/10/12
to google-we...@googlegroups.com
I don't understand why it cannot be instant-JS-in-place modification? JS seems to be much more predestined for in-place modification the Java Bytecode, still the Eclipse compile can to it instantly. 
Maybe one would have to change some parts and allow only a subset of GWT functionality, still an instant deploy experience would be so much better.
Reply all
Reply to author
Forward
0 new messages