Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm curious what you don't like about Prisma?

I like Active Record + Arel (from Rails) a lot, and have found Knex relatively unpleasant in comparison, offhand Prisma has looked more pleasant/usable to me...



This is where our preferences probably differ.

I’m not a fan of ActiveRecord or ORMs in general. I’d much rather write raw sql queries with a little help to improve reusability.

I found Prisma to be super basic. Anything complex like joins or a composition of where’s and ors and it didn’t work.

It also nests related objects where for my purposes I wanted everything to be flat. So if a list has a user associated with it, I want to flatten it like: { list, user }.

I also didn’t like how Prisma has a generate cli to integrate end developer models that must be integrated into your build step to deploy if you’re using typescript.

Its schema cli command worked but in weird ways that I didn’t like. Sharing Prisma types with the client was not automatic. For example, Prisma coverts datetime columns into dates, which sounds nice, but when I send that data as an api response it turns into a string. Now I can’t use their interfaces without plucking the date times and converting it to a string. It just wasn’t as useful as I had hoped.

Knex does exactly what I want and nothing more. All of my raw sql queries were easily converted and worked perfectly. I build the interfaces and knex uses them. There’s no special command that converts their schema format into something I can kind of use.

Their typing was nice once I got it working however, and for simple things it worked fine. I just noticed I had to write a lot of raw sql.


Sounds sort of like Active Record without Arel. The things that you're mentioning do sound irritating, not being able to do joins easily, etc., seems lousy. (I think Arel is a bit overlooked, but it's actually very pleasant to build complex/composable queries with it IMO.)

Regarding types, the more I've used JS the more I've come to hate JS's native types for numbers and dates/times, so not terribly shocked by that, kind of think its native types being really obnoxious is part of why typescript is relatively popular.

I am a bit curious - the piece of ORM-style solutions that I like is that they create a clear pattern for organizing certain kinds of application logic - for example, if there's a rule that value X meets certain conditions, usually there are tools or conventions with ORMs to make it not easy to write something that skips the rule without doing so intentionally. Whereas in codebases that don't use some sort of frameworky-ORM-y solution I often find myself thinking there aren't clear patterns of responsibility for such things, leading to bugs or poor DRY practices.


Curious about the date response part.

JSON.stringify(payload) turns dates into strings. Did that not work as a response for your API for some reason?


It works fine, but the typescript types that prisma generates says that type is a date, not a string. So I can't directly use that as the API response type, I have to modify the prisma type to get it to work correctly on the FE.

Does that make sense?




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: