Yarn

Recent twts in reply to #vh5pwrq

@markwylde@twtxt.net No, it doesn’t have to be this way, but it is (almost) always this way. When a programming language makes it too easy to manage dependencies, you inevitably get microdependencies. It doesn’t help that many people learn JavaScript or Python as their first language.

⤋ Read More

@prologic@twtxt.net hmm… I have mixed feelings… Like reinventing the wheel to learn vs using an already round one…

It’s a hard conversation, and as with education it depends on your context and ideology but you can and should ‘force’ it in your organization

⤋ Read More

@prologic@twtxt.net I see the opposite here, copying and pasting lazily instead of creating reusable code.

I mean, having a dependency to know if a number is odd or even is excessive https://www.npmjs.com/package/is-odd-or-even

But at the same time if your language or runtime gives you these quick snippets is usually better that your own code, due to those “things you didn’t know you don’t know”. That’s why I have mixed feelings on copying and paste vs using a dependency vs reimplementing it yourself.

⤋ Read More

@eaplmx@twtxt.net There can’t be a concrete rule for this sort of thing. I’m generally in favor of reinventing the wheel to certain extent, but using a library can be very useful if you want to focus on the end result.

When your 5 dependencies each have 5 dependencies of their own, then you have a problem.

⤋ Read More

@prologic@twtxt.net

“dependency hell” comes from this “exponential dependency tree” that we inevitably see in ecosystems like NodeJS / NPM

Yes, and these “ecosystems” try to put a band-aid on it by allowing packages to specify which version of a package they need. All that means is you get 7 different versions of the same package bloating up your node_modules folder and 6 critical vulnerabilities from one package.

Then, it’s impossible to keep track of all 1200 of your dependencies and sub-dependencies, so you get a robot to do it for you: Dependabot. What happens when Dependabot dies? Absolute chaos.

NodeJS library authors could just write better libraries and avoid breaking changes every update, and NodeJS software developers in general could fix their programs when they break, but they don’t. It’s on the “ecosystem” to solve for this, and it inevitably does a terrible job.

⤋ Read More

@prologic@twtxt.net

are there other examples?

Python, Ruby, Perl, Rust. Sometimes even Go. There’s a little bit of this in every language with an official package manager. I’d say Python and NodeJS are the worst offenders, though.

I feel like I pick on NodeJS / NPM too much

I don’t think we pick on NodeJS/NPM enough.

⤋ Read More

@eaplmx@twtxt.net my view on this is that I tend to recreate the wheel everytime for a simple reason: it get better everytime I make it.

When copying something, which is ok for me too, you’re relying on the thought you had at the time, while currently they could be different and you could get around a problem quite differently.

For me reusability is about internal code, not with libraries.

If I need to share code with my project using a library then that library is made with my own hands and code.

⤋ Read More

Participate

Login to join in on this yarn.