10 ms·

> The real horsemen of the legacy apocalypse is the depth of the dependency tree. I won't speak for Java or Python. For Node/JS, I do not see this being a prob

> The real horsemen of the legacy apocalypse is the depth of the dependency tree. I won't speak for Java or Python. For Node/JS, I do not see this being a problem for the future. The reason is because npm is so fragile that the entire thing falls over today if you just look at it wrong. The very second you run "npm install" you have a mountain of instant tech debt. The primary reason for this is because the people writing JavaScript do not know what they are doing. They have not cut their teeth on libraries in C/C++ or other languages and have no clue how backwards compatibility or versioning works. If you doubt what I'm saying, then I invite you to do your own quality inspection of any major JS library or framework out there. I'm not going to name names, but the vast majority of it is pure shit. In my experience, JS code has a life expectancy of about a year and a half. Give or take. After that, it is rewritten. Which also contributes to the lack of quality in the JS ecosystem. There is a built-in assumption that this code won't survive past the time your average dev gets bored of it. People, today, do not realize there are JS frameworks that predate React/Angular/etc. and have already died. Once popular frameworks. And I'm not talking jQuery. You don't see them because JS development = churn. You don't even see CoffeeScript mentioned today, and that was just a few years ago.

vturner 6y ago
Recently came back to a React GUI at work. Doing the Docker build is almost comical as the npm red text rolls by :). You would think the thing is surely going to explode. Of course, when you run the app React reminds us of all the new best practices which were non existant 6, 8 months ago
sergiotapia 6y ago
marionette, backbone, knockoutjs! lol the list is endless. in 5 years, react??? who knows.
- jcheng 6y ago
  In fairness, a lot has also changed/churned in Windows desktop UI development, iOS development, and Android development over the same time period. (I know a lot less about the latter two, but didn’t they at least both change languages and see the significant rise of PhoneGap/Titanium and then React Native and then Flutter?) And those are all ecosystems that, for better or worse, have a single dominant corporation lording over it.
zackify 6y ago
I’ve got a 5 year old react app that still gets worked on just fine. It doesn’t need every new state management library. The problem with JS isn’t the major frameworks. It’s people that complain about how many packages exist. This is a consequence of its popularity. Take some time to use the language more, and you won’t be installing packages that are out of date in a month.
- nicbou 6y ago
  The packages aren't directly installed by you. They're installed as dependencies of the frameworks you use.
downerending 6y ago
Ha. I've only had one experience with 'npm' (user requested install), and it went just like that. It seemed to want to install about 500 modules and just exploded half-way through.
Scottopherson 6y ago
Almost every comment thread, regardless of topic, has someone shitting on front-end developers and it's extremely demoralizing.
- speedgoose 6y ago
  I would suggest to ignore them. You read it 10 times and you are fine, it's always the same.
  - brlewis 6y ago
    > it's always the same They're usually the same. This one forgot to flame about how the JS community is supposedly constantly reinventing things real programmers discovered decades ago. I think there's still time to edit that comment into conformance with the JS-bashing standard.
- perlgeek 6y ago
  Same happens with every article about Perl. Or PHP. Or any other technology that people love to hate.
- ptasker 6y ago
  Yup ignore it. Front-end dev is super complex these days! I started when it was just HTML/CSS. JavaScript dev these days is much more complex than some 'real' programming languages!
  - systematical 6y ago
    JavaScript wasn't too complex back in the HTML/CSS days though. Lets be honest, we viewed it as a toy to sprinkle in some slick UI. Then some jQuery scripts started getting really out of control. Then I think ember and angular came out, or maybe it was backbone. Then things just kind of got more and more complex. Webpack is insane to learn. I finally took the time to learn it in isolation with es6, away from the heavy frameworks, and it wasn't so bad. But then when I look at using it with the heavy frameworks it makes me want to run for the hills. I was playing around with puppeteer recently, which is a fantastic tool. It's perfect for what I needed. After I put together an ugly procedural proof of concept I wanted to figure out how to do things right and move it into classes. It's an adventure figuring out the right way to layout a project or even the right way to build a class. The fact that there isn't an authoritative answer tells me the eco-system is not mature or maybe I just didn't Google it right. Meanwhile, PHP has https://www.php-fig.org/psr/ https://www.php-fig.org/psr/. So anytime I can't remember how to name an Interface or an Abstract or anything really, I just google $blah + php psr. JavaScript is a shitshow that I have to live with, unfortunately. I know its funny coming from a guy that just used PHP as example for good language design, but at least the community has coalesced around standards...and composer > npm. Its to the point now that I actively avoid making dynamic pages and SPAs AT ALL COSTS. It reduces the complexity of the code a ton that way. Thats not to say I haven't. I used VueJS for a big SPA because marketing wanted feature sets that required it. I fought it and lost. VueJS wasn't so bad, at least the learning curve was less than React, but SPAs are still terribad. Yuck.
viklove 6y ago
I love seeing these opinions on HN, it means my job as a qualified JS dev is very, very secure. If you work at a place that has problems with npm deps, just understand that the problem is your team, not the ecosystem. Choose which tools you use, and choose carefully my friends.
- mywittyname 6y ago
  Software developers have been rewriting legacy codebases since forever. My early career was spent bouncing in and out of projects that the customer deemed in need of a rewrite. If it was perl, it needed to be replaced with Java. When it was Java, it had to be replaced by Ruby. And now all the Ruby needs to be replaced with JS. Now that we are stuck with JS, devs are just finding new reasons to rewrite stuff. PHP projects never seemed in need of a rewrite.
  - phist_mcgee 6y ago
    That last line! Oh boy have I seen some PHP projects rushed out that sure do live by the skin of their teeth. They really do need a rewrite.
chc 6y ago
I think "a few years" is a bit of an understatement. CoffeeScript came out one year after Google Chrome, in the heyday of Ruby on Rails. The entire web development landscape has shifted a lot since then.
- mywittyname 6y ago
  That kind of supports the parent comment. RoR is not even that old and, "the development landscape has shifted a lot since then."
  - chc 6y ago
    It would support the parent comment if the point of the parent comment had been something like "The state of the web has changed a lot since 2005," but it wasn't. The parent comment was specifically castigating the JavaScript ecosystem for having so much "churn" "because the people writing JavaScript do not know what they are doing." Ruby on Rails is not a JavaScript framework, so if there's been lots of change throughout the web ecosystem in same timeframe, how does showing the same trend reflect negatively on JavaScript developers in particular? It seems a bit like pointing to somebody in an earthquake and yelling at them to stop moving around.
    - majormajor 6y ago
      Yes, it was bad then, too. Doesn't seem like much of the Node ecosystem learned from that, though. Rails projects were pretty famously brittle and painful to deal with for doing major upgrades. I've moved to JVM-land and don't miss that part of working with Rails, though there are still things I miss about Ruby. But everything my coworkers tell me about Node projects sounds like it's even worse than Rails was.
_bxg1 6y ago
> The primary reason for this is because the people writing JavaScript do not know what they are doing. Hello. I'm a JavaScript programmer who cut my teeth on Java twelve years ago, followed by C++ two years later and throughout the course of my Computer Science program, and over the years I've done personal work in half a dozen other languages including Rust, Clojure, Python, C#, etc. Despite all of that TypeScript remains by go-to general-purpose language of choice, for any arbitrary project without particular constraints. Take your flame-bait elsewhere, please.
- jagged-chisel 6y ago
  I'm interested in your take wrt to the dependency hell GP mentions.
  - brundolf 6y ago
    Personally, I: 1) Keep my direct dependency list slim and mostly limited to "too big to fail" projects backed by major companies 2) Avoid frameworks in favor of libraries I don't stress about indirect dependencies. If one of React's dependencies stops being maintained, or has a security problem or a bug, Facebook isn't going to not address it. Far too much money is riding on React as a whole, so whether they have to switch to a new dependency, or update the version, or reimplement the functionality themselves, they will. On top of this, the left-pad catastrophe can't happen again, because NPM publications are now impossible to remove after 72 hours: https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish On the other hand I'm not going to add a direct dependency that I don't truly need. If it's a one-off function that I can write myself, or copy, I'll do so. On time I copied and pasted Lodash's debounce function into my codebase because that was all I needed, and I didn't want to bring in the whole library. Libraries, compared with frameworks, are easier to predict, to fill gaps in, and to replace if necessary. And even some things that we call ""frameworks"" like React can really be used as libraries. If you only use React as a rendering layer - what it's best at anyway - it actually has a very thin and elegant boundary with your code: you construct a data structure, and you hand it off. Others, like Angular and Aurelia, are truly frameworks and I tend to avoid them as a result. I wrote a blog post recently about the libraries/frameworks thing which got some attention/discussion here on HN: http://www.brandonsmith.ninja/blog/libraries-not-frameworks http://www.brandonsmith.ninja/blog/libraries-not-frameworks
vmception 6y ago
> The primary reason for this is because the people writing JavaScript do not know what they are doing. > Hmm I can't get hired at all these companies with 20-30 year olds heavily dependent on Javascript, this must be age discrimination.
joekrill 6y ago
This sounds like the sort of thing I hear from folks who have only passively dealt with the Javascript ecosystem but somehow still seem to think they have a really great handle on the entire situation, how it got there, what exactly the root of the problems are, and (sometimes) how it can be fixed. And while I partially agree in some cases, I don't think this is in any way a problem specific to the JS ecosystem. There is definitely a lack of quality in a whole lot of JavaScript code out there. But I've also seen TONS of horribly written Ruby gems, .Net libraries, Java apps, even Dockerfiles. It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Even the early Android days were plagued with tons of horrible options for networking libraries, SQLite helpers, or whatever else wasn't fleshed out well. And that was just the _platform_ maturing with a language that was already quite mature. With JS you have not only the language itself maturing and changing rather quickly, but also all the underlying platforms, package management systems, security issues, etc. Patterns, best practices, and standards often take quite a while to surface and become established. And they seem so obvious in hindsight! Which is why I think we get a lot of people coming from other ecosystems who seem to have selectively forgotten about that happening in their own established tech niche.
- vlovich123 6y ago
  That could be the case. It could also be the case that those deeply rooted in the Javascript ecosystem aren't listening to domain experts. The numerous security problems with how NPM installs dependencies was pointed out as problematic from the get go by language maintainers, package manager maintainers, & security experts from other projects. I think it's possible that Javascript is getting better & more responsive here & I bet at least some of the defensiveness was that it has also been unfairly criticized which makes it hard to separate signal from noise.
- brazzy 6y ago
  > It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Even the early Android days were plagued with Node is about half a year younger than Android, and npm another half year. Javascript is, of course, over a decade older. If JS, Node, NPM, etc is "still maturing" after all that time, then that is a pretty strong indication that there is something wrong with that ecosystem.
tengbretson 6y ago
I used to think backbone was kind of cool! RIP I guess.
- Cthulhu_ 6y ago
  It was, at the time - this was right before Angular, then React made a splash, but before those became mainstream, Backbone was a really good framework to be using. Plus, both Angular and React kinda relied on the performance of JS engines becoming what they are nowadays.
gyrgtyn 6y ago
ZZZZZZzzzz
quonn 6y ago
> In my experience, JS code has a life expectancy of about a year and a half. Maybe for toy projects. I‘m working on projects that take years to build and are around for many years. There are problems with JS but with TypeScript and React I find it more maintainable and robust than other languages. The worst project I‘ve worked on in the last few years had 800k lines of C# around a C++ core from the early 90s. It was terrible to work with and far worse than anything I‘ve seen in the Javascript world.
- systematical 6y ago
  Probably because its nearly 40 years old now.... Find me when we have the first large scale JavaScript project that is forty years old.
corford 6y ago
I've been programming since the late 90s and as recently as one or two years ago I would have agreed with a lot of this. However, having recently come back to JS and currently in the midst of developing a large, complex non-frontend app in it; I have to say the language, tooling, standards and ecosystem have jumped forward significantly. It has honestly been a pleasure building this out. Yes, you still need to be selective about dependencies but that's the case for many languages. Beyond that, JS/Node in 2020 (in the right hands and for the right project) is pretty awesome.
- dijit 6y ago
  The parent is not decrying developing things right now. They are suggesting that what is built will not survive a very long time. It would be more interesting if you had picked up a 3yr old project and could tell us your experience with that; failing this it would only be interesting if you come back in a few years to tell us how it is.
  - corford 6y ago
    >They are suggesting that what is built will not survive a very long time. I suspect that thanks to the recent jumps forward (language itself, common best practices, tooling) that this argument doesn't hold as much weight as it once did. I see a lot of JS library code today that looks eminently supportable and survivable beyond a ~3yr time horizon.
    - dijit 6y ago
      I would like to agree, but given that we have no evidence for this and a history that has not supported this assertion- we cannot make that claim. Only time will tell.
  - cmrdporcupine 6y ago
    Honestly what the post author is describing sounds about my experience with the Java + Maven deps world about 10 years ago when I last used it. A giant trail of dependencies of questionable quality (and how many problems with commons-logging?). I have no desire to write JS, really, but it doesn't sound unfamiliar.
noobermin 6y ago
Not sure I understand this post. You say it isn't a problem for the future but then go on to say it is a problem.
- samcodes 6y ago
  He’s saying it’s not a problem for the future, because that implies it’s not a problem now, which he asserts that it is. It’s humor
skrebbel 6y ago
I totally disagree but I just want to compliment you on a delightfully written comment. I laughed out loud multiple times.

vturner 6y ago

Recently came back to a React GUI at work. Doing the Docker build is almost comical as the npm red text rolls by :). You would think the thing is surely going to explode. Of course, when you run the app React reminds us of all the new best practices which were non existant 6, 8 months ago

sergiotapia 6y ago

marionette, backbone, knockoutjs! lol the list is endless. in 5 years, react??? who knows.

jcheng 6y ago
In fairness, a lot has also changed/churned in Windows desktop UI development, iOS development, and Android development over the same time period. (I know a lot less about the latter two, but didn’t they at least both change languages and see the significant rise of PhoneGap/Titanium and then React Native and then Flutter?) And those are all ecosystems that, for better or worse, have a single dominant corporation lording over it.

zackify 6y ago

I’ve got a 5 year old react app that still gets worked on just fine. It doesn’t need every new state management library. The problem with JS isn’t the major frameworks. It’s people that complain about how many packages exist. This is a consequence of its popularity. Take some time to use the language more, and you won’t be installing packages that are out of date in a month.

nicbou 6y ago
The packages aren't directly installed by you. They're installed as dependencies of the frameworks you use.

downerending 6y ago

Ha. I've only had one experience with 'npm' (user requested install), and it went just like that. It seemed to want to install about 500 modules and just exploded half-way through.

Scottopherson 6y ago

Almost every comment thread, regardless of topic, has someone shitting on front-end developers and it's extremely demoralizing.

speedgoose 6y ago
I would suggest to ignore them. You read it 10 times and you are fine, it's always the same.
- brlewis 6y ago
  > it's always the same They're usually the same. This one forgot to flame about how the JS community is supposedly constantly reinventing things real programmers discovered decades ago. I think there's still time to edit that comment into conformance with the JS-bashing standard.
perlgeek 6y ago
Same happens with every article about Perl. Or PHP. Or any other technology that people love to hate.
ptasker 6y ago
Yup ignore it. Front-end dev is super complex these days! I started when it was just HTML/CSS. JavaScript dev these days is much more complex than some 'real' programming languages!
- systematical 6y ago
  JavaScript wasn't too complex back in the HTML/CSS days though. Lets be honest, we viewed it as a toy to sprinkle in some slick UI. Then some jQuery scripts started getting really out of control. Then I think ember and angular came out, or maybe it was backbone. Then things just kind of got more and more complex. Webpack is insane to learn. I finally took the time to learn it in isolation with es6, away from the heavy frameworks, and it wasn't so bad. But then when I look at using it with the heavy frameworks it makes me want to run for the hills. I was playing around with puppeteer recently, which is a fantastic tool. It's perfect for what I needed. After I put together an ugly procedural proof of concept I wanted to figure out how to do things right and move it into classes. It's an adventure figuring out the right way to layout a project or even the right way to build a class. The fact that there isn't an authoritative answer tells me the eco-system is not mature or maybe I just didn't Google it right. Meanwhile, PHP has https://www.php-fig.org/psr/ https://www.php-fig.org/psr/. So anytime I can't remember how to name an Interface or an Abstract or anything really, I just google $blah + php psr. JavaScript is a shitshow that I have to live with, unfortunately. I know its funny coming from a guy that just used PHP as example for good language design, but at least the community has coalesced around standards...and composer > npm. Its to the point now that I actively avoid making dynamic pages and SPAs AT ALL COSTS. It reduces the complexity of the code a ton that way. Thats not to say I haven't. I used VueJS for a big SPA because marketing wanted feature sets that required it. I fought it and lost. VueJS wasn't so bad, at least the learning curve was less than React, but SPAs are still terribad. Yuck.

viklove 6y ago

I love seeing these opinions on HN, it means my job as a qualified JS dev is very, very secure. If you work at a place that has problems with npm deps, just understand that the problem is your team, not the ecosystem. Choose which tools you use, and choose carefully my friends.

mywittyname 6y ago
Software developers have been rewriting legacy codebases since forever. My early career was spent bouncing in and out of projects that the customer deemed in need of a rewrite. If it was perl, it needed to be replaced with Java. When it was Java, it had to be replaced by Ruby. And now all the Ruby needs to be replaced with JS. Now that we are stuck with JS, devs are just finding new reasons to rewrite stuff. PHP projects never seemed in need of a rewrite.
- phist_mcgee 6y ago
  That last line! Oh boy have I seen some PHP projects rushed out that sure do live by the skin of their teeth. They really do need a rewrite.

chc 6y ago

I think "a few years" is a bit of an understatement. CoffeeScript came out one year after Google Chrome, in the heyday of Ruby on Rails. The entire web development landscape has shifted a lot since then.

mywittyname 6y ago
That kind of supports the parent comment. RoR is not even that old and, "the development landscape has shifted a lot since then."
- chc 6y ago
  It would support the parent comment if the point of the parent comment had been something like "The state of the web has changed a lot since 2005," but it wasn't. The parent comment was specifically castigating the JavaScript ecosystem for having so much "churn" "because the people writing JavaScript do not know what they are doing." Ruby on Rails is not a JavaScript framework, so if there's been lots of change throughout the web ecosystem in same timeframe, how does showing the same trend reflect negatively on JavaScript developers in particular? It seems a bit like pointing to somebody in an earthquake and yelling at them to stop moving around.
  - majormajor 6y ago
    Yes, it was bad then, too. Doesn't seem like much of the Node ecosystem learned from that, though. Rails projects were pretty famously brittle and painful to deal with for doing major upgrades. I've moved to JVM-land and don't miss that part of working with Rails, though there are still things I miss about Ruby. But everything my coworkers tell me about Node projects sounds like it's even worse than Rails was.

_bxg1 6y ago

> The primary reason for this is because the people writing JavaScript do not know what they are doing. Hello. I'm a JavaScript programmer who cut my teeth on Java twelve years ago, followed by C++ two years later and throughout the course of my Computer Science program, and over the years I've done personal work in half a dozen other languages including Rust, Clojure, Python, C#, etc. Despite all of that TypeScript remains by go-to general-purpose language of choice, for any arbitrary project without particular constraints. Take your flame-bait elsewhere, please.

jagged-chisel 6y ago
I'm interested in your take wrt to the dependency hell GP mentions.
- brundolf 6y ago
  Personally, I: 1) Keep my direct dependency list slim and mostly limited to "too big to fail" projects backed by major companies 2) Avoid frameworks in favor of libraries I don't stress about indirect dependencies. If one of React's dependencies stops being maintained, or has a security problem or a bug, Facebook isn't going to not address it. Far too much money is riding on React as a whole, so whether they have to switch to a new dependency, or update the version, or reimplement the functionality themselves, they will. On top of this, the left-pad catastrophe can't happen again, because NPM publications are now impossible to remove after 72 hours: https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish On the other hand I'm not going to add a direct dependency that I don't truly need. If it's a one-off function that I can write myself, or copy, I'll do so. On time I copied and pasted Lodash's debounce function into my codebase because that was all I needed, and I didn't want to bring in the whole library. Libraries, compared with frameworks, are easier to predict, to fill gaps in, and to replace if necessary. And even some things that we call ""frameworks"" like React can really be used as libraries. If you only use React as a rendering layer - what it's best at anyway - it actually has a very thin and elegant boundary with your code: you construct a data structure, and you hand it off. Others, like Angular and Aurelia, are truly frameworks and I tend to avoid them as a result. I wrote a blog post recently about the libraries/frameworks thing which got some attention/discussion here on HN: http://www.brandonsmith.ninja/blog/libraries-not-frameworks http://www.brandonsmith.ninja/blog/libraries-not-frameworks

vmception 6y ago

> The primary reason for this is because the people writing JavaScript do not know what they are doing. > Hmm I can't get hired at all these companies with 20-30 year olds heavily dependent on Javascript, this must be age discrimination.

joekrill 6y ago

This sounds like the sort of thing I hear from folks who have only passively dealt with the Javascript ecosystem but somehow still seem to think they have a really great handle on the entire situation, how it got there, what exactly the root of the problems are, and (sometimes) how it can be fixed. And while I partially agree in some cases, I don't think this is in any way a problem specific to the JS ecosystem. There is definitely a lack of quality in a whole lot of JavaScript code out there. But I've also seen TONS of horribly written Ruby gems, .Net libraries, Java apps, even Dockerfiles. It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Even the early Android days were plagued with tons of horrible options for networking libraries, SQLite helpers, or whatever else wasn't fleshed out well. And that was just the _platform_ maturing with a language that was already quite mature. With JS you have not only the language itself maturing and changing rather quickly, but also all the underlying platforms, package management systems, security issues, etc. Patterns, best practices, and standards often take quite a while to surface and become established. And they seem so obvious in hindsight! Which is why I think we get a lot of people coming from other ecosystems who seem to have selectively forgotten about that happening in their own established tech niche.

vlovich123 6y ago
That could be the case. It could also be the case that those deeply rooted in the Javascript ecosystem aren't listening to domain experts. The numerous security problems with how NPM installs dependencies was pointed out as problematic from the get go by language maintainers, package manager maintainers, & security experts from other projects. I think it's possible that Javascript is getting better & more responsive here & I bet at least some of the defensiveness was that it has also been unfairly criticized which makes it hard to separate signal from noise.
brazzy 6y ago
> It is just much more prevalent when those ecosystems are still "maturing" - which I think JS, Node, NPM, etc still very much are. Even the early Android days were plagued with Node is about half a year younger than Android, and npm another half year. Javascript is, of course, over a decade older. If JS, Node, NPM, etc is "still maturing" after all that time, then that is a pretty strong indication that there is something wrong with that ecosystem.

tengbretson 6y ago

I used to think backbone was kind of cool! RIP I guess.

Cthulhu_ 6y ago
It was, at the time - this was right before Angular, then React made a splash, but before those became mainstream, Backbone was a really good framework to be using. Plus, both Angular and React kinda relied on the performance of JS engines becoming what they are nowadays.

gyrgtyn 6y ago

ZZZZZZzzzz

quonn 6y ago

> In my experience, JS code has a life expectancy of about a year and a half. Maybe for toy projects. I‘m working on projects that take years to build and are around for many years. There are problems with JS but with TypeScript and React I find it more maintainable and robust than other languages. The worst project I‘ve worked on in the last few years had 800k lines of C# around a C++ core from the early 90s. It was terrible to work with and far worse than anything I‘ve seen in the Javascript world.

systematical 6y ago
Probably because its nearly 40 years old now.... Find me when we have the first large scale JavaScript project that is forty years old.

corford 6y ago

I've been programming since the late 90s and as recently as one or two years ago I would have agreed with a lot of this. However, having recently come back to JS and currently in the midst of developing a large, complex non-frontend app in it; I have to say the language, tooling, standards and ecosystem have jumped forward significantly. It has honestly been a pleasure building this out. Yes, you still need to be selective about dependencies but that's the case for many languages. Beyond that, JS/Node in 2020 (in the right hands and for the right project) is pretty awesome.

dijit 6y ago
The parent is not decrying developing things right now. They are suggesting that what is built will not survive a very long time. It would be more interesting if you had picked up a 3yr old project and could tell us your experience with that; failing this it would only be interesting if you come back in a few years to tell us how it is.
- corford 6y ago
  >They are suggesting that what is built will not survive a very long time. I suspect that thanks to the recent jumps forward (language itself, common best practices, tooling) that this argument doesn't hold as much weight as it once did. I see a lot of JS library code today that looks eminently supportable and survivable beyond a ~3yr time horizon.
  - dijit 6y ago
    I would like to agree, but given that we have no evidence for this and a history that has not supported this assertion- we cannot make that claim. Only time will tell.
- cmrdporcupine 6y ago
  Honestly what the post author is describing sounds about my experience with the Java + Maven deps world about 10 years ago when I last used it. A giant trail of dependencies of questionable quality (and how many problems with commons-logging?). I have no desire to write JS, really, but it doesn't sound unfamiliar.

noobermin 6y ago

Not sure I understand this post. You say it isn't a problem for the future but then go on to say it is a problem.

samcodes 6y ago
He’s saying it’s not a problem for the future, because that implies it’s not a problem now, which he asserts that it is. It’s humor

skrebbel 6y ago

I totally disagree but I just want to compliment you on a delightfully written comment. I laughed out loud multiple times.