Angular-Seed (together with the project owner's excellent Switching to Angular, 3rd Ed.—Oct. 2017) have taught me much of what I've learned about this framework and ecosystem during the past several months and I'm grateful to the owner and community for their years of contributions that have brought this project to this stage.

That said, as I've learned much more about the current (i.e. 2019) ecosystem for Angular development and the core technologies in use here, I've belatedly realized that this project represents, above-all, a substantial technology bet on SystemJS over WebPack.

In light of the prestige and huge following of this project (nearly 5,000 stars), more effort needs to be made in the key ReadMe and wiki to make the core ("opinionated") technology choices clear on the tin, so as to assist users new to the framework in making the right investment of their time. Ideally, there should be a link to a blog article that rationalizes or justifies the continuing (or is it legacy?) commitment to SystemJS as a loader/bundler.

As it stands, the contents of our ReadMe and wiki do not assist newbies in making an informed choice.

As a minimum, we need to link to and engage with the material in the following resource to outline the use-cases in which we believe the core technologies in use in this seed are the right bet, for dev and prod, for new development in 2019, versus alternatives:
Comparison of module bundlers and loaders

The choices about technologies are not trivial. Anyone who has configured the project.config.ts in this seed to support angular material widgets; who has discovered the intricacies of configuring a (third party, babel) systemjs plugin-transpiler to make function an ostensibly "angular"-oriented project such as ng-circle-progress; or who has configured functioning lazy loading aligned with the current guidance in the angular docs for Lazy Loading Feature Modules will immediately understand the gravity of the choice for new users' and teams' efforts.

If this is a legacy project that still primarily reflects the scene ca. 2015, then we need:

• a road-map for transforming it to something that will vindicate the investments of new users just "switching" to Angular;
• mark it, up-front, as deprecated (not recommended in its current form for new development); or,
• champion a downstream fork that stands the best chance of providing a competitive/winning set of tools.

Because of the connection of this project to the project owner's books, there is no doubt that this project is attracting interest from general users relatively new to the ecosystem. We need to ensure that the top level messages for this project treat them responsibly, with the care and respect they deserve.