Hacker News Reader

Comment by apo | Hacker News Reader

Meanwhile, Deno (alternative server-side JS built from scratch by the creator of Node) keeps chugging along:

It will be interesting to see which happens first: developers migrate to Deno or Node finalizes its ES module implementation.

I think both groups are doing excellent work, but the Node team seems to be at a disadvantage having to continue support for some decisions made early on in Node:

https://www.youtube.com/watch?v=M3BM9TB-8yA&vl=en

View on HN

This is my first time seeing it but so much of it looks great. I don’t think I’m a fan with how it handles dependencies, though. It feels like they’ve just reinvented GOPATH.

“Deno caches remote imports in a special directory specified by the $DENO_DIR environmental variable. It default to $HOME/.deno if $DENO_DIR is not specified.

...

Production software should always bundle its dependencies. In Deno this is done by checking the $DENO_DIR into your source control system, and specifying that path as the $DENO_DIR environmental variable at runtime.“

https://github.com/denoland/deno/blob/master/Docs.md

The suggestion to import and reexport dependencies in a central `package.ts` file sounds absurd to me.

Clearly, I’m not a user and am just now reading this for the first time. Has there been discussion about this in the community? Are there plans to correct it? Go has been digging out of this hole for years, I can’t imagine why they’d start in the same place.

Disclaimer: I contribute to Deno.

Contrary to Go, when using Deno you don't need to invoke any command to install a package. You just put your import statement with full URL (you can pin version there, eg. https://unpkg.com/liltest@0.0.5/dist/liltest.js) and Deno downloads it on first run and caches for later use. Changing $DENO_DIR is somehow equivalent to changing node_modules location. This eliminates need for package manager.

I'm tempted to apply a Greenspun-ism, that by "not having a package manager", you're going to effectively have a half-implemented, bug-ridden package manager anyway. :-)

More seriously, dealing with the version hell that is inherent in dynamically assembling (your project has it's own unique dependency graph) publicly shared, uncontrolled libraries (only Google has a true no-version-numbers-ever monorepo) is nontrivial and so it seems like surely there has to be something being "effectively a dependency manager", though perhaps it is just semantics of embedding that in the runtime "because imports are urls in the source files and not a separate Json file"...not sure what fundamental benefit that brings though?

I feel that the Deno project's goals to get away from NPM/centralized registries is causing developer experience pains that it feels like you're trying to sweep under the rug.

Maybe it's time to take a look at building a replacement package manager.

The convenience of having a single package manager that handles name resolution, versioning, governance, and security is why NPM is as prolific as it is today.

That being said, the reason NPM even received any traction from the start was because Isaacs bundled it with the Node distribution.

In my opinion, this is the clear chance for Deno to provide its own, better package manager, built on top of IPFS/Dat or some similarly decentralized protocol, and correcting the many mistakes that have been openly accepted by Isaacs and others in the lineage of Node/NPM.

You don’t need package management dependency hell just like you don’t need frameworks. This pain is self imposed due to a desire of perceived convenience or the lack of competence to see otherwise.

When your total dependency graph is less than 8 packages you can easily manage this manually. This especially true since there are bots that can automatically check for version updates.

I don't have knowledge about early NPM stages, but from my perspective the goal right now is to get rid of need for package manager.

How does Deno need a package manager at the moment? I don’t understand your perspective.

I think the point here is, that Node.js needs one and Deno is created to get away from that.

How exactly does Node.js require a package manager?

const packageManager = require('package-manager'); // QED

`const npm = require("npm")` actually works AFAIK

Well, it doesn't technically require it...

Exactly.

Deno doesn't need to solve for this, it's already achieved it. An interpreter has nothing to do with a package manager. One problem that Deno is actually solving is the tight coupling of NPM and Node. Commonjs is very much purpose-built for NPM modules.

It's a smart call for the team to tackle this problem as it's one of the biggest pain points of using Node and the biggest threat to its long-term sustainability. But I fail to see how no package manager is a viable solution. As someone who's used Go and Node for the majority of the time they have existed, trust me when I say that a package manager is a good thing.

Node is an incredible ecosystem. We just need a better implementation of its package manager.

> import { test } from "https://unpkg.com/deno_testing@0.0.5/testing.ts";

This feels both very pragmatic and frightening at the same time.

What bothers me most about it is the lack of a checksum, which is something Go modules support. I think that’s a mandatory feature to prevent certain attack vectors. Other than that, I have no problem with this approach.

Package validation (using a checksum or signature) is definitely on our radar. We just haven't gotten around to it yet.

I'm not an "expert" but that feels just as insane as the npm argument people make. I'd love to hear from someone more in the know as to why they aren't the same.

They really aren't if you think about it. Going straight to a URL for a version of a dependency is the same as pulling it from a registry, except it's decentralized from a single source (NPM) and removes the extra hops in between the package vendor and the package consumer.

On the flip side, that extra hop adds a ton of convenience in the form of name-resolution, security and governance. It's the age old double-edged sword of centralization.

Maybe if you turn that url into a hash, than just use the hash to check if the package has a local copy already, it wont be so bad. But you will need to add the package version in the URL so that you know you will always have the package you really want in your local cache.

because npm's is implicitly in the build pipeline. You won't run 'npm install' on production! you run that on development/certification and then push the validated image to production.

With deno, there is no distinction anymore, kinda of. You still can send to production images that have the deno cache. Only thing that changes is the default. Previously you would have to explicitly run 'npm install' on the production host, failing that the code fails. With deno you still can choose to push to production an image without the caches (same as 'npm install' in prod), but now the default is that untested code in QA will auto install without hash check!

in summary: absolutely no practical change (i.e. no new feature impossible before) other than production defaulting to installing remote dependencies of proven-not-tested functions.

Without SRI or similar this is very frightening.

edit: they're thinking about it:

https://github.com/denoland/deno/issues/200

Security shouldn't be an afterthought.

Let's throw everything out of the window and start from scratch. The JavaScript way of doing things is why I don't like to invest much in this ecosystem.

Being a daily TS/Node dev for a while now, I'm super excited about Deno. Any idea of when it will be production ready?

Disclaimer: I contribute to Deno. IMHO it will take 1-2 months before someone deploys simple production services. We're already working on standard library, which you can see here: https://github.com/denoland/deno_std

Awesome, how has the experience been on the project? I'd love to get involved as well, are there any contribution guidelines or starting points?

Experience has been awesome. This tech is really challenging for me, but at the same time amount of knowledge I gain is huge. Deno community hangs around on gitter, here: https://gitter.im/denolife/Lobby

Question about contributions has been raised on gitter several times already and the answer was to look for "good first issue" labels in GitHub repo. However there are not many of them right now.

Does Deno support native ES modules or does it implement a require() shim and rely on TypeScript transpilation?

PR for this is here: https://github.com/denoland/deno/issues/975

It's expected that this should land in next month.

Thanks for reminding me about Deno. It really feels like some of Node’s homegrown solutions to things like modules and async is starting to become a burden.

> It will be interesting to see which happens first: developers migrate to Deno or Node finalizes its ES module implementation.

I guess that depends on what you mean with "happens". Only one of them has a clear point where they're done happening.

Hehe,

I want a Deno Lambda runtime :D

You can do this now with Lambda Layers and the Lambda Runtime API, right?

https://aws.amazon.com/blogs/aws/new-for-aws-lambda-use-any-...

"The runtime bootstrap uses a simple HTTP based interface to get the event payload for a new invocation and return back the response from the function."

Interesting. I had the impression it would take more to get your language of choice up and running.

Reply on news.ycombinator.com