3 ms·

There is really no place where updating dependencies is dramatically better. Back end frameworks and even whole languages have this problem. On the front end, I

There is really no place where updating dependencies is dramatically better. Back end frameworks and even whole languages have this problem. On the front end, I mostly use React and it has been fairly backwards compatible. It's a tradeoff. If you never ever make breaking changes you can end up constrained by previous design decisions. If you make them all the time users won't be able to keep up.

smt88 2y ago
> There is really no place where updating dependencies is dramatically better This is absolutely untrue. There's a huge gap in how easy it is to upgrade some stacks vs. others. Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy, for example: Step 1: update dependencies Step 2: fix compiler errors Upgrading major versions of .NET, for example, sometimes requires no work at all. This is not true in JavaScript, Python, and some other languages where you're only going to discover issues during runtime. TypeScript makes things a lot better, but you're relying on the authors of your dependencies either using TypeScript or keeping types up to date.
- morsecodist 2y ago
  I was a bit broad here. I am sure certain projects get things better than others. When I said no place I was more referring to whole categories of development like, front-end, back-end, embedded, data pipelines, ect... I love types and advocate their use whenever possible. They help a lot but they are a spectrum. Thanks to static analysis tools like TypeScript or even eslint you can get a bit towards automated checks on front end code. Also even compiled languages can miss some things, different languages have type systems that give you different kinds of guarantees. For example, Java has NPEs that can't be caught at compile time.
- KronisLV 2y ago
  > There's a huge gap in how easy it is to upgrade some stacks vs. others. This I can agree with. > Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy Java would typically be regarded a pretty close to .NET in regards to its type system, yet I've seen plenty of issues with updating dependencies, whenever you have any sort of dynamic class loading or reflection going on: be it Lombok or MapStruct not liking a specific version of Java, or Spring Boot or one of its many integrations throwing errors during startup after a successful compile, sometimes even disliking specific annotations that worked previously. A decent type system will help you make sure that the code compiles, sure (and I'm thankful for that), but with some styles of writing code and handling, for example, dependency injection, all bets are off. The same goes for any dependencies that make liberal use of those features. I'd have to dig around for specific examples, but I know for a fact that there are plenty of projects that are stuck on old versions of Spring for that very reason. Or the fact that there are plenty of pre-.NET Core projects out there that won't be upgraded to anything new anytime soon for similar reasons. In my experience, updates suck across the board, the only variable is how much. And that applies to everything not just dependencies in code (and runtimes): I've also had seemingly innocuous Debian updates break GRUB and prevent the OS from booting, or even upgrades making exim4 start up for some reason and taking up the port that my mail server needed, preventing it from starting.

smt88 2y ago

> There is really no place where updating dependencies is dramatically better This is absolutely untrue. There's a huge gap in how easy it is to upgrade some stacks vs. others. Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy, for example: Step 1: update dependencies Step 2: fix compiler errors Upgrading major versions of .NET, for example, sometimes requires no work at all. This is not true in JavaScript, Python, and some other languages where you're only going to discover issues during runtime. TypeScript makes things a lot better, but you're relying on the authors of your dependencies either using TypeScript or keeping types up to date.

morsecodist 2y ago
I was a bit broad here. I am sure certain projects get things better than others. When I said no place I was more referring to whole categories of development like, front-end, back-end, embedded, data pipelines, ect... I love types and advocate their use whenever possible. They help a lot but they are a spectrum. Thanks to static analysis tools like TypeScript or even eslint you can get a bit towards automated checks on front end code. Also even compiled languages can miss some things, different languages have type systems that give you different kinds of guarantees. For example, Java has NPEs that can't be caught at compile time.
KronisLV 2y ago
> There's a huge gap in how easy it is to upgrade some stacks vs. others. This I can agree with. > Updating dependencies in a language with strong, static types and/or an expressive type system is incredibly easy Java would typically be regarded a pretty close to .NET in regards to its type system, yet I've seen plenty of issues with updating dependencies, whenever you have any sort of dynamic class loading or reflection going on: be it Lombok or MapStruct not liking a specific version of Java, or Spring Boot or one of its many integrations throwing errors during startup after a successful compile, sometimes even disliking specific annotations that worked previously. A decent type system will help you make sure that the code compiles, sure (and I'm thankful for that), but with some styles of writing code and handling, for example, dependency injection, all bets are off. The same goes for any dependencies that make liberal use of those features. I'd have to dig around for specific examples, but I know for a fact that there are plenty of projects that are stuck on old versions of Spring for that very reason. Or the fact that there are plenty of pre-.NET Core projects out there that won't be upgraded to anything new anytime soon for similar reasons. In my experience, updates suck across the board, the only variable is how much. And that applies to everything not just dependencies in code (and runtimes): I've also had seemingly innocuous Debian updates break GRUB and prevent the OS from booting, or even upgrades making exim4 start up for some reason and taking up the port that my mail server needed, preventing it from starting.