Is there support (planned) for Code Splitting?

[vjay82]

Hi,

code splitting in GWT was really easy by utilising GWT.runAsync(). In j2cl I just found a hint to that topic in the readme regarding the closure compiler. Is splitting applications/the output also supported? Could you give a hint on how to achieve that?

Thank you.

[gkdn]

Code splitting with Closure Compiler is very powerful but not easy. There is no standard solution specialized for J2CL/Java apps at the moment.

You can find some pointers in
https://github.com/google/closure-compiler/wiki/Chunk-output-for-dynamic-loading

Sorry I don't have a great answer for you, that's all I have at the moment.

[ChadKillingsworth]

If j2cl has a well-known method that is used to asynchronously load another file, then I can update the closure-calculate-chunks utility to recognize that load as a split point.

The challenge is that Google utilizes the goog.module system and the rest of the world uses CommonJS or ES Modules.

[vjay82]

@gkdn
Thank you for your answer.
Doesn't the Clojure Compiler require different input files for that? I got the impression by reading that link of yours ( https://github.com/google/closure-compiler/wiki/Chunk-output-for-dynamic-loading ).
But when I now inherit/implement class/interface A (in J2CL) through classes B and C ... to only have one copy of A out there, I would be required to compile everything into one file, or? So how to pipe that into the Clojure Compiler correctly then? Maybe there would be a manual way to achieve things through JS and manually chunk somehow but then A would exist twice, no?

@ChadKillingsworth
Do you mean modifying J2CL? Because the Clojure Compiler seems to understand all those formats. How about a config option? At least the pure Java Guys would be happy with anything (speaking for myself here at least).

With increasing code sizes I think chunking would be a really nice feature.
Just makes me wonder, how amazing the GWT compiler still is in 2023.

[ChadKillingsworth]

One note "Clojure" is a completely separate project. Closure-Compiler is the JavaScript compiler that j2cl targets. That's what we are really discussing.

Closure compiler works by passing it a set of input files and configuration on which output file those files should target. The easiest use (and the default) is all input files are bundled into a single output file. With code splitting however, you target multiple output files. The different output files have a dependency graph between them: for instance every input file will depend on the language polyfills the compiler inserts. The larger and more complex your project, the larger and more complex that output file dependency graph becomes.

Its not enough though to simply split code into separate output files - your JavaScript code has to dynamically load the needed files in your application. This is done via a script or module loader. Since loading scripts or modules is an asynchronous task, code cannot be arbitrarily split. The application has to be aware of such loading points and wait. Modern JS build tools such as rollup, esbuild or even webpack create separate output files wherever they encounter these asynchronous loading points: normally when they see the ES Modules dynamic import statement import('foo').then((ns) => { /* imported module available here */ }); This is also what Closure-Calculate-Chunks uses.

I believe the goog module system utilized by J2CL has an async loader, but I am not very familiar with it. Understanding this would be a prerequisite to updating the Closure-Calculate-Chunks utility and probably the most straightforward way to utilize code-splitting in J2CL projects.