Looks very interesting! I too came from the PHP world and made a 2nd stop at TypeORM (sequelize was my 1st had some really bad experiences with it).
Got one question though, since I see many similarities between TypeORM and MikroORM: Why not try to contribute to the TypeORM community, to help them grow? I think it's OK to reinvent the wheel when learning, but on Open Source wouldn't it make more sense to prefer collaboration with existing solutions instead of rolling out your own? I'd understand if you needed extra power and made a work/proposal that got rejected.
I don't think they are that similar under the hood. TypeORM does not implement neither unit of work nor identity map, so the underlying logic is really different I believe.
My main reason to start new project was not to be bound by such a huge community - I don't see how we could maintain back compatibility while introducing UoW and IM to TypeORM. It would have to be another (optional) way to use it, which would make it even more complex (which it already is).
TypeORM code is so complex and was started in a time when js/ts language features were lacking. I think the TypeORM API has some fundamental issue like it uses too much string building for queries.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Looks very interesting! I too came from the PHP world and made a 2nd stop at TypeORM (sequelize was my 1st had some really bad experiences with it).
Got one question though, since I see many similarities between TypeORM and MikroORM: Why not try to contribute to the TypeORM community, to help them grow? I think it's OK to reinvent the wheel when learning, but on Open Source wouldn't it make more sense to prefer collaboration with existing solutions instead of rolling out your own? I'd understand if you needed extra power and made a work/proposal that got rejected.
I don't think they are that similar under the hood. TypeORM does not implement neither unit of work nor identity map, so the underlying logic is really different I believe.
My main reason to start new project was not to be bound by such a huge community - I don't see how we could maintain back compatibility while introducing UoW and IM to TypeORM. It would have to be another (optional) way to use it, which would make it even more complex (which it already is).
Sounds fair!
TypeORM code is so complex and was started in a time when js/ts language features were lacking. I think the TypeORM API has some fundamental issue like it uses too much string building for queries.