Hacker News Reader

Comment by gigel82 | Hacker News Reader

You hardcode the dependency version in the actual URL string in JavaScript code? How in the world is that manageable? I run `npm update` once a week and it brings down a dozen or so updates (occasionally `npm outdated` as well with manual testing).

I bet we'll have a bunch of competing standards for "dependency management" in deno coming online really soon, because there's an obvious need for that.

Also, are dynamic dependencies a thing? Can I run some code to decide (at runtime) whether I import this.package or that.package? Holy hell... with test coverage the way it is in most projects, that's going to blow up really fast.

View on HN

>I run `npm update` once a week and it brings down a dozen or so updates

That's my worst nightmare. This kind of thing always results in my having to spend hours figuring out which of the new updates broke everything and what do I have to do to fix it.

Once I have something working, I don't want updates to ever be installed unless I know 100% for sure that it is only fixing a security issue.

I never had that issue. But I had issues with native extensions often, a few years ago it occurred often enough that I would favor JS only if I could find an alternative. But I also avoid webpack because that always did break with updates, maybe now is more stable? Regardless, dependency management is hard. Every time I would do some c++ I would waste a lot of time just trying to get things to compile. Worst experience for me has been with iOS apps, I would make an app, wouldn’t need to touch it for a while and then I would have to update iOS version, which required a new Xcode version, which required a new Mac version, and then Swift’s API would have changed and things wouldn’t work. Dreadful. I guess my takeaway is that software rots fast

You can use automated testing to verify if your functionality is still there.

If that's too much work you can just deploy to a subset of your users (after npm audit) and let the error monitoring system tell you about the new exceptions.

I think it works fairly well for the use case of a scripting runtime instead of an application runtime. Consider a common command such as:

> curl -fsSL https://myapp.io/install.sh | sh

Thats pretty scary. It might do anything to user data. The deno sandbox would offer more assurances of course:

> deno run --allow-write=~/.myapp https://myapp.io/install.sh

You know it would only access what you expect. Same with another command:

> deno run --allow-read=./my-data.csv https://data-app-thing.io/visualize-data.ts my-data.csv

It's as described, a browser, not a server platform.

Please don’t compare Deno to NPM. This is all I see anytime Deno is mentioned, and often in some form of severe defensiveness.

If you need a million packages to write a tiny application Deno may not be your cup of tea. The entire article is about readjusting your expectations away from that kind of incompetence towards an alternative approach.

It's not incompetence; there's quite literally no other real solution. The sprawl of the npm ecosystem is a result of there being (essentially) no standard library in JavaScript and an intentionally small one in Node.js. As a result, simple problems have to be solved in userspace.

Your application can intentionally choose only to depend on a small number of libraries, but of course those libraries will need to consume other libraries, and so on, and you rapidly end up with hundreds of dependencies in node_modules.

If we wanted to solve this, we could introduce a comprehensive standard library. However, we'd need it to be bundled with every existing browser (and Node.js), which is likely why it hasn't happened.

> The sprawl of the npm ecosystem is a result of there being (essentially) no standard library

You finish that statement with a phrase completely at odds with this part about no standard library. After having written applications using Node for a decade now I have learned to see the real problem is developers not wanting to write or own original code. No standard library will be comprehensive enough to fix that.

The lack of a standard library is definitively a major factor and the way npm solves the Diamond Dependency Problem exacerbates the issue by an order of magnitude. Not only is everyone pulling in dozens of packages that do simple things, you also end up pulling in dozens of versions of each of those packages because package developers aren't forced to flatten their dependency trees. And since no one is forced to do do this, using something like 'yarn install --flat' yourself is a huge pain.

If we had a proper standard library and a sane package manager with flat dependency resolution by default, bundling just the parts of the standard library we need for the web would be easy (browserify has existed for a long time).

> You hardcode the dependency version in the actual URL

Websites have been doing this for .. 20 years?

It's quite a different paradigm, yes.

Before the age of React, when I used to work on decent-sized web sites' frontend, there would typically be maybe a handful of external dependencies; usually just jquery; and later on perhaps a few other powered-by-jquery utility that gives you maybe a carousel or other UI elements. Most of the rest of the JS code is written in-house.

Working with node backend in the past few years, most of my backend services typically list a dozen dependencies or so in package.json, and those in turn have a bunch of other dependencies of their own. Among these there's probably lodash, some schema validator (ajv/joi/etc.), maybe an xml parsing/building lib, some unit testing framework, db query builder, and so on.

I'm not saying this to be pro-node and attack deno or anything; I just feel like the statement of "websites/browsers have been doing this forever" isn't exactly an apples to apples comparison.

A major difference: transitive dependencies. In the old days, jquery.foo.bar.js would say “make sure you’ve loaded jquery.js and jquery.foo.js first”, and it would be up to you to decide which versions of them to use. Under Deno, modules will declare their exact dependencies and I suppose you the caller can’t control them. Or else they could devolve into some form of dependency injection.

This could lead to many copies of a library being loaded and included, rather than just one via deduplication as other packaging systems tend to do.

(The article talks about the potential need to remap dependencies, which could allow you to resolve this sort of duplication manually, but says that the current implementation should probably be avoided.)

Websites have been doing this for .. 20 years?

Web developers have been trying to move away from that paradigm in order to make sites faster, more reliable, and smaller for almost as long.

Web developers have been trying to move away from URLs that describe their content for 20 years?

Well that certainly explains the state of the 'modern' web

Web developers have been trying to move away from URLs that describe their content for 20 years?

My comment wasn't about URLs describing their content, but rather the assumption that goes along with it that every network request will always work perfectly. Once you realise that things do actually fail occasionally you should realise that local caches and bundling things in to a smaller number of requests can improve resilience.

That's not really an issue with Deno because it does things to mitigate the issue (eg caching packages locally), but websites that loaded libraries using separate requests for each one were horribly prone to failure if one thing was missing, and slower overall if the browser couldn't fetch everything in parallel, so devs invented things like bundlers to fix the problem. Then came things like code-splitting and tree-shaking to reduce the size.

You could for example just as well import * from 'unpkg.com/react' that handles the updating automatically since it always resolves to the latest version. You could just as well put a modifier to the url to specify you only want minor updates etc...

There are already more than few.

Personally I am a big fan of https://github.com/hayd/deno-udd

GitHub probably will have a dependency management for it. It already hosts most of the packages I guess

Reply on news.ycombinator.com