Hacker News new | ask | show | jobs
by mmckelvy 624 days ago
My bet is on Remix (which will eventually just be React Router). I think it's just the right amount of abstraction over native web functionality with a nice, simple API that doesn't deviate too much from web standards. I also think the full stack approach just makes sense for developing on the web.
3 comments

Remix is backed by Shopify, compared to Next.js being backed by Vercel. Does this influence any decision to take?

Today Next.js has a big advantage which is that they have already integrated most of the new React 19 rendering features and apis. I think it will take a while for Remix to catch up to that.

Other notable frameworks are community led Waku made by Daishi Kato from Pmdrs and TanStart made by Tanner from Tanstack.

Also there's Redwood.js betting on a more integrated experience.

Today I am using Nextjs because I don't think I can go back to not using RSCs, but when Remix catches up or Waku and TanStart get to v1, I sure will give them a serious try!

Shopify "backing it" means less to me than the maintainers themselves. The Remix maintainers are straight shooters and have been maintaining open source consistently for over a decade now.

I also just like their API and design decisions.

> Remix is backed by Shopify

This makes me distrust it (slightly more than I distrust Next/Vercel).

Shopify's core business is not in making javascript frameworks. Remix is always one bad Shopify away from being ejected.

> which will eventually just be React Router

how strongly do you believe this. because ive just read both docs and i think they have different goals/audiences (tho obviously same owner). i think react router will be a poorer project if it starts to require serverside components like it is looking

They made an announcement that they are merging the projects a little while back: https://remix.run/blog/merging-remix-and-react-router. Obviously things could change, but I think RR v7 will effectively be the next iteration of Remix.
ah yeah. they didnt quite address my concerns in that post. but they know better than i.
I'm a huge remix fan. Remix, Shadcn, postgres, and Prisma have been great for rapid development
Agreed, minus the Primsa.
Honestly, I hated Prisma for the longest time. Like, hated it. I tried to rip it out of projects multiple times. Why would you build a node library in Rust? (as one of many problems) But, I had a mental shift recently that helped me appreciate it more: I use Prisma only for features that fit neatly into an simple ORM (i.e. building a web page based on a bunch of joins). Anything else, I use raw SQL.

They released TypedSql (https://www.prisma.io/docs/orm/prisma-client/using-raw-sql/t...) which is heavily inspired by PgTyped. That lets me write raw Postgres SQL that's converted into TypeScript. The other things I do:

- If I want derived data, write views that encapsulate the transform. Prisma supports reading from views - If I need something more complex, use DuckDB + python for analysis and write to the appropriate table. - If I need to cache complex queries, just use a materialized view and read it as a prisma object

It's not perfect, but that let's me use prisma for what it's good at (Managing an ORM and deeply nested queries), then fall back into raw SQL for everything else.

Going straight to SQL has been a breath of fresh air, but, let's be honest, dealing with deeply nested joins really sucks when all you want to do is build a page that shows a company, all of it's people, and all of those people's relationships. ORMs are pretty handy for that last case, and I use SQL for everything else

Check out Kysley: https://kysely.dev/
I've looked into it a bit. I'm getting to the point where I either want to use a full ORM, or I want to write raw SQL and have it checked against the database.

Query builders are nice, but they sometimes end up in this middle ground where they have the worst parts of an ORM (needing to learn a new syntax and not getting access to all the DB features) and the worst parts of raw SQL (Unpacking relationships into objects w/ pointers is error prone boilerplate that sucks to write).

I love SqlAlchemy since it's still enough of an ORM to solve the main problem I want solved. Super curious to hear if you've had good experiences with Keysley and how it deals with transforming relationships into objects