Hacker News Reader

Comment by henning | Hacker News Reader

> You Might Not Need NPM

If it's like every other JavaScript project I've been on since 2016, it's going to actually require thousands of JavaScript packages and doing everything with it is going to be slow as molasses even on high-end developer workstations.

View on HN

Deno has a standard library that wants to be 'batteries included' so you don't have nonsense like a third party package for left padding a string (deno supports string padStart natively for this for example).

Sorry but padStart/padEnd are part of EcmaScript 2019 (or near that year). Deno did not implement it. (AFAIK)

Both are implemented in deno per MDN’s compatibility table.

Deno does not have its own javascript implementation, it uses the V8 javascript engine, and V8 happens to implement padStart and padEnd.

V8 was originally created as the javascript engine for Chrome, but it is used in many products now, including Node.js and Deno: https://v8.dev/

That’s true for padding. Deno is still doing a lot to standardize on the web platform APIs to be part of the base runtime available and that’s work they’re doing on their own and not for free as part of v8. This is similar to what we do at Cloudflare and I think there’s similar efforts within Node in 17 for what it’s worth.

Everything supports padStart natively, for almost half a decade by now.

I'm referring to the left-pad package on npm that infamously ignited a huge controversy years ago and started some of the cracks in the entire ecosystem that are growing larger and larger today. For more context: https://qz.com/646467/how-one-programmer-broke-the-internet-...

Point is, Deno is doing a lot to bring feature parity with expected Web APIs (which are not part of JavaScript the language yet), and they are building a single export standard library, but padStart is not part of their (direct) actions.

One benefit of deno on this front is that it _only_ pulls down the js files you actually need. With npm, even if you only import one file from a package, every single other file will also be downloaded to your computer. And probably some test files, a bunch of package-lock files, maybe some branding images. Oh and the same for all the packages it references, too. The storage/download time savings of getting just the js add up a _lot_ more than I expected. I've toyed with deno on a few projects, and my entire deno cache is smaller than any single node_modules directory.

Deno is also creating a standard library, so that too should reduce the amount of external packages you'll need.

The Deno standard library is not bundled, but separately fetched as a dependency for each embedded file.

That's a pedantic argument, the deno standard library doesn't depend on any other library except itself and deno's core. You can know if you depend on it that you don't have dozens or hundreds of other dependencies, unlike pulling in a random npm package.

This is the real power of Deno!

Coming from PHP to Node.js back in the days it felt like quite an improvement.

In PHP reinventing the wheel was one of the biggest issues.

I think the problem was/is a generation of inexperienced developers who were brought up on importing packages for padding a number. Thing that always struck me was how easy and free it was to publish.

Kinda fun to imagine a packaging system where you have to pay a very small crypto fee to publish. I'd bet less packages but more useful stuff on the whole.

Reply on news.ycombinator.com