> flush out all the awful NPM modules out there you don't even know you have a dependency on and create a JS module ecosystem worth its salt This kind of view

> flush out all the awful NPM modules out there you don't even know you have a dependency on and create a JS module ecosystem worth its salt This kind of view is very prevalent in the web community, and in my opinion it's often the failing of the ecosystem. Good engineering takes time, there's almost no project out there that nailed everything on day one. It is through iteration and progressive improvement we achieve big things. Anyone with a crash course in programming can publish a library in a week. But it takes proficiency and hard work to maintain an interface over years or even decades. There is also no such thing as a perfect solution. Every solution makes tradeoffs and being able to adapt to tradeoffs relevant to your problem is a huge aspect of engineering. Deno going the scorched earth way would mean pulling back the ecosystem by at least 10 years. There is no guarantee they will get things "perfect" this time around. In all likelihood, they eventually would've come up against the same set of constraints the original ecosystem did, make similar tradeoffs and there would be a conversation 10 years from now about needing a reboot. The right way to do is to embrace legacy and build solid tooling where the legacy gives you rough edges. Another big aspect of engineering, in my opinion, is not being fanatical about aesthetics. Function over form, every time. I'm glad Deno is taking this route, I was previously critical of their choice to fork core packages like dotenv, semver, base64 etc, but hopefully this will move the community towards consolidation rather fragmentation.