On Monday, October 24, 2016 at 3:55:47 AM UTC+2, Brandon Donnelson wrote: > > I like the sounds on this, although my initial thoughts feel like it's > another layer. But I also know typically it takes me a bit longer to warm > up to new approaches. I have trying to think how I can cut the code server > out of the loop. > > So I've been wondering if I could start the gwt super dev mode compile, > provide the user agent in the args, so the code server isn't needed. Then > compile the initial compile into the web app directory. Skip the working > directory, skip a temp directory, do it into the web app. There would be no > need for injection, b/c it'd be acting like the real web app, minus the > optimizations and multi permutation builds. So in that same process, listen > for changes to the app, and then recompile after the change, or based on a > trigger, like a change in file. >
That'd be entirely possible yes (might require duplicating large portions of CodeServer if you want to do it "externally", but could be baked into GWT proper yes). Webpack actually comes with both a "watch mode" and a devserver (which, in the case of Webpack, actually wraps the "watch mode", it does not compile on-demand like GWT's SDM); each has its use IMO, they're not mutually exclusive. The devserver has the advantage that you can proxy to a live server on another machine without even touching that machine, or you can serve static files from a local directory without writing to that directory and messing with either an existing production compile, your SCM, or your build (e.g. a *.nocache.js from src/main/webapp overwriting the production compilation in target/, or your build skipping GWT compilation because it thinks it's up-to-date and you end up packaging and deploying a stub nocache.js). Webpack's devserver can also inject a "live reload" script (which the GWT devserver could possibly do too, if it also watched the input files) so the webpage is automatically refreshed whenever a change is detected. The "watch mode" is great if you're OK with writing directly to the webapp, or you can configure the webapp to load the GWT module from another directory (this is what I do currently in my gwt-maven-archetypes). With the devserver, you can actually debug with a production server and quickly test changes to the code; like we used to be able to with the legacy DevMode in -noserver mode (even though we were deploying some code that allowed the "devmode" to be triggered, which is why you had to whitelist your server in the browser plugin settings when doing so), and we can do with the SDM bookmarklets when you're able to use them (i.e. you only have permutations around the user.agent and locale properties). BTW, the devserver approach also works around the HTTPS limitations of SDM, as it proxies everything through HTTP (and on localhost so you can safely use APIs that require a "secure context"). That said, HTTPS could be added to CodeServer (and the devserver, for use by other devices/VMs not on localhost) relatively easily. Actually, GWT already watches files to update its internal PathPrefixSet and avoid a full re-scan of the classpath. I wonder what the cost would be to do the same thing in another class (hopefully the JVM or the OS would share resources when watching the same folder or file twice), or if it could be possible to reuse the ResourceAccumulatorManager (but there's currently no callback to trigger anything on change). The thing is, a GWT compilation still is rather costly even with all optimisations disabled, so I'm not sure triggering a compile on file change is a good thing. > Here's how Eclipse web tools platform could take advantage of that. > Compile into a web app directory, when ever contents are added or changed > in that directory it refreshes the server and if you refresh the web page, > the contents get loaded. > My understanding is that this is how GWT 3.0 with J2Cl would work, because J2Cl is "only" a transpiler that can work at the file level, without knowledge of the whole classpath (I can be wrong on that last bit though). > Do you think we could get rid of the any additional web server (code > server) and push the bits into the web app directory, or some directory we > could push to the web app server? The arguments needed for the compiler > could be provided in the program args, and changes could trigger the > recompile. > As said above, technically, yes, we could. This is not mutually exclusive with a devserver though, and/but might prove too costly at runtime compared to the current "compile on-demand" approach. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/b57a8086-d493-4da5-a1ad-155e8b84f16e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
