Live data from Hacker News

The JavaScript ecosystem is a hot mess and so is software development

nadh.in

81–90 of 94 posts

Re: The JavaScript ecosystem is a hot mess and so is software development

#81

I can definitely appreciate rants like this, and I think anyone who has been in JS development for a while has hit some sort of dependency incompatibility headache like this. That said, I'm also always left a bit annoyed when the author isn't really introspective to think about what benefits came with the environment he is bitching about. As much as everyone loves to complain about "dependency hell" in the JS/Node ec…

You are 100% right. People simply want everything: rich, flexible and robust API's. That's not possible. Pick 2, not 3. Also think of the time you have saved by building on top of so many building blocks. Everything's a trade-off.

Re: The JavaScript ecosystem is a hot mess and so is software development

#82

This reads more like an issue with Vue (social, not technical) than a valid criticism of the JS ecosystem. Vue.js is a great project for front-end enthusiasts, but if you look at business objectives (aka getting things done) you would want to use React for any web app: The ecosystem in terms of libraries, help articles, developers is at least 10x bigger. The release of Vue 3 definitely makes this situation worse for…

I disagree. The React API arguably changed more often than Vue. Remember the migration path from class based components > functional components > overly complicated React Hooks? And how about styling components? There are millions of ways doing it. Let alone the fact that routing and state stores don't have any first party support.

Vue in that sense is really simple: Vue + vue-router + Vuex still work together in the exact same way as they did 5 years ago.

Re: The JavaScript ecosystem is a hot mess and so is software development

#84

I can definitely appreciate rants like this, and I think anyone who has been in JS development for a while has hit some sort of dependency incompatibility headache like this. That said, I'm also always left a bit annoyed when the author isn't really introspective to think about what benefits came with the environment he is bitching about. As much as everyone loves to complain about "dependency hell" in the JS/Node ec…

> As much as everyone loves to complain about "dependency hell" in the JS/Node ecosystem, the fact that there are tons of high quality (or, at least discernible quality) components, largely for free, is something that really didn't exist before say the mid '00s. CPAN for Perl and Java's rich set of libraries come to mind from before the mid 2000's.

Actually, I think the comparison to Java is a good one. Java had a pretty good standard library in the JDK (though I'd argue the latest ES and Node versions are pretty on par), but what it really had going for it was Apache Jakarta libraries. I think pretty much 95%+ of open source Java I used at that time was Jakarta.

The difference with JS is that there are actually a ton more open source libraries available in the NPM world, but there is not an overarching project to bless some of them as "standard" and high quality (though I could see some of the Deno libs changing this). Again, it's a tradeoff - there is much more choice but that requires more management.

Also, FWIW, I had many more dependency upgrade nightmares in Java vs. JS, primarily because Java's nominal typing can be very unforgiving (vs. Typescript's structural typing). I still have PTSD from Jersey 1.x to 2 upgrades.

Re: The JavaScript ecosystem is a hot mess and so is software development

#86
post #9

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 wr…

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.

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?

Re: The JavaScript ecosystem is a hot mess and so is software development

#87

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 wr…

> 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.

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

Re: The JavaScript ecosystem is a hot mess and so is software development

#88
post #87

Earlier quoted context omitted.

> 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.

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

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).

Re: The JavaScript ecosystem is a hot mess and so is software development

#89
post #87

Earlier quoted context omitted.

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

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).

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.

Re: The JavaScript ecosystem is a hot mess and so is software development

#90
post #89

Earlier quoted context omitted.

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).

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.

> 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.

Post reply on HN