News for hackers. Stuff that matters.

A comment on Deno on MDN. Parent comment

Re:Deno on MDN by andrew_ on Monday August 23, 2021 @09:55AM (#28275753)
The more I learn about how it imports external/third-party code [1] the more I like it. It's got none of the hangups of NPM. No package.json nonsense (there are great script runners if you need them), and no cruft when importing external code (e.g. no need for yarnclean). The registry they do maintain is unique and immutable, which I was not sold on until I had this discussion [2]. I do still think they need some more guidance around how that works, and some contingencies in the event of bad actors, but it's just as good as NPM's registry imho. Native TS is a nice convenience for projects which call for it, and compiling is much more streamlined than bolting it onto a project yourself. It's worth noting that it does support plain JS, just the ESM flavor. And last but not least is the stdlib, which roughly aims to prevent the need for a million one-line packages spread out across the registry. Network throughput performance is impressive to say the least, and with leveraging Rust I can only see that getting better. The more I learn about Deno the more that I'm liking it.

[1] https://deno.land/manual/linking_to_external_code [2] https://github.com/denoland/deno/discussions/11809#discussio...

[ Parent | on HN ]
Re:Deno on MDN by nightpool on Monday August 23, 2021 @11:12AM (#28277033)
I was just having this discussion with a friend of mine this morning. How is this not the exact same mistake Go made when it was released in 2015? They spent years and years walking back the issues that "go get" had in favor of a real, actual package manager. I know Deno encourages users to use versioned imports, which works around some of the bigger problems that Go had, but creates a lot more problems in terms of upgrading transitive dependencies. How is this a step forward?
[ Parent | on HN ]
Re:Deno on MDN by whateveracct on Monday August 23, 2021 @11:22AM (#28277207)
Ignoring hard problems for short-term gains is an easy way to get market share.
[ Parent | on HN ]
Re:Deno on MDN by lucacasonato on Monday August 23, 2021 @11:31AM (#28277384)
We don't ignore these problems. We find web compatible ways to solve them. If you had done just about 3 seconds of research before posting, you would have noticed we have support for import maps[1]. These elegantly solve the issue in a way that also works in the browser. No node_modules needed :-)

[1]: https://deno.land/[email protected]/linking_to_external_code/im...

[ Parent | on HN ]
Re:Deno on MDN by whateveracct on Monday August 23, 2021 @12:09PM (#28278051)
That looks like the output of a package manager (like a cabal freeze file), but if that's all you got then you don't have a package manager yet.
[ Parent | on HN ]
Re:Deno on MDN by spankalee on Monday August 23, 2021 @11:51AM (#28277714)
Import maps are great if you know all the mappings you want to make.

That requires that you know every way that conceptually the same packages are imported in the entire transitive module graph, which is hard enough on its own, but also requires crawling the whole live module graph to discover all the imports. I don't see how this isn't just npm-but-worse.

[ Parent | on HN ]
Re:Deno on MDN by whateveracct on Monday August 23, 2021 @12:10PM (#28278068)
It'll eventually evolve into npm-but-different once Deno gains more adoption and its users learn they need a real package manager. And the cycle continues.
[ Parent | on HN ]
Re:Deno on MDN by andrew_ on Monday August 23, 2021 @12:17PM (#28278164)
projects like `trex` [1] take the heavy lifting out of the equation, and are nicely compatible with a lockfile. This may feel familiar, even somewhat similar, but after using it for a short time I state with confidence that it's not a package manager. This paradigm is enjoyable.

[1] https://nicedoc.io/crewdevio/Trex

[ Parent | on HN ]
Re:Deno on MDN by silasdavis on Monday August 23, 2021 @01:10PM (#28278942)
Yes, it seems like a very similar mistake to me: https://github.com/denoland/deno/issues/4574#issuecomment-62...
[ Parent | on HN ]
Re:Deno on MDN by spankalee on Monday August 23, 2021 @11:06AM (#28276908)
It's quite a bit worse than npm.

Without bare module specifiers (like `import {html} from 'lit-html'`) to act as an abstraction over location you have to import directly from a URL, but what URL? Packages either have to be self-hosted, or very often npm packages are loaded via CDNs. There are several CDNs that host the same packages (unpkg, Skypack, jspm, jsDelivr/esm.run) so there's no single canonical URL to load anything from and each module that loads a package could load from a different CDN, or simply load a slightly different but compatible version, causing multiple copies of the packages to be loaded.

There's a huge benefit to abstracting over package names, and Deno mostly throws it all away. It does support import maps, but you'd need tooling that doesn't fully exist yet to crawl and dedupe a module graph and at that point it'd basically be npm but a lot slower with no registry to use for metadata.

[ Parent | on HN ]
Re:Deno on MDN by andrew_ on Monday August 23, 2021 @12:19PM (#28278197)
> It's quite a bit worse than npm.

That's a rather subjective take.

The rest of your comment can be fulfilled by `trex` https://nicedoc.io/crewdevio/Trex. Perhaps it's been a while since you took a good look at how the ecosystem has evolved. I just started giving Deno a hard look last week and I've already found answers for needs like this.

[ Parent | on HN ]
Re:Deno on MDN by spankalee on Monday August 23, 2021 @12:25PM (#28278300)
Aren't most takes on here subjective? I don't think we label most posts with "Only my opinion, but..." event though that applies to almost everything here. Anyway...

Trex doesn't do anything about transitive dependencies and package deduplication, what my critique is about.

[ Parent | on HN ]
Re:Deno on MDN by ramesh31 on Monday August 23, 2021 @11:51AM (#28277712)
>Okay so it's coupled to Microsoft's take on Javascript. What about Flow or any of the other compiles-to-Javascript languages? What's wrong with using Babel with sourcemaps?

This is kind of like saying "Oh it supports Javascript? So now I'm tied to Netscape's take on browser scripting?" at this point. Typescript has won the JS compiler wars and become the defacto standard for the community.

[ Parent | on HN ]
Re:Deno on MDN by spankalee on Monday August 23, 2021 @11:52AM (#28277738)
Which slightly incompatible version of TypeScript though?

edit to add: I'm serious. JavaScript tries very hard to not have backward breaking changes. TypeScript does have breaking changes at about ever minor release. The TypeScript team manages the project as a versioned tool, not as a distributed environment like the web. afaik, Deno hasn't really solved this problem, so there's a chance your code breaks when Deno upgrades its TypeScript version.

[ Parent | on HN ]
Re:Deno on MDN by Vinnl on Monday August 23, 2021 @03:04PM (#28280477)
It's a somewhat relevant concern, but also less so because breaking changes in TypeScript are usually semantic (type-checking) ones and most of the times make it error on bugs (i.e. code that hopefully isn't in your codebase already, and if it is, you'll want to take it out). Deno doesn't do type checking, it just strips TypeScript's type annotations, which they're far more careful about breaking.

Even so, they could limit such breakage to major Deno versions with other breaking changes, if necessary. Not sure if they do.

[ Parent | on HN ]
Re:Deno on MDN by oatmealsnap on Monday August 23, 2021 @01:45PM (#28279427)
That's always a concern, though. Node has breaking changes, too.
[ Parent | on HN ]