[symboltoproc]

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.

[forty]

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

[simion314]

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.

[reindeerer]

Also, your average npm module packages incredibly small amounts of functionality, making dependency trees huge and hence also very brittle.

[pjmlp]

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.

[chrisco255]

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.

[pjmlp]

Not for our customers that keep happily using solutions based on Java and .NET platforms.

[StreamBright]

You must be joking. I never heard of Express and we have put several REST APIs into production in several companies.

[y4mi]

Uh, what?

It might've become the defacto standard for consuming them, but definitely not for creating them.

Almost no service I've ever administered used a nodejs backend.

[tomnipotent]

He never said anything about node being prevalent, only that Express was within node.

[no_wizard]

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]

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]

Rust has also embraced the very small packages mentality more and more, and it's already showing, things turn far more brittle quickly

[IloveHN84]

"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]

You're free not to work on backend javascript (or other interpreted languages) but many people would (and do) disagree with you.

[klibertp]

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