The best part will be when we're all standardized on ES2015 modules instead of commonJS modules. I agree with you that CommonJS requires are nice to use, but since they're not statically analyzable the way ES2015 imports are, optimizing compilers like the Closure Compiler can't really analyze your entire application, including its dependencies.

Once we've completely made the ES2015 transition (at least for front end modules), we might be in a position to see some really great front end tooling.

Yeh I initially hated that commonjs was not used for es2015 imports. Slowed down application startup and lack of node.js compatibility.

But after reading the justification it will be better in the long run.

We just need some way to lazy load modules.

Better bad is not the same as good.

The approach itself yielded the issues such as that you reference, which have only been partially resolved by subsequent iterations of the same approach. I don't believe we should give credit for an approach that yields what is still a net-negative.

It's a new thinking that we need, not reluctant acceptance of the best sub optimal execution the old thinking can deliver.