Wednesday, November 25, 2015

Re: GWT3: code splitting

I think the goal was to implement all of those kind of optimizations using the javascript closure compiler.. so dead code elimination and shrinking and code-splitting would all be done by the closure compiler.

I'd guess the GWT code would remain similar, and the output javascript would use closure modules or something to handle the splitting?

On Tuesday, November 24, 2015 at 3:26:13 PM UTC+2, salk31 wrote:
My understanding is that you can pass in parameters (for each permutation) that the compiler/linker can see as constants so optimise away.

I think this is getting less focus in the belief that browsers are getting less quirky and that a mono-culture of GWT is not the way to go so it needs to play nicely with other JS frameworks?

Maybe this makes sense for some GWT users but I think for us, doing a big business app that happens to be a webapp, it will be more of a pain.

On Saturday, November 21, 2015 at 2:27:53 PM UTC, Mars wrote:
when GWT 3 is more targeted to js libs/GUIs, then does it mean, that we will lose all benefits, like code-splitting, different permutations for languages/browsers, etc.?

i.e. as I understand it, even a Polymer component must include all the bloated css/js-quirks for different browsers, right?

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

No comments:

Post a Comment