Live data from Hacker News

Ask HN: Which full stack framework (NextJS, Remix, SvelteKit) would you use?

news.ycombinator.com

51–57 of 57 posts

Re: Ask HN: Which full stack framework (NextJS, Remix, SvelteKit) would you use?

#51
I prefer using Next. I've been using Remix at the day-job for about a year now. It's fine, but I still choose to use Next with all personal work. I'd also prefer to work with it professionally. My personal dev-blog started in v12, I upgraded it to v13 a while back (not much involved in that upgrade), and at this moment am refactoring it to v14. A lot has changed, and for the better.

It provides a great solution for most needs and problems. But I think the biggest selling point is that their docs are excellent. I never connected with the Remix docs...they often left me still confused. I've used Remix v1 and updated our two work repos to v2. I still don't feel fluent with it for some reason and often find myself thinking "I prefer the way Next does this".

Someone else here mentioned the T3 stack. That's a good resource to at least see other libraries/services that work well with Next. You don't need to follow any of it blindly, but use it as an information resource.

Re: Ask HN: Which full stack framework (NextJS, Remix, SvelteKit) would you use?

#52
post #49
post #11

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.

Re: Ask HN: Which full stack framework (NextJS, Remix, SvelteKit) would you use?

#53
post #49

Earlier quoted context omitted.

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.

Re: Ask HN: Which full stack framework (NextJS, Remix, SvelteKit) would you use?

#54
post #53

Earlier quoted context omitted.

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 AP…

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.

Re: Ask HN: Which full stack framework (NextJS, Remix, SvelteKit) would you use?

#55
post #53

Earlier quoted context omitted.

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 AP…

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…

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.

Re: Ask HN: Which full stack framework (NextJS, Remix, SvelteKit) would you use?

#57

I would recommend - https://create.t3.gg/ It uses the following, which as of late are pretty well know and common, so you can punch in your problems to stackoverflow, google, or chatgpt and get some pretty good answers. It uses: Nextjs (React), typescript, trpc (typescript rpc), auth, tailwind, and Prisma (ORM for sql and mongo) Though of course these could go out of fashion tomorrow, but I don't think the essential…

Isn’t trpc redundant now that next’s server actions are out?

Helps with larger apps that are not solely Next.js
Post reply on HN