It is "slow/laggy" because the hosted mode is compiling to JS on the fly and therefore will be slow as it reads the GWT compiler reads the source and generates the required JS etc... this is one of the trade offs to allow for incremental compile (ie you just have to change source and re-fresh the browser) and debug support (meaning you can step through java code as it is rendered to the browser).
The buggy (resize issues) is a GWT embedded browser issue - that is the way it is and Google need to resolve that.
Google is in the throws of developing a plug-in for standard browsers (OOPHM) that will allow native execution in FF, IE or WebKit (Safari) that will allow hosted mode but let you use your favorite browser to view/test.
Ok. That sounds reasonable. But, say I'm just dragging a window around.. After the compilation into JS, shouldn't it eventually start getting fast? It doesn't have to constantly recompile the same thing?
After the compilation into JS, shouldn't it eventually start getting fast? It doesn't have to constantly recompile the same thing?
Nope. It compiles/interprets from Java source to JS line by line whilst in hosted mode. This is how it can debug and do other neat tricks. Remembering that hosted mode is purely a developer tool and is used to validate/test not verify performance.
Every now and then you would compile to native JS to verify correct browser operations and get a feel for performance - knowing that everything runs faster native than in hosted mode.
yes and no - as its being compiled/interpreted in realtime, the size of the code being executed will impact the lag/delay - something really complex (like dragging or opening a big render) will show whereas something simple (like clicking a button) will not show any noticable delay.