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…
The JavaScript ecosystem is a hot mess and so is software development
81–90 of 94 posts
Re: The JavaScript ecosystem is a hot mess and so is software development
#82This 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…
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
#83Re: The JavaScript ecosystem is a hot mess and so is software development
#84I 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.
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
#85I know this was meant to be rhetorical...but the answer is YES! ABSOLUTELY!
Re: The JavaScript ecosystem is a hot mess and so is software development
#86This 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.
Re: The JavaScript ecosystem is a hot mess and so is software development
#87This 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.
Re: The JavaScript ecosystem is a hot mess and so is software development
#88Earlier 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.
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
#89Earlier 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).
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
#90Earlier 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.
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.