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

[Ramesh S]

Hi, 

I am looking for some help on GWT code splitting. 

I have a very basic gwt - maven project, which have a few model classes (Shape, Circle, Square, etc).

and I use demo.html to load the generated <mymodule>.nocahce.js. 

to pass the inputs and do some computation and get the result back.

Here the nocache.js contains the whole java script of the GWT stuff also my java classes converted to javascript. 

Is it possible to have separate java script file for my java classes. ?

Thanks

[Darko P]

I have a very similar issue.

Let say I want to have two modules

• calculation
• view
  

Now I would like to have:

• one big javascript file containing all arbitrary GWT related javascript code.
  let say GWT.js (which will be the biggest file, I assume somehow 400-500kByte of size)
  
• one calculation.js
  only containing my classes and dependent js transpilations for the calculation (this file shall be probably only a few kByte of size) and of course it depends on GWT.js
  
• one view.js
  only containing my classes and dependent js transpilations for theview  (this file shall be probably also only a few kByte of size) and of course it depends on GWT.js
  

is such a splitting possible? If so how?

[Jens]

GWT only supports code splitting as described in http://www.gwtproject.org/doc/latest/DevGuideCodeSplitting.html

Anything else is not possible.

Also keep in mind that while GWT code splitting allows you to move code into a separate download, it does not mean that you can update that separate download selectively, e.g. only updating your view.js file. You always have to update your full GWT app.

-- J.

[Kirill Prazdnikov]

 Kotlin JS is what you are asking for, it is a modular system.

[Ignacio Baca Moreno-Torres]

This is an exaggerated comment, but... you know that nowadays most of the pages uses various MB on each load, for example just opening apple store downloads 2M, just click ipad goes up to 6M. So... em, hehe codespliting a 1MB uncompressed JS (probably around 300k compressed) which is going to be cached forever is not very good place to dedicate your effort ;). Obviously is just an opinion. But the monolithic approach with the pretty nice unused resources purge algorithm of GWT is even better now than 5 years ago (I remark the 'purger' because you cannot purge if you do not compile the whole app at once). And it even support code splitting if you goes up to various MB of JS.

[Darko P]

I have reviewed the docs again. And still I am unsure if I have modularized the JSInterop / GWT part properly. Why?

as of the example all generic classes are duplicated in the modules. Means if my non-modularized code has a size of about 500kByte I am now getting nearly the same size for each module.
Let say I need to make 10 modules. In this case my codebase will explode to 5MByte of size. I cannot imagine that this is the "modularizing" approach of JSInterop. So I still assume I am doing something wrong.

Can someone clarify?

[Jens]

Can someone clarify?

Each GWT module that has an EntryPoint defined will end up being a GWT application. Each GWT application will contain the code of the GWT SDK that you are using in your app, e.g. a GWT Button, Label, LayoutPanels, etc. So yes if you have 10 small, independent GWT applications (= 10 entry points) and you sum up their final JS size you will end up with a larger total download compared to a single GWT application (= 1 entry point) containing the modules.

So people generally end up using a single GWT application (entry point) and if their app becomes too large they use code splitting so that the app is downloaded in smaller chunks on demand. However some people are also fine with having 10 GWT applications. Server side GZ compression, client side caching and the fact that each of the 10 GWT applications can also use code splitting makes the overhead of duplicated GWT SDK code downloads not that important. With 10 applications you also get benefits like updating them independently from each other.

So again: No you can not have a GWT.js library shared across your GWT modules. You either have to create a single GWT application or multiple GWT applications. A single GWT application will always be smaller than the same application split up into 10 smaller GWT applications because of GWT SDK code duplications. Choose whatever fits best for your use case.

-- J.

[Darko P]

Thank you for your clarification. Now the picture is much clearer to me!

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.

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?

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?

[Jens]

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.