I rather like the experience of working with Remix. Though it has some quirks. `remix-auth` is OK. `drizzle` works ok. I dunno, it depends on a lot of factors but in the spirit of your question this is what I'll answer.
Remix is my favorite as well from this category. But I’m super conflicted regarding ORMs and data access libraries. All of them are either too new, too unstable, too unmaintained, too VC backed, too little devs/community, etc.
Too new, too focused on TypeScript (which I don't use), mostly developed by a single dev that already abandoned other similar projects (objection) and nobody knows what its future is.
This is exactly what I mean.
Compare that to using the ORMs from Django, Laravel or Rails or some of the Java ones. You can be sure than 3~4 years from now they'll still be around, well maintained and probably without big rewrites or API changes.
Not saying that it's not the best option in node land (I don't know), but what frustrates me is that there's no clear option for many core/basic things. And always "the best solution that's going to fix everything" seems to be the one that appeared last. Feels like building on top of mud to be honest.
I get your point. I see Kysely more as a progression from Objection, but that's not the case if you're not into TypeScript. I was using Knex.js like forever and now switching over to Kysely. kysely-codegen introspects the database on every build, and doesn't massage the output model like for instance Prisma does. The database is leading, the only dependency is the query builder API which feels pretty familiar coming from Knex.js. So even though it's new and shiny, it doesn't feel like a huge commitment you can't back out of if things go south with Kysely. Anyway, Node.js does indeed not have these "one true way" giants like the frameworks you mentioned. That's a blessing and a curse.
I think that when working with Node the "trick" is to pick libraries/dependencies/frameworks that are either 1) Well know, supported, big community, well maintained, many users, etc or 2) They're small and isolated enough that it wouldn't be a big deal to replace them or to just fork and maintain yourself.
At least that's my kind of unwritten rule about it.
Comments
I rather like the experience of working with Remix. Though it has some quirks. `remix-auth` is OK. `drizzle` works ok. I dunno, it depends on a lot of factors but in the spirit of your question this is what I'll answer.
Remix is my favorite as well from this category. But I’m super conflicted regarding ORMs and data access libraries. All of them are either too new, too unstable, too unmaintained, too VC backed, too little devs/community, etc.
Share the same sentiment and settled on Kysely. Although new, it doesn't try to do too much and has excellent TypeScript support.
Too new, too focused on TypeScript (which I don't use), mostly developed by a single dev that already abandoned other similar projects (objection) and nobody knows what its future is.
This is exactly what I mean.
Compare that to using the ORMs from Django, Laravel or Rails or some of the Java ones. You can be sure than 3~4 years from now they'll still be around, well maintained and probably without big rewrites or API changes.
Not saying that it's not the best option in node land (I don't know), but what frustrates me is that there's no clear option for many core/basic things. And always "the best solution that's going to fix everything" seems to be the one that appeared last. Feels like building on top of mud to be honest.
I get your point. I see Kysely more as a progression from Objection, but that's not the case if you're not into TypeScript. I was using Knex.js like forever and now switching over to Kysely. kysely-codegen introspects the database on every build, and doesn't massage the output model like for instance Prisma does. The database is leading, the only dependency is the query builder API which feels pretty familiar coming from Knex.js. So even though it's new and shiny, it doesn't feel like a huge commitment you can't back out of if things go south with Kysely. Anyway, Node.js does indeed not have these "one true way" giants like the frameworks you mentioned. That's a blessing and a curse.
Yeah, that sounds good to me.
I think that when working with Node the "trick" is to pick libraries/dependencies/frameworks that are either 1) Well know, supported, big community, well maintained, many users, etc or 2) They're small and isolated enough that it wouldn't be a big deal to replace them or to just fork and maintain yourself.
At least that's my kind of unwritten rule about it.