Re: GWT Code Splitting: The GWT Stuff and My Core Java Classes

The module system - with code duplication - is not a option for me since even with gzip I will bloat my cellphones traffic volumes beside of the evil wait times in bad coverage areas.
Even if I do not understand why such redundancy in modules is implemented by the JSInterop team, I understand that the split-points may help me.

The reason is that GWT heavily optimizes your code including pruning or unused code. That means if GWT Application A does use a GWT button it will end up in the JS file, but if application B doesn't use a GWT button it won't be in the final JS. Now if you would want to share the GWT button in a common GWT.js file then application B downloads a button it never uses. Basically GWT.js would then need to contain the whole GWT SDK as you never know what an application needs, or the GWT compiler would need to somehow compile application A and B at the same time and analyze which GWT SDK code has been used by either one.

So as you see, while it sounds logical to have a GWT.js file shared across applications it is pretty complicated if you think about code pruning / optimizations. So GWT has decided against it.

 

There - hopefully my last question:
If I define following split-points:

• bootstrap
  contains only some NOOP-code (e.g. a dummy trace to console)
  
• calculation
  my calculation classes
  
• view
  my view classes

Afaik from documentation, this would create the splitting I was asking for. Since with the first bootstrap-splitpoint I will also get the GWT-API code generated, and the other splitpoints shall only have the generated JS code of the wished classes. Or have I some knots in my thoughts?

There is no point in making a nearly empty split point as each split point is also a network request which should be considered slow. Thus to optimize your load times you should think about if its worth it to do an additional 100ms request for downloading 10kb of code instead of just attaching that 10kb of code to some initial download.

Personally I usually use split points on a per menu item (or group of menu items) basis. That means the app frame (overall layout, static menus, logos, etc) and the default view you see when launching the app are not in any split point. Then I have split points for, e.g. a profile menu item, an admin menu item, a chat menu item. Kind of depends how large the code loaded by these menu items is and wether they share code or not. 

During GWT compilation the GWT compiler can generate a compile report showing you the initial download, split points, left overs by passing the -compileReport -extra /path/to/output parameters to the compiler. It also helps analyzing why some code ends up in a fragment you would not expect it to be in.

If my assumption is right. is there a way to control the filenaming of the generated split-points? I could not find anything in the docs about it. 

If there is no common way to control the filenaming, where in the JSInterop api should I take a look for it, to maybe intercept or modify the process of generation?

I think you can but that would require you writing a new GWT linker and that work isn't worth it. You better stick with what GWT gives you as there is a reason why files are named the way they are named. Primary reason is to have an easy caching mechanism. http://www.gwtproject.org/doc/latest/DevGuideCompilingAndDebugging.html#perfect_caching

-- J. 

--
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 https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.