Not sure why this touched a nerve enough to be downvoted into oblivion. If it was the cheeky tl;dr I guess I can make a point to avoid any and all attempts at s

Not sure why this touched a nerve enough to be downvoted into oblivion. If it was the cheeky tl;dr I guess I can make a point to avoid any and all attempts at sarcasm in my future posts. As for the rest, I genuinely think it's a useful approach to consider 1. it's relies on future web standards not tools Tools come and go. Web standards never go. If the goal is to avoid technical debt, then don't write code in a way that will eventually be obsolete. 2. 'Abstractions are the solution to every problem, except the problem of too many abstractions' Except, when there's a viable strategy to provide access at multiple layers of abstraction. If we're finally getting a truly universal module standard, why not leverage it to improve our library APIs? It's not like we have to waste the time/energy/effort supporting multiple module non-standards anymore. The approach I outlined above provides much better usability with very little effort on the part of the dev implementing an API. 3. It doesn't rely on approaches that will eventually be obsolete Namely bundling. Tree shaking is great if the end goal is to analyze all dependencies and create an optimized bundle. Except for the fact that bundling will become an anti-pattern when HTTPv2 reaches widespread adoption.