Question

In GWT-land, what is the relationship between “linkers” and DFN code splitting? Why does a linker need to support codesplitting, and why do some linkers not support it? How do you choose which linker your app should use and what factors go into that decision?

Answer 1

The primary linker (there also are secondary linkers, but they’re not involved here) is responsible for creating the *.js or *.html files that host the compiled JS code, and of course how to bootstrap/load them into the browser.

Once you know that, it becomes obvious that they have to explicitly support code-splitting.

For instance, the xs (cross-site) linker wraps the whole script in an anonymous function so it doesn’t “pollute the global scope” (technique also known as the module pattern). It cannot then dynamically inject some other script into the page that would have access to its internals. The sso (single-script) linker has the same limitation.

The std (iframe) linker loads your app in a dynamically created iframe which serves as the sandbox: the iframe’s global scope is not the host page’s global scope. It can then dynamically inject a script inside the iframe that would have access to everything that’s already there (the iframe’s global scope).

But actually, you don’t have to choose which linker your app should use: stick with the xsiframe (which you have to activate explicitly however, for the time being that is). It combines the cross-site friendliness of the xs linker with the iframe sandboxing of the std linker.

You can expect all other linkers (except maybe the sso one) to be deprecated in future GWT releases, and eventually be removed altogether; and the std linker to be replaced by the xsiframe linker as the default linker.