3 ms·

Hey, thanks a lot for the feedback (and I've seen harsher words on HN, so no worries)! I wrote most of the docs, so more than happy to take any feedback to see

Hey, thanks a lot for the feedback (and I've seen harsher words on HN, so no worries)! I wrote most of the docs, so more than happy to take any feedback to see where it can improved! What I'm mostly trying to refer to are ActiveRecord style ORMs in the Node.js ecosystem (such as Sequelize and TypeORM). With those libraries, you often have model objects that can get really complicated to work with, these are not plain objects but implement lots of additional behaviour for storage and retrieval of data, often times business logic as well. Compared to that, working with plain objects (which are statically and structurally typed) is a fundamentally different approach that's hopefully easier to reason (at least that's what I've found from my personal experience).

eitland 7y ago
Ok, thanks for replying. I've been busily trying to reword my post since talking down to people who stand up and make things really isn't my thing either. I guess your explanation here makes a lot of sense - I don't know much about Javascript ORMs.
eropple 7y ago
I don't really understand the claim you're making here--you have to go out of your way in TypeORM to get ActiveRecord objects instead of plain JavaScript objects. The happy path is pretty firmly in data-mapper territory; as an example, for all the shade I will happily fling NestJS's way they just hand you a Repository and tell you to get on with your day. There's also stuff like Objection.js (which works well in TypeScript), too. I don't dislike Prisma, but the framing is really strange to me.
- PaulMest 7y ago
  Could be off-topic for this thread... but what shade would you like to throw NestJS's way? Or do you have a write-up somewhere else, by chance?
  - eropple 7y ago
    - I think it comprehensively misunderstands and mis-implements a lot of things that are important. Their “microservices” boondoggle is a whatever RPC mechanism that has no real reason to exist, their CQRS library expects the world to be a single node, their OpenAPI library is vestigial and completely separates the generation of documentation from actually validating inputs. Most of the things outside of core are rotated about 45 degrees away from where you’d expect with a holistic understanding of a web application. Stuff built by somebody who heard of a problem, not felt a problem. - I think that the core team is bad at and refuses to improve at communicating with its community via roadmaps. Huge changes just appear, including literally breaking changes within a given major release, with little to no warning. - I think they don’t respect what community they do have, building completely new, blessed-by-the-core-team libraries that step on existing open-source solutions in the NestJS ecosystem mostly just so the package can say “@nestjs/“ at the front of it. (Top of mind example is “@nestjs/schedule”, which is a worse take on “nest-schedule.") There isn't much personal incentive to build community tooling if the core team will swoop in and go "mine now!" without so much as a prior-work credit and it's disrespectful besides. - They continue to build their own tooling that steps on the accepted norms and systems in the Node community. The NestJS CLI now incorporates "monorepos" that aren't Lerna or Yarn ones; they're also pushing developers to use it as their primary way of building applications, rather than invoking tsc, with the dangly carrot of "we'll write plugins for it [rather than using one of the existing ways to better handle extended compilation]". It feels like a lock-in play for future monetization (there's open rumors that Kamil is very focused on monetization, which--you do you, but as Rails and Django and even Spring showed us this stuff seems to really work better if you care about it existing to exist, and you make money off of using it) and the lack of community roadmap makes assuaging those concerns very much not a priority of the core team. I was a big booster of NestJS a year ago and I’ve written a bunch of modules for it. I was even a personal donor to the project's Open Collective, it's the only project I've ever done that for. But I do not use NestJS for new projects because I have no confidence in the design or the leadership there and I don’t think it’s a wise use of my time anymore.
    - seymon 7y ago
      What are you using now for your new projects instead of nestjs?

eitland 7y ago

Ok, thanks for replying. I've been busily trying to reword my post since talking down to people who stand up and make things really isn't my thing either. I guess your explanation here makes a lot of sense - I don't know much about Javascript ORMs.

eropple 7y ago

I don't really understand the claim you're making here--you have to go out of your way in TypeORM to get ActiveRecord objects instead of plain JavaScript objects. The happy path is pretty firmly in data-mapper territory; as an example, for all the shade I will happily fling NestJS's way they just hand you a Repository and tell you to get on with your day. There's also stuff like Objection.js (which works well in TypeScript), too. I don't dislike Prisma, but the framing is really strange to me.

PaulMest 7y ago
Could be off-topic for this thread... but what shade would you like to throw NestJS's way? Or do you have a write-up somewhere else, by chance?
- eropple 7y ago
  - I think it comprehensively misunderstands and mis-implements a lot of things that are important. Their “microservices” boondoggle is a whatever RPC mechanism that has no real reason to exist, their CQRS library expects the world to be a single node, their OpenAPI library is vestigial and completely separates the generation of documentation from actually validating inputs. Most of the things outside of core are rotated about 45 degrees away from where you’d expect with a holistic understanding of a web application. Stuff built by somebody who heard of a problem, not felt a problem. - I think that the core team is bad at and refuses to improve at communicating with its community via roadmaps. Huge changes just appear, including literally breaking changes within a given major release, with little to no warning. - I think they don’t respect what community they do have, building completely new, blessed-by-the-core-team libraries that step on existing open-source solutions in the NestJS ecosystem mostly just so the package can say “@nestjs/“ at the front of it. (Top of mind example is “@nestjs/schedule”, which is a worse take on “nest-schedule.") There isn't much personal incentive to build community tooling if the core team will swoop in and go "mine now!" without so much as a prior-work credit and it's disrespectful besides. - They continue to build their own tooling that steps on the accepted norms and systems in the Node community. The NestJS CLI now incorporates "monorepos" that aren't Lerna or Yarn ones; they're also pushing developers to use it as their primary way of building applications, rather than invoking tsc, with the dangly carrot of "we'll write plugins for it [rather than using one of the existing ways to better handle extended compilation]". It feels like a lock-in play for future monetization (there's open rumors that Kamil is very focused on monetization, which--you do you, but as Rails and Django and even Spring showed us this stuff seems to really work better if you care about it existing to exist, and you make money off of using it) and the lack of community roadmap makes assuaging those concerns very much not a priority of the core team. I was a big booster of NestJS a year ago and I’ve written a bunch of modules for it. I was even a personal donor to the project's Open Collective, it's the only project I've ever done that for. But I do not use NestJS for new projects because I have no confidence in the design or the leadership there and I don’t think it’s a wise use of my time anymore.
  - seymon 7y ago
    What are you using now for your new projects instead of nestjs?