I’d like to ask whether anyone has thought about how the new dynamic imports will work with Angular and Typescript?
The key benefit I’m after is improved startup time as our app is growing rapidly but so is the load time.
I’m exploring a number of avenues and I thought it would try to clarify the key issues:
AOT Compilation of Angular templates.
Compilation of templates when the Angular app starts is definitely taking quite a bit of time for us, and the AOT compilation of those templates using
ngc would help a lot. I know work is in progress to integrate this into the angular-meteor and angular2-compilers (see https://github.com/Urigo/angular-meteor/issues/1475 and https://github.com/barbatus/angular2-compiler/issues/2) and I really appreciate the efforts that the team have been putting into Angular support. But I also understand that they are quite busy with other things too.
Angular has a sophisticated mechanism for grouping code together with dependencies. It is integrated with the router so the router can lazily load the modules on demand. See https://angular.io/docs/ts/latest/guide/ngmodule.html
This does work non-Meteor apps, but as you know meteor before 1.5 currently essentially bundles all client side code into one big download.
Typescript support for import()
It seems that Typescript doesn’t currently support the dynamic import() syntax, and I’m not sure what impact it would have on propagation of type information. Clearly at build time, for type checking the import would want to be eager, and then only actually do the require() etc. underneath at runtime. See https://github.com/Microsoft/TypeScript/issues/12364
More details on what sort of imports are supported are here: https://www.typescriptlang.org/docs/handbook/modules.html#import
Though Typescript does have some support for calling require() so possibly there’s some way of using that instead. https://www.typescriptlang.org/docs/handbook/modules.html#export--and-import--require
So my question is really more a case of:
Has anyone considered how these issues interact with Meteor 1.5?
Does anyone have any additional information towards solving these?
Here are my related thoughts…
For me, Typescript is has been a real benefit maintaining a larger code base with multiple people working on it. It naturally fits with Angular (2+) and given our investment in both it would be a real shame and significant effort to lose either.
We also rely heavily on meteor methods, subscriptions, account package plus lots of other nice Meteor things, e.g. server side coding with fibers is nice too (though async/wait would be fine), therefore we’re not keen to lose Meteor either.
Meteor 1.5 seems to be going in a fantastic direction - finer grained lazy loading and caching seem to be exactly what we need (though it obviously won’t solve the template compilation issue). With that, we would not need to rely on Angular modules for bundling.
So, I thought I’d ask for input.
Please avoid non-constructive “switch to React (or Vue, or …)” or “ditch Typescript” suggestions. These are a consideration but the switch cost is pretty high in a number of respects, and I’d like to explore options with the existing stack first.
UPDATE: I did come across this post from Uri about the Meteor Client Bundler which may help. I haven’t absorbed/investigated it all just yet: https://blog.meteor.com/leverage-the-power-of-meteor-with-any-client-side-framework-bfb909141008