7 ms·

This isn't really true though. There are plenty of open-source modules in Node which were released more than 5 years ago and are still in use today. People only

by lhnz 5y ago

This isn't really true though. There are plenty of open-source modules in Node which were released more than 5 years ago and are still in use today. People only move to new ones, when they are clearly better. What exactly is wrong with that?

creshal 5y ago
> There are plenty of open-source modules in Node which were released more than 5 years ago and are still in use today. And how stable was their API over the last five years? It hardly counts if over 5 years the APIs change so much they're basically different libraries at the end. Django's code churn for even complex projects is on the order of single digit hours per year at worst, the remaining 99.99% of time can go into delivering things customers care about. I can't say I've seen that sort of stability in anything Javascript-related, apart from maybe jQuery projects. (Which of course have their own problems because jQuery is the wrong abstraction usually.)
- nicoburns 5y ago
  On the backend, Express has had a very stable API for 5+ years. On the frontend, React has. However, stable or not there's nothing that competes with Django/Rails/Laravel in the Node ecosystem.
  - Silhouette 5y ago
    I'm not sure React is the best example. Although the library is backward compatible in theory, it doesn't much matter in practice because almost the entire ecosystem switched to a radically different core abstraction a couple of years ago.
    - hrisng 5y ago
      There's nothing stopping you from using class component as opposed to the new functional component though. It works completely fine, as it ever was, and in fact, I know a lot of teams are still using it. The API on that front is indeed surprisingly stable. Furthermore, there haven't been any shiny new thing since hooks, and it starting to feel like boring old tech. It's not the cool kid on the block anymore.
      - Silhouette 5y ago
        There's nothing stopping you from doing it, but part of the reason a library like React achieves such widespread use is the ecosystem that builds up around it, and if everyone else is using hooks to expose whatever functionality they're building, you are now excluded from the benefits of all of that work.
        nicoburns 5y ago
        Well sure, if you don't adopt the new technology then you don't get the benefits of the new technology. But that's true it literally every ecosystem. If you don't upgrade to a C11 compiler, then you can't use libraries using C11 features either. But in both cases, there's little reason not to upgrade because your old code will still work fine on the new version. And indeed you're free to continue writing new code in the "old" style. Adding additional API surface after 3 years while continuing to maintain and support the old API is hardly unstable!
        Silhouette 5y ago
        But that's true it literally every ecosystem. If you don't upgrade to a C11 compiler, then you can't use libraries using C11 features either. I don't think the situations are equivalent, at least not to any meaningful degree. With C11, your old code continued to work, your old libraries continued to work, your tools probably required at most minor configuration changes, your new code and libraries were still mostly the same style even if you also used some of the new features, and anyone you were working with who knew one version could very quickly and easily adapt to the other. With React, you can stop after your old code and libraries continuing to work, except that you might not be able to use those old libraries from new code any more and they might no longer be getting much ongoing development. You still effectively have to learn a whole new version of React API, and find your way around a whole new ecosystem of libraries and tools that operate alongside that new API. So does everyone you're working with. You have the backward compatibility, but only by having two completely different coding styles in the same code base, and if you're hiring new people who only know the new API and ecosystem, they now have to learn the old one as well to work on your code. If the original point was about whether tools are stable for a long time so you don't have to worry about making major changes or learning big new things, one of these situations is not like the other.

by lhnz 5y ago

creshal 5y ago

> There are plenty of open-source modules in Node which were released more than 5 years ago and are still in use today. And how stable was their API over the last five years? It hardly counts if over 5 years the APIs change so much they're basically different libraries at the end. Django's code churn for even complex projects is on the order of single digit hours per year at worst, the remaining 99.99% of time can go into delivering things customers care about. I can't say I've seen that sort of stability in anything Javascript-related, apart from maybe jQuery projects. (Which of course have their own problems because jQuery is the wrong abstraction usually.)

nicoburns 5y ago
On the backend, Express has had a very stable API for 5+ years. On the frontend, React has. However, stable or not there's nothing that competes with Django/Rails/Laravel in the Node ecosystem.
- Silhouette 5y ago
  I'm not sure React is the best example. Although the library is backward compatible in theory, it doesn't much matter in practice because almost the entire ecosystem switched to a radically different core abstraction a couple of years ago.
  - hrisng 5y ago
    There's nothing stopping you from using class component as opposed to the new functional component though. It works completely fine, as it ever was, and in fact, I know a lot of teams are still using it. The API on that front is indeed surprisingly stable. Furthermore, there haven't been any shiny new thing since hooks, and it starting to feel like boring old tech. It's not the cool kid on the block anymore.
    - Silhouette 5y ago
      There's nothing stopping you from doing it, but part of the reason a library like React achieves such widespread use is the ecosystem that builds up around it, and if everyone else is using hooks to expose whatever functionality they're building, you are now excluded from the benefits of all of that work.
      - nicoburns 5y ago
        Well sure, if you don't adopt the new technology then you don't get the benefits of the new technology. But that's true it literally every ecosystem. If you don't upgrade to a C11 compiler, then you can't use libraries using C11 features either. But in both cases, there's little reason not to upgrade because your old code will still work fine on the new version. And indeed you're free to continue writing new code in the "old" style. Adding additional API surface after 3 years while continuing to maintain and support the old API is hardly unstable!
        Silhouette 5y ago
        But that's true it literally every ecosystem. If you don't upgrade to a C11 compiler, then you can't use libraries using C11 features either. I don't think the situations are equivalent, at least not to any meaningful degree. With C11, your old code continued to work, your old libraries continued to work, your tools probably required at most minor configuration changes, your new code and libraries were still mostly the same style even if you also used some of the new features, and anyone you were working with who knew one version could very quickly and easily adapt to the other. With React, you can stop after your old code and libraries continuing to work, except that you might not be able to use those old libraries from new code any more and they might no longer be getting much ongoing development. You still effectively have to learn a whole new version of React API, and find your way around a whole new ecosystem of libraries and tools that operate alongside that new API. So does everyone you're working with. You have the backward compatibility, but only by having two completely different coding styles in the same code base, and if you're hiring new people who only know the new API and ecosystem, they now have to learn the old one as well to work on your code. If the original point was about whether tools are stable for a long time so you don't have to worry about making major changes or learning big new things, one of these situations is not like the other.