> because you make it sound like you easily could have just extracted the Deno-compatible JS, and made a regular ECMAScript Module and avoided an NPM compatibil

> because you make it sound like you easily could have just extracted the Deno-compatible JS, and made a regular ECMAScript Module and avoided an NPM compatibility layer at all "Easily" is relative. I'm sure one could port the library I'm using to be Deno-compatible, maybe with less trouble than some other libraries because it's unlikely to use many system APIs, but it's also a large, significant, mature library; we're not talking about leftpad here. And I'm just making a blog site. I want to get on with my life, not spend hours or days fiddling with all the long-tail incompatibilities I would probably run into making a Deno-compatible fork of a major library that I'm not planning to maintain (not to mention any dependencies it itself has!) If I'm writing a new library that I've already decided to put effort into, I'm likely to make it Deno-compatible from the get-go. But porting something significant to Deno is not trivial, even where it is straightforward. Things take time, and over a whole ecosystem it adds up, and we can't erase that labor gap from the discussion.