3 ms·

That is a weird example, because you make it sound like you easily could have just extracted the Deno-compatible JS, and made a regular ECMAScript Module and av

That is a weird example, 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. In fact, I did this exact thing to use marked[1] with QuickJS[2]. Obviously, QuickJS doesn't have an NPM compatibility layer because it doesn't need one, and neither does Deno. The great thing is the resulting .js file can easily be a Deno module as well. > I tend to be an idealist in my programming - that's why I like Deno - but the absolutism I'm seeing in this thread is bizarre I don't really see any absolutism in this thread, it's just a disagreement. Yes, NPM compat is great for adoption. I'm arguing it's not great for the runtime, and that it adds tech debt, and slows the team down from doing (imo) more creative things. It also adds more to the binary. [1] https://raw.githubusercontent.com/markedjs/marked/master/lib/marked.esm.js https://raw.githubusercontent.com/markedjs/marked/master/lib... [2] https://bellard.org/quickjs/quickjs.html https://bellard.org/quickjs/quickjs.html

brundolf 3y ago
> 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.

brundolf 3y ago

> 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.