Hacker News new | past | comments | ask | show | jobs | submit login

JavaScript has the unfortunate situation of having years upon years of terrible standard library design, leading to people building lots of small libraries on top of those libraries to get things that were basic functionality in other languages.

Then people started stacking more and more things on top of those libraries, creating a giant dependency morass of microdependencies that larger frameworks are now build on top of. And because all these frameworks do things just different enough from each other, every larger library that a dev would want to integrate with those frameworks now needs a specialized version to work with those frameworks.

In most languages, if you want to know how something works, you can usually dig into your dependency tree and by the time you hit the stdlib's optimization spaghetti/language internals, you'll probably have figured out what's causing your snag/what the library is expecting out of you. In JavaScript, you hit the dependency morass and have to give up. Most competent devs then decide to pick another language.

You can write very legible JavaScript these days, even without a framework, but it looks nothing like JavaScript used in a framework.

The other language I know of with this issue is, ironically, Rust.




Please explain the rust angle?


Similar "lots of microdependencies" issue, born in Rusts case from the desire to keep a conservatively sized standard library. It's a smaller problem in the sense that Rust has stronger API contracts as opposed to the absolute disaster that NodeJS is, but in terms of code comprehension you hit a similar dependency morass.

The one thing salvaging Rust for now is a lack of similar frameworks, but who knows how long that will last.


The implication is that Rust's conservatism regarding what is blessed to go into the standard library sets up a similar dynamic.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: