[throwdecro]

This is a rant I can appreciate. Two subjective takes on the same subject:

1) As JavaScript became ascendant, it seems like developers lost their fear of dependencies, for some reason I don't understand. Dependencies came to be seen as "time saved" rather than "something out of your control that can hurt you."

2) When dependencies don't fit together, things fail in a way that makes it look as if the code is simply wrong. Yet everyone working in the environment ends up conditioned to run to google with the combination of (circumstances, error string) to find someone who has figured out what the actual dependency issue is. It's automatic behavior. At some point it would make sense to include automated googling in the CI pipeline just to add some necessary information to the errors.

[Hermitian909]

I agree strongly and think once you regain your fear of dependencies the JS ecosystem actually isn't that bad. The kinds of packages that save me months or years of work are generally of reasonable to great quality, it's packages that (theoretically) save a couple days or weeks that tend to be the real stinkers.

[noahtallen]

I’ve definitely spent a ton of time on dependency work. I think the web app ecosystem is unique compared to its counterparts because the platform is really not designed for applications; it’s designed to render documents. You get so much more out of the box when developing for proper application platforms like iOS. For example, dealing with dates and internationalization. iOS gives you enough tools to not really need an extra library. Not so with the web.

Plus, the std for these platforms is much larger too, because you get access to the huge API surface the platform provides. Apple has spent a significant amount of resources making the platform decent to develop for. They even include reactive UI patterns out of the box now; something you’ll need a library for on web.

I think that’s the real shame. The web platform is very flexible and ubiquitous, so most people try to target it. But in doing so, you’ll need to account for web standards differences across browsers (using a tool like browserslist), the cost of downloading the source code when navigating into a page (with webpack and minification to make bundle sizes more reasonable or split up), and the cost of not having strong default patterns for stateful, interactive UI.

Every other platform will include nearly all of the tools you need within the IDE and on the platform. Web just doesn’t have that, unfortunately, and it has further problems that really don’t exist on other platforms. (For example, other platforms don’t rely on downloading the app source code from a remote server when launching it every time.) It relies on the open source community to provide solutions to so many problems, resulting in the complex dependency trees we see in large apps.

On the one hand, the OSS spirit is admirable. There are competing projects for nearly everything, similar to Linux programs. (Just like there are many Linux dependency managers, there are multiple JS dependency managers.) This allows projects to “get better” by competing with each other, but at the cost of breaking changes and maintenance over time. (For example, there are many projects aiming to provide the fastest JS bundler.) But there is something to be said for having an opinionated platform with more features like iOS or UWP for windows.

All that to say, I don’t think this is a JS shortcoming, but a shortcoming of the web platform in general. And some of those shortcomings are inherent to the benefits of the platform.

[sam0x17]

A side rant: for some reason in recent years it has been OK to make breaking changes. I remember a time when these were considered a nuclear option -- now popular libraries will make breaking changes for minor aesthetic reasons, resulting in billions of wasted developer hours changing foobar to foo_bar.

[rob_c]

Yup, this is what major releases are for and frankly we need more people like Linus reminding people don't break your external APIs!

[sam0x17]

Some projects _never_ make breaking changes, and major version bumps represent major additions.

[rob_c]

Very true and these are the gold standard in some regards. But not everyone has a crystal ball and are beholdant to external factors they don't control. E.g. the pcie bus evolving forces Linux to change, and not all change is bad.

[pca006132]

> At some point it would make sense to include automated googling in the CI pipeline just to add some necessary information to the errors.

Sounds like a decent feature to include in a compiler!

[taurath]

I installed ESLint into a new project and my package.lock file expanded to 3000 lines. I understand what problem it was trying to solve but the sheer inelegance of it sort of gives everything a jank feel, like you have no idea what’s running.

Or perhaps it’s more that it’s exposing a bunch of things that are hidden or tucked in standard libraries in other languages.

[nsonha]

hep me understand this. I need a binary called eslint. I put its version x as a dependency. why can't i just get a fat eslint@x blob of code? Why do I have to care to fetch all eslint's dependencies? is this because they don't "bundle" things like eslint? Should they then?

[austincheney]

> for some reason I don't understand

Fear of writing original code. There is less perceived risk (actual risk is slightly increased) if you can defer blame.

[nsonha]

it's not true that all this mess was caused simply by irrational emotion. There is actual cost involved in writing original code.

[austincheney]

How much?

Until there are numbers, as in qualified by data, its all irrational. It doesn't matter that something costs money. What's important is how much more it costs (the difference).

[nsonha]

People don't add more dependencies into ther code out of fear that's just a weird idea.

I'm not saying I know the cost, I'm just rebutting the comment about this being driven by fear. It's not, this is cost saving, and might be lousy at that, or not data driven.

By the way there is no such thing as "data driven software methodology", no one has ever done such a thing, so asking for it is just rhetorical.

[austincheney]

> People don't add more dependencies into ther code out of fear that's just a weird idea.

Weird or not it is the reason and most commonly expressed as vetted by the community.

> By the way there is no such thing as "data driven software methodology",

There is. A/B testing is a form of that. Running tests and experiments, even against developers, was my job for awhile.

What I find most strange is that this comment expresses the opposite position of your prior comment.

[nsonha]

> vetted by the community

I think that's the reason why a certain 3rd package is chosen.

the decision between roll your own and 3rd package often comes down to whether you want to sidetrack engineering _right now_ to write code that's not your product's functionality.

> A/B testing

you're talking about data driven product decisions. What we are talking about is data driven engineering decisions. Show me one article on such experiment?

the first problem is that there is no data. Last I checked developers are not fond of telemetry in their dev tools.

my point is not that's it isn't desirable. It's just not a thing that exists to bring up in arguments.

there is a difference between emotions (fear) and heuristics (this will cost time and is potentially buggy). I mean they are actually same in nature but at different points on the spectrum.