Kinda getting the feeling that with JSR Deno is both heading into the swamp that is the package repository sector and is waving goodbye at browser compatibility and putting Node compatibility first. Even as Node is putting more work into browser compatibility themselves.
> However, Deno code on JSR will NOT be permitted to use HTTPS imports. JSR performs deduplication of dependencies based on semantic versions, which is not possible with HTTPS-imported dependencies. If you attempt to publish code that contains HTTPS imports to JSR, you will receive an error.
@zack The problem I have is the only open standards in Node are the APIs that come from the web world and, hopefully, package.json now that OpenJS is trying to standardise that. The node standard library isn’t an open standard but managed as a software project. It’s unique to node and still changing
From my perspective, Deno’s node compat isn’t a new implementation of an existing standard but a VC-funded organisation trying to clone the evolving APIs of another OSS platform
@zack Which they’re allowed to do. Forks and cloning APIs are a longstanding tradition in free/open source software. Often they fail. Occasionally they turn out to be substantial improvements. In this case, Deno seems to be moving away from everything that made it unique, though. So there’s a good chance that my negativity is just my personal disappointment that a more web-oriented JS runtime didn’t seem to successfully compete with node.
Add comment