6 ms·

Regarding ORM, it's typically paired with Sequelize or Prisma. (I'm personally using the latter.) I've built Django apps in the past (it's actually how I learne

Regarding ORM, it's typically paired with Sequelize or Prisma. (I'm personally using the latter.) I've built Django apps in the past (it's actually how I learned Python in the 2.5 days), but what's nice about Node/TS is that the frameworks are more loosely coupled so you can pick/choose your best components. For example, while I mentioned the ORMs above, you can even go one step further and use a backend headless CMS like Strapi, which will get you the ORM + admin interface that you'd get from Django models.

creshal 5y ago
> what's nice about Node/TS is that the frameworks are more loosely coupled so you can pick/choose your best components. For about two weeks, then one of them becomes deprecated again and you have to migrate everything all over again…
- 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!

creshal 5y ago

> what's nice about Node/TS is that the frameworks are more loosely coupled so you can pick/choose your best components. For about two weeks, then one of them becomes deprecated again and you have to migrate everything all over again…

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!