[exogen]

Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right?

Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc.

These things are made to be reusable right?

What are the chances you can do that without issues? Do you think any of their style rules/selectors would clobber each other? What about the base/assumed CSS that they all most likely require? What about components more complicated than a button? Without actually trying it, how much confidence do you have in your guess, vs. your assumptions about importing other things (like functions from npm modules)?

Good software is reusable without worry.

[gizmogwai]

> Good software is reusable. I can import functions from 1,000,000 different npm modules all into my project and they don't fuck with each other, right?

I just spent the whole day trying to fix compatibility issues between different versions of npm libraries transitively imported in a project. Reusability in JS is a joke.

[devilshaircut]

Agree.

As a primarily JS/React developer, I think there is irony if JS is held as a good design pattern in comparison to CSS with respect to reusability. Inasmuch as what are being called CSS "workarounds" are in fact workarounds, so too has been the case with JavaScript itself. I am old enough to remember jQuery and Prototype colliding over the dollarsign namespace.

Don't get me wrong. I am not a JS (or CSS) hater. I think these "workarounds" are more than adequate in making these technologies easy to work with. Which I suppose is sort of my point. I see a lot of overengineered codebases with Byzantine solutions to relatively simple problems.

Also, to parent poster:

> Let's say you wanted to pull in a button from Bootstrap for one part of your page, a button from Material UI elsewhere, a button from Semantic UI elsewhere, etc.

1) First of all, don't do this. Perhaps you were just saying this to make a point, but obviously don't include 3 monolothic libs with overlapping functionality in order to implement 3 things with the same functionality.

2) It sounds like your problem with this is more with the libraries themselves. When I write a component, I always namespace it myself. Obviously, if libraries are properly namespaced, then you could easily include buttons from three separate button libraries.

[exogen]

What dependency system anywhere on earth is free of the problem of "two things require different versions of the same library"? I don't see the relation to JS at all.

I've had this problem with JavaScript-before-npm-existed, Python, apt, Homebrew, Portage...

[ahakki]

stack for haskell

nix package manager

[exogen]

Note that npm also supports having multiple versions of the same package installed just fine.

The problem:

I use X to create an object with library A v1.0.

I use Y to create an object with library A v2.0.

These objects are not necessarily compatible, so X and Y have problems communicating.

I would be very surprised if you told me nix or stack inherently make objects from multiple versions of the same library magically compatible with each other.

Feel free to close issues like this one if I'm wrong: https://github.com/NixOS/nixpkgs/issues/30551

[Risord]

Hmm I think this should go something like this:

How would objects created from X and Y can reach each other and communicate when X is not dependent from Y or otherwise? You need global mutable state or your own code witch depends from both X and Y is somehow connecting them.

So one top thing FP movement argues against is global mutable state so of course you don't have that ...Unless you are wrapping some non-FP thing like QT...

And if it's your own code it shouldn't be different that Y creates B:s instead of A v2 since your code is aware from two different versions anyway.

Do you see any weak points?