4 ms·

The absolute worst in my small experience with it is anything touching the node ecosystem. Try to follow any guide or use any library not updated in the last we

The absolute worst in my small experience with it is anything touching the node ecosystem. Try to follow any guide or use any library not updated in the last week and there will be breaking API changes and deprecation warnings everywhere.

LoSboccacc 6y ago
try using four libraries and chances are they require two different version of a build tool installed globally
kungato 6y ago
The sad part about the js ecosystem is that even the biggest corps like Google can't keep their own js ecosystem stable on the last version. I have a small Angular app with Firebase backend and every time I come back to it to update, the libs are out of sync
- nicoburns 6y ago
  Google aren't very good at this, but Facebook are. Maybe give React a try.
- joepie91_ 6y ago
  Google is notoriously bad at maintaining (or even designing) their open-source stuff. I wouldn't say "even the biggest corps like Google" -- Google does considerably worse at this than many hobbyist maintainers! I just don't use Google libraries anymore, if I can at all avoid it. See also my other comment[1] - Angular is an example of such a magical does-everything framework. [1] https://news.ycombinator.com/item?id=24168279 https://news.ycombinator.com/item?id=24168279
  - nl 6y ago
    Tensorflow is another example of this.
  - RonanTheGrey 6y ago
    We've abandoned an app because of the inability to keep Firebase working on it (JS libraries). Between out of sync Typescript definitions, broken APIs, broken interfaces, "this version of some other dependency works with this version of Firebase thanks to some random transient dependency", it just became too much. We won't use the JS libraries at all anymore. Angular is the only one that has remained even remotely usable, but certainly not stable. It's never as simple as running the upgrade utilities, changing the version, and being done. It ALWAYS takes at least a day to find all the "little" things they didn't feel fit to mention in the upgrade docs. It's aggravating. I genuinely don't like using Google software, at all. I've felt for a long time that Google is coasting on the momentum of the early web and the awe people felt for what they built early on. That hasn't been Google for a long, long time.
  - sukilot 6y ago
    Google was better when they were smaller. Java Guava rules.
BossingAround 6y ago
I'm running into this problem more and more. It seems like Node is fundamentally unusable for anything but the nimblest teams that do not mind updating their dependencies automatically, every week, and when something breaks, they are capable of fixing it within hours. I really like Node as a language (especially with TS), but Node as an ecosystem feels like a very hard fit into 90%+ of corporations.
- nicoburns 6y ago
  I think the culture of Node comes from the earlier culture of in-browser JavaScript. When running on the browser platform you have to make sure your libraries are up to date and maintained, otherwise you're at the mercy of browser updates breaking things from under your feet (this is less bad now, but it was awful in the days of IE<9, and on android before they started shipping auto-updating Chrome webview) Consequently, JavaScript developers got used to the burden of maintenance and rapidly updating to the latest versions of libraries, and this culture carried through to Node (partly because a lot of libraries are shared between node and the web). Having said that, if you pick your libraries well, it's not too bad these days. When I upgraded from Node 12 to Node 14 earlier this year, I had to upgrade the `pg` package to a newer version that supported Node 14 (there was one available), but I didn't have to make any code changes. And other than that I've had no forced version upgrades in a long time. I guess if you're lookig at 5-10 year timescales with literaly no maintenance then this would be a different matter though.
  - dutchmartin 6y ago
    I strongly feel that you must have end to end tests while using node because of the dependency hell. Not even knowing if a upgrade of a dependency breaks your system is just hard. Also testing it by hand is just not maintainable.
    - joepie91_ 6y ago
      > Not even knowing if a upgrade of a dependency breaks your system is just hard. This is true for any language/platform.
joepie91_ 6y ago
This is only a problem in some parts of the ecosystem - but they are the parts that most 'tutorials' are written about, because they look shiny and fancy. If I'm blunt, they're the parts of the ecosystem that HN loves to gloat about in their "how I saved my company thousands of dollars by building a todo app with GlamorousLibraryJS" type posts. The short answer: if you avoid the shiny tools that claim to do everything, you will not have this problem. And as a special case, avoid Gulp, which is mismanaged. The single-responsibility libraries that have a well-defined scope, on the other hand, have often been sitting on npm unchanged for 5-6 years, because they are simply done, and they do what they need to. They will very likely never deprecate anything, as there is simply nothing to change. I would argue that these libraries are actually doing a better job of stability than their counterparts in other languages. Edit: An additional factor is that it's easy to write a tutorial about an extensive framework with a large scope; there's plenty of stuff to write about. Writing a tutorial about "this is how you make a function call to this library to parse a geo URI", on the other hand, probably isn't going to happen. So if you follow third-party tutorials, you are naturally going to end up at the packages that are most prone to deprecations.
userbinator 6y ago
Anything Node, JS, or web-development related seems to churn much more than everything else.

LoSboccacc 6y ago

try using four libraries and chances are they require two different version of a build tool installed globally

kungato 6y ago

The sad part about the js ecosystem is that even the biggest corps like Google can't keep their own js ecosystem stable on the last version. I have a small Angular app with Firebase backend and every time I come back to it to update, the libs are out of sync

nicoburns 6y ago
Google aren't very good at this, but Facebook are. Maybe give React a try.
joepie91_ 6y ago
Google is notoriously bad at maintaining (or even designing) their open-source stuff. I wouldn't say "even the biggest corps like Google" -- Google does considerably worse at this than many hobbyist maintainers! I just don't use Google libraries anymore, if I can at all avoid it. See also my other comment[1] - Angular is an example of such a magical does-everything framework. [1] https://news.ycombinator.com/item?id=24168279 https://news.ycombinator.com/item?id=24168279
- nl 6y ago
  Tensorflow is another example of this.
- RonanTheGrey 6y ago
  We've abandoned an app because of the inability to keep Firebase working on it (JS libraries). Between out of sync Typescript definitions, broken APIs, broken interfaces, "this version of some other dependency works with this version of Firebase thanks to some random transient dependency", it just became too much. We won't use the JS libraries at all anymore. Angular is the only one that has remained even remotely usable, but certainly not stable. It's never as simple as running the upgrade utilities, changing the version, and being done. It ALWAYS takes at least a day to find all the "little" things they didn't feel fit to mention in the upgrade docs. It's aggravating. I genuinely don't like using Google software, at all. I've felt for a long time that Google is coasting on the momentum of the early web and the awe people felt for what they built early on. That hasn't been Google for a long, long time.
- sukilot 6y ago
  Google was better when they were smaller. Java Guava rules.

BossingAround 6y ago

I'm running into this problem more and more. It seems like Node is fundamentally unusable for anything but the nimblest teams that do not mind updating their dependencies automatically, every week, and when something breaks, they are capable of fixing it within hours. I really like Node as a language (especially with TS), but Node as an ecosystem feels like a very hard fit into 90%+ of corporations.

nicoburns 6y ago
I think the culture of Node comes from the earlier culture of in-browser JavaScript. When running on the browser platform you have to make sure your libraries are up to date and maintained, otherwise you're at the mercy of browser updates breaking things from under your feet (this is less bad now, but it was awful in the days of IE<9, and on android before they started shipping auto-updating Chrome webview) Consequently, JavaScript developers got used to the burden of maintenance and rapidly updating to the latest versions of libraries, and this culture carried through to Node (partly because a lot of libraries are shared between node and the web). Having said that, if you pick your libraries well, it's not too bad these days. When I upgraded from Node 12 to Node 14 earlier this year, I had to upgrade the `pg` package to a newer version that supported Node 14 (there was one available), but I didn't have to make any code changes. And other than that I've had no forced version upgrades in a long time. I guess if you're lookig at 5-10 year timescales with literaly no maintenance then this would be a different matter though.
- dutchmartin 6y ago
  I strongly feel that you must have end to end tests while using node because of the dependency hell. Not even knowing if a upgrade of a dependency breaks your system is just hard. Also testing it by hand is just not maintainable.
  - joepie91_ 6y ago
    > Not even knowing if a upgrade of a dependency breaks your system is just hard. This is true for any language/platform.

joepie91_ 6y ago

This is only a problem in some parts of the ecosystem - but they are the parts that most 'tutorials' are written about, because they look shiny and fancy. If I'm blunt, they're the parts of the ecosystem that HN loves to gloat about in their "how I saved my company thousands of dollars by building a todo app with GlamorousLibraryJS" type posts. The short answer: if you avoid the shiny tools that claim to do everything, you will not have this problem. And as a special case, avoid Gulp, which is mismanaged. The single-responsibility libraries that have a well-defined scope, on the other hand, have often been sitting on npm unchanged for 5-6 years, because they are simply done, and they do what they need to. They will very likely never deprecate anything, as there is simply nothing to change. I would argue that these libraries are actually doing a better job of stability than their counterparts in other languages. Edit: An additional factor is that it's easy to write a tutorial about an extensive framework with a large scope; there's plenty of stuff to write about. Writing a tutorial about "this is how you make a function call to this library to parse a geo URI", on the other hand, probably isn't going to happen. So if you follow third-party tutorials, you are naturally going to end up at the packages that are most prone to deprecations.

userbinator 6y ago

Anything Node, JS, or web-development related seems to churn much more than everything else.