Is it possible to do an AOT build without using buildStatic? I need dynamic loading.

[factoidforrest]

When you buildStatic, you lose some SystemJS stuff I need, namely dynamic module loading at runtime.

The trouble has been that I haven't been able to make normal SystemJS code work with AOT. Does anyone know if it's even possible?

[mgechev]

Here's an example for lazy-loading (what I suppose you want to achieve) https://gist.github.com/mgechev/63d374d51ac846797879a0cdc9c3b97c.

[factoidforrest]

Wow, thats very interesting. So you are bundling the main app with SystemJS but then using buildstatic for the lazy loaded modules. Any reason for that? Since the SystemJS runtime is already required by the main app. And this approach works with AOT?

Is this the same or similar to what happens if I call npm run build.prod.exp from the lazy branch?

[mgechev]

Yes, it does work with AoT. Used it in a production application some time back.

[factoidforrest]

Hmm, I'm trying to figure this out. Rather than posting this gist around, how come it isn't part of angular-seed? Seems like you have it already working. I checked out the "lazy" branch but it won't build. Seems like a ton of the dependencies are messed up for me since they weren't version locked.

So you call AOT first somehow and then bundle the resulting ngfactory files? Is there a more complete setup using this setup that I could see? It's difficult to figure out how the parts fit together.

It seems this fellow got close but his changes were never merged. #1714

[dcarabott]

@light24bulbs Have you ever managed to make use of dynamic module loading ?

[factoidforrest]

@dcarabott YES actually, we got the whole thing running in webpack with aot and JIT, so far only with an older version of the compiler from angular 4. It was insane task, it's taken us these last months to do. Soon my company will be open sourcing the modules we have developed to make it work, and publishing a white paper.

Be warned though, we did insane things. We wrote a webpack plugin to replace module IDs in webpack with UUIDs. We hooked a canactivate on the angular 404 (** route) and when it gets hit, we check a list of webpack bundles, then manually load the webpack bundle onto the angular router.

Our pattern was nuts, I can't really recommend it, although we will be explaining it pretty soon in detail. It would be much easier with something like Vue, which is a lot more flexible and all around better. AOT and typescript have made all this dynamic stuff a nightmare.

I can't really recommend Angular at all, after everything weird we have found digging around in here. It's a house of cards made out of bad decisions.

[bmbell]

@light24bulbs : I would be very interested to know what you guys did. My company is currently struggling with the same problem and we haven't found any decent solutions.

[factoidforrest]

We are waiting to have some adoption within the company to see if this approach really works and then we will publish a whitepaper and open source the relevant modules. As usual, it's taking longer than expected.

From a team that spent months getting this to work, here is my takeaway: Don't do this. Our story, while successful, is also a cautionary tale. I'm not sure I would call it a healthy pattern.

We are now, after 4 months, in alpha of the dynamic loading approach. We have diverged from webpack and angular significantly. The upgrade to angular 5 is questionable at best. Sharing code is cumbersome, and involves adding modules to a DLL(as in webpack DLL) and then rebuilding all submodules.

We have lost: Dead code elimination/tree shaking, sane continuous integration, and our application has become fragmented and difficult to maintain.

I think that if you want a modular application, you should build it all in one repo, use Lerna to version and maintain all modules together(exactly how angular was built btw), and have a master build step so things fail-fast if they are broken. And for the sake of your own sanity, use Vue.

[bmbell]

@light24bulbs Thanks for the recommendation.