Dynamic loading tutorial

In this post we will see how true dynamic loading with dartdevc works and how to use it with polymerize projects.

Dynamic loading is a powerfull feature that at the moment is unique to dartdevc and can be a valid replacement for the hard optimizations techinques that dart2js is capable of.

To explain how dynamic loading works and how to use it in your project we will make use of a sample project.

The loader sample project

You can build the demo yourself by following the instructions on the project home page, or access a running sample here.

Running the demo

When accessing the demo a “splash” (very basic indeed) screen is loaded first:

splash screen

This takes a very short time as it’s only a static template and a couple of script (web components polyfill and polymerize start.js):

phase1

Then the main entry point is loaded and started:

phase2

This times it takes a little longer and it loads:

The main entry-point is very light and requires few libraries to be loaded, most of which (for example dart_sdk.js) will also be cached, so it is very fast load and to execute.

It is at this point that the real execution of “dart code” begins.

The task of loader.dart is just to trigger the loading of the first module (web/module1.dart that defines the polymer component <component-one>), wait for the loading to complete then replacing the splash screen with the main component tag:

phase3

This times a lot of things get loaded. The first thing that’s loaded is the module entry point : web__module1.js (web/module1.dart), then all the dependencies :

When the module finishes loading the new component tag gets registered and the loader will use it. At this point the user can already start to work and interact with the first module of the application:

page1

By clicking on the button the second module gets loaded. While waiting for the module to load a spinner is shown in the top-right corner.

Again the modules file (web__module2.js) is the first to be loaded, then all its dependencies:

phase4

When the load finishes and the new components get registered, the neon-animated-page current page changes to show the new state:

page2

Clicking on the paper-fab a dialog is shown that asks confirmation and the first page is displayed again. This time clicking on the button won’t trigger the module loading again as it is already loaded and the next page is shown immediatly.

Conclusions

Dynamic loading is a powerfull feature that let you control which parts of the application should be loaded and when.

When using dynamic loading during the lifetime of the application only the resources neeed to accomplish the user requests gets loaded. This is true not only for dart code but also for all the related resources like, for instance:

All this doesn’t apply to dart2js builds because they are monolitic. All the dart code will be loaded in a single step and the user must wait for the whole application to be ready until he/she can start to interact with it. In that scenary it’s easy to understand why something like tree-shaking is not only desiderable but also vital for the application usability. And that’s why without something like dynamic load using dartdevc for realease build would be a suicide mission.

On the other end having the chance to only load the parts of the application that are needed let’s you create a progressive and pleasant user experience even without extreme optimizations of the build.

Obviously in a perfect world you would like to have both. But unfortunately the tree-shaking algorithm doesn’t play well with modularization. On the other end a certain amount of post processing can even be done to dartdevc builds like minification and embedding.

Ok, But how it works ?

In the next part we will dig into the sample code to learn how to define application modules and how to load them.