4 ms·

The JavaScript Fatigue argument is not good. There's simply no data that backs it and nobody is forced to use new libraries only because they use JavaScript. I

The JavaScript Fatigue argument is not good. There's simply no data that backs it and nobody is forced to use new libraries only because they use JavaScript. I've seen third party dependencies churn on Elixir as well (packages that are no longer maintained or alternatives that are better) - I think it's an inherent problem with using dependencies and has nothing to do with the programming language in which those dependencies are written. > As a developer I just want to get on with my work, not have to read another Hackernoon post on how everything from last week is obsolete because XYZ framework My recommendation is that you don't read Hackernoon. This seems like a very ineffective way to level up your developer skills. Edit: I agree that Elixir is very nice and would pick it over JavaScript for backend heavy applications without thinking. I just don't think this argument makes any sense in that context.

IloveHN84 8y ago
"backend" and "JavaScript" quite don't fit together in the same phrase. I would never work on backend with JavaScript or any other interpreted language, due to error proness.
- marcinzm 8y ago
  You're free not to work on backend javascript (or other interpreted languages) but many people would (and do) disagree with you.
- deleted 8y ago
  [deleted]
- klibertp 8y ago
  > interpreted language, due to error proness. There is no connection, at all, between a language being interpreted and it being error-prone to write or run. You either mean something else or are mistaken.
forty 8y ago
> nobody is forced to use new libraries only because they use JavaScript. It's not completely true IMO for 2 reasons: 1- the nodejs standard lib is quite poor compared to say, Java's, Scala's or python's, so you generally need quite a lot of modules to do anything 2- the npm ecosystem is much more amateur. To do anything you have a ton of poorly supported by hobbyists or not supported at all modules. This can force you to change modules/libs regularly. This is to be compared to the Java ecosystem for example, were more people are working together to build well supported/high quality libs (Apache libraries for example)
- pjmlp 8y ago
  This is why many of us do the sane thing and leave JavaScript to the browser, while enjoying server side rendering with a bit of dynamism.
- simion314 8y ago
  Exactly, it is impossible to use a stable long term Linux distribution and node, most packages force you to get the latest or before latest version of node. Other issue is that things move fast and break, you are not sure that 3 months old tutorial will work in present. Edit: I know I can and I did grabbed node and npm outside the repositories, but you do not see this issue with other languages where I must install latest stuff to get most libraries working.
  - exactly 8y ago
    Exactly.
- chrisco255 8y ago
  Yeah but on Node.js, Express has been the de facto framework of choice for building REST APIs for over 6 years. The JS fatigue phenomenon was mostly on the front end, and even that has basically settled down as people have rallied around React, Angular and Vue.
  - y4mi 8y ago
no_wizard 8y ago
I’m not calling out JS or elixir communities by any means here. I just want to mention that a big part of the “JavaScript Fatigue” is the amount of overlapping libraries that all do the same thing and it isn’t always straightforward to figure out which one is better - and this happens with so many packages it would be impossible to do it with all of them. Just look up “isArray” (which I wish where just not showing up in libs at this point. It’s a built in in both node and the browser now) and you get 102 packages that are very similar but will clearly vary in implementation and quality. Where as something like the Python community or Rust community (where I have had more experience) I have always found that even if there are packages that do the same thing, there usually aren’t nearly as many duplicates and often times the community has done a better job communicating the value of many of the packages. There is just less confusion around the whole thing I have also found there to be relatively little overlap between the big packages, in my experience
- chrisco255 8y ago
  It's no more difficult than choosing an app in the app store. You go on NPM, you look at the download count, you look at the feature set, you install and then move on with your day. JS is a vast and very open ecosystem so duplication is inevitable.
- reindeerer 8y ago
  Rust has also embraced the very small packages mentality more and more, and it's already showing, things turn far more brittle quickly

IloveHN84 8y ago

"backend" and "JavaScript" quite don't fit together in the same phrase. I would never work on backend with JavaScript or any other interpreted language, due to error proness.

marcinzm 8y ago
You're free not to work on backend javascript (or other interpreted languages) but many people would (and do) disagree with you.
deleted 8y ago
[deleted]
klibertp 8y ago
> interpreted language, due to error proness. There is no connection, at all, between a language being interpreted and it being error-prone to write or run. You either mean something else or are mistaken.

forty 8y ago

> nobody is forced to use new libraries only because they use JavaScript. It's not completely true IMO for 2 reasons: 1- the nodejs standard lib is quite poor compared to say, Java's, Scala's or python's, so you generally need quite a lot of modules to do anything 2- the npm ecosystem is much more amateur. To do anything you have a ton of poorly supported by hobbyists or not supported at all modules. This can force you to change modules/libs regularly. This is to be compared to the Java ecosystem for example, were more people are working together to build well supported/high quality libs (Apache libraries for example)

pjmlp 8y ago
This is why many of us do the sane thing and leave JavaScript to the browser, while enjoying server side rendering with a bit of dynamism.
simion314 8y ago
Exactly, it is impossible to use a stable long term Linux distribution and node, most packages force you to get the latest or before latest version of node. Other issue is that things move fast and break, you are not sure that 3 months old tutorial will work in present. Edit: I know I can and I did grabbed node and npm outside the repositories, but you do not see this issue with other languages where I must install latest stuff to get most libraries working.
- exactly 8y ago
  Exactly.
chrisco255 8y ago
Yeah but on Node.js, Express has been the de facto framework of choice for building REST APIs for over 6 years. The JS fatigue phenomenon was mostly on the front end, and even that has basically settled down as people have rallied around React, Angular and Vue.
- y4mi 8y ago

no_wizard 8y ago

I’m not calling out JS or elixir communities by any means here. I just want to mention that a big part of the “JavaScript Fatigue” is the amount of overlapping libraries that all do the same thing and it isn’t always straightforward to figure out which one is better - and this happens with so many packages it would be impossible to do it with all of them. Just look up “isArray” (which I wish where just not showing up in libs at this point. It’s a built in in both node and the browser now) and you get 102 packages that are very similar but will clearly vary in implementation and quality. Where as something like the Python community or Rust community (where I have had more experience) I have always found that even if there are packages that do the same thing, there usually aren’t nearly as many duplicates and often times the community has done a better job communicating the value of many of the packages. There is just less confusion around the whole thing I have also found there to be relatively little overlap between the big packages, in my experience

chrisco255 8y ago
It's no more difficult than choosing an app in the app store. You go on NPM, you look at the download count, you look at the feature set, you install and then move on with your day. JS is a vast and very open ecosystem so duplication is inevitable.
reindeerer 8y ago
Rust has also embraced the very small packages mentality more and more, and it's already showing, things turn far more brittle quickly