Thanks for reading and giving a feedback! You stated, "Don't trust benchmarks" but then you asked the reader to trust the results of your isolated use case. I stated "Don't trust benchmarks" and I did not ask the reader to trust my benchmarks. On the contrary, I gave my numbers, and right after that I told that after trying this on a real project, those numbers worth nothing. You should try it on your real project rather than trusting random articles over the internet, and you should be suspicious even for your own numbers. Your library size doesn't make it a perfect real-world scenario for comparing the speed. I agree. All the benchmarks you can find are measuring just one particular scenario. It's possible that you have a very similar but slightly different case, and you can receive totally different results. In case of Jest, it's not officially documented that you can use it with swc or esbuild, people go with default settings (Jest is transpiling your code with Babel by default), its ending up terribly slow. But if you try it with swc, it's highly likely to become more performant than Vitest, at least, in my experience. There is no such a setting in Vitest that I can change and make it faster than Jest on my particular codebase. And I doubt that Vitest can become faster anytime soon, because it's based on a full blown bundler that does a lot of things internally - Vite, while Jest + swc is just a test runner + transpiler and nothing more. The sad truth is that there is no really good unit test framework so far. Jest can't be considered good because of ESM and lack of support and not so good docs, but Vitest is really good, excellent docs, has everything you may need. Can you share what's missing from Vitest for you? What are the questionable choices that you mentioned?

Kysely is great and I was happy to use it in my last work project. In theory, implementing "real world app" with Kysely might have some quirks (or maybe not), but implementing this app one more time is time-consuming so not gonna do that. Though it would be interesting to see if it's much easier to use than Knex, as they are similar, but take different approaches for query builder design.

That's a super inspiring comment filling my heart with joy! Programming day and night is totally worth it when you have such feedback, thank you!

Stephen Haberman thank you for checking it out! I understand your point, so I added an explanation on the very first page of the docs that is not a "traditional" ORM. But it is an ORM like Prisma. None of the query builders is helping with relations, literally none of them, so if I call it a query builder it's like ignoring the most fun part of it: working with relations. Here is a code example in benchmarks section. Calling it a DSL or a database SDK would tell nothing to potential users. Everyone knows Prisma, and I guess if they can call it ORM, then mine can be called too. Anyway, there are no strict clear bounds of what ORM is. Different people have different expectations. So for me, query builder is abstracting only tables, while ORM is also abstracting relations. And how exactly it is implemented - instantiating class or not - is just an implementation detail.

Hi Stephen Haberman! I see you are continuing to develop Joist ORM (the last commit is yesterday), great to see such insistence. I developed my ORM too. And updated this article to include a brief overview. Surely it's completely different from yours, I hope you could find some time to check it out, it may have some interesting ideas. I'd be happy to get feedback from the developer of another ORM (even harsh)!

Thank you for sharing, could explain why did you choose Mongo?

Stephen Haberman I'm working on own ORM too and just want to share my ideas/vision on those points: But net-net is that you get the same "just an empty model" "class Author {}" when starting out Migration is responsible for changing db schema, not only for creating tables, but also changing, renaming, sometimes we do data updates in migration. And in the model we define current columns, it doesn't take much time, developer can easily jump to User and see the fields. But I decided to go further, let it be possible to define a validation schema right in the model! If you know Zod library, I mean to define columns in similar way like they do. Something like: const User = model({ schema: (t) => ({ id: t.serial().primaryKey(), email: t.text().email(), }) }) And now it's not only db types, but also validation types. Later in the controller we can reuse this schema to validate payload: const createUserSchema = User.schema.pick({ email: true, name: true, // ... }) router.post('/user', (req, res) => { const data = createUserSchema.parse(req.body) data // TS knows exactly what the type is }) but that means you can't test any code that commits transactions (or maybe you could use subtransactions?) Yes :) Just published package for this: https://www.npmjs.com/package/pg-transactional-tests There is explanation how it handles nested transactions, previously it was a script I copied from project to project and it helped me a lot even on a production project. Yep! That makes sense, but the wrinkle is: is book.reviews a BookReview[] or Promise<BookReview[]>? I'm going to implement nested loads with json_agg, i.e postgres can aggregate data to json arrays by it's own. As for the interface, .include method should be fine: const result = await Post.include('comments') result // is an array of posts const post = result[0] post.comments // array of comments Also it should accept sub queries, so we can load filtered comments: const result = await Post.include({ comments: Comment.where({ ...conditions }).order({ createdAt: 'DESC' }) }) By the way, is it possible in Joist to load Post with their Comments ordered by comment field or apply some condition? Regarding whether book.reviews is a BookReview[] or Promise<BookReview[]> - well, I suspect it's tricky to customize result of em.load, but in theory it's possible to return BookReview[] type only if this resource was preloaded, and Promise<BookReview[]> otherwise. Regarding Unit of Work, I simply don't understand it's benefits, I like the concept of simple structures with fewer magic, when you can see clearly in the code what's going on. Maybe you could suggest an example where it shines? const user = await User.find(1) const data: Partial<UserType> = {} // ...some logic to change user if (someParam) { data.foo = 1 data.bar = '...' } // and in the end: await User.update(user, data) Here is quite typical update flow, without Unit of Work so no need for creating some session, track any states, etc. Even without "ActiveRecord" pattern, User.update is a static method, while user is a plain lightweight JS object. So in my opinion, Unit of Work adds a bit of boilerplate, overhead, complicates things, or am I wrong? I don't mean to criticize Joist, just have different preferences and beliefs. So maybe node.js has no decent ORM to use with pleasure (yet?), but we have so huge variety of libs which are mixing completely different ideas, and continuing building new ones, there is something good in it (I guess).

Thanks for reading! These are my thoughts on Joist after briefly reading through the docs, sorry that not examining it more deeply: continual, verbatim mapping of the database schema to your object model Am I getting it right, first user need to create table in any way they want, and then they run your codegen and this lib generates model files? Some other ORMs are doing the opposite: you're writing models and then they generate migrations. I simply can't understand why - why not to follow simple and reliable RoR approach, I guess the same as in other languages? Write migration, write model, there are scaffolds for lazy people. "reactive" validation rules - that's interesting, I remember was using it all the time in Rails, if specific column or columns was changed it will run specific validation. I suggest to make change docs/readme so it's more obvious for the new comer what is special about Joist. "Schema-driven code generation" - new comer doesn't know what is it, you could write it like "Automatically generates code for models out of your database". As a new comer, I don't really see how it's better than others, I see it's similar to MikroORM and has additional features, something graphql specific, but how is it better for everyday use? "Guaranteed N+1 safe" well, in the page of docs "Avoiding N+1" the first example you show is NOT N+1 safe. And to see how to do it right reader has to scroll to the very bottom of this page. Fast tests: let me brag about my approach, I patched node-pg so in each tests gets wrapped in a transaction, and it simply rolled back after each test, no need to clean db at all. And this approach worked for 3 of 6 ORM's in this article. Some time later I'm going to write about this and to publish a lib. Syntax is similar to MikroORM (which I don't like): const em = newEntityManager(); const a = await em.load(Author, "a:1"); If you're saying ActiveRecord is an inspiration, why not: const a = Author.find("a:1") // or const a = Author.findBy({ id: 'a:1' }) // or const a = Author.where({ id: 'a:1' }).take() book.reviews.get; Looks a bit weird, conventionally we use verbs for functions, here we have property get. Would be better to do it without property, I believe this should be possible: book.reviews

GraphQL is awesome, it's a better approach in almost every way. The flow: define a GraphQL schema, if it's schema first generate TS types with one command, if it's code first generate schema, implement resolvers and data-loaders and let the types to guide you. I work with React usually, so next step is to generate types and ready to use hooks for the frontend. And you have API docs and playground for free. I love this flow, it saves a lot of time, less code to support, API is more unified. There is a one question I'm not sure how to solve in GraphQL, what if evil client will load too much of nested resources making server to feel sick, but there must be a way to solve it. For some reason, GraphQL is still not too popular, perhaps people think it's more complex, or they know some flaws, so in my experience where I worked it was always a REST API, so I'm not very familiar with GQL and only learned it by using on a pet project. If by any chance you'd like to write an article about Nexus vs Pothos, and for me vs Mercurius, there is also typegraphql, apollo server, I'd love to read it!

Writing in depth article is so time consuming, because need to take a library, to read it's docs and learn how to use it, then to write bunch of code to see in action. Most of the time spent on fighting with bugs, limitations, digging issues. And it was very pleasant to get a lot of positive comments for my first large post (on reddit many people said it's good written, bookmarked). I really like the topic of ORMs because that is a tool I work with primarily for many years, and I'm developing own, so I wanted to see what the market has and to get inspiration. GraphQL solutions overview is a bright idea for an article, but I don't work with GraphQL usually, so not motivated for this. I enjoyed working with "fastify mercurius" for GraphQL, but it's schema first. After changing schema it generates all the types, and only need to implement resolvers and data loaders.