Ask HN: Which full stack framework (NextJS, Remix, SvelteKit) would you use? And why?
(Please do not answer with the usual "Use what you have most experience with" or "It depends on the use case") Also what libraries/services do you prefer to use in combination? For example: -Auth -ORM/Db connector -Email -Deployment (VPS/Container...) |
If I’m free to decide the tech stack it is HTMX with a backend technology that suits the business case. For web related work I usually choose Node.js and fastify without template engine. It’s fast and easy going.
If I was forbidden to use that, I'd probably use Ruby on Rails, Django or something like that.
Is it possible to build “nice” websites like that?
I have made a number of fully profitable (and pretty nice) websites over the last few years using that stack.
I can't point to any specific resource for learning how to do it other than the official docs regarding writing web applications [1]. For me, it all started there and evolved over time.
It has Auth, Templating, ORM, Email, Caching, Forms, Validations.
For frontend I like Bootstrap or Tailwind as a base, but for interactivity I use a combination of htmx and Alpine.js, so everything's pretty light-weight.
In the frontend world, I started reducing my reliance on it. I started quite a while ago and had went through jQuery, jQuery UI, bower, gulp, grunt, AngularJS, then the completely rewritten Angular 2+, Vue.js, npm, yarn 1, yarn 2, yarn 3, webpack, rollup, Parcel.js (which I like)...
It was too much for me to keep up. So I stuck with Symfony and try to keep the frontend light-weight.
My problem with the ones you are mentioning (next, remix, svelte kit, etc) is that 1) they are not a full solution… you still have to figure out everything else, from authentication, authorization, sending emails, ORM, background jobs, etc… and 2) they’re in constant shuffle and rewrites and change of opinions so maintaining long running projects on these frameworks quickly becomes a nightmare.
If it’s for learning or a side project, then pick whatever. If it’s for business, pick tried and true and something g you’re confident in 2 years will be still maintained and not be a totally different beast (ehem, next).
Which one is it?
Or please, describe how are you doing in your super simple stack:
Authentication, authorization, background jobs, assets bundling, migrations, emails, security (csrf,rate limiting, timing protection, etc), and everything else provided by batteries included frameworks.
I'd say you almost never need file-based routing, I'd even go that far to say you don't need routing DSLs for backend (just use if statements, performance will be fine without compiled regular expression to match all routes). The fetch API has request and response objects, and URL and URLSearchParams. But in frontend I find react-router-dom very practical. I think they introduced file-based routing in NextJS and co, because it's easier to generate frontend code bundles per route by listing files at build time. Other than that it's just a gimmick.
And as already mentioned ORMs (object-relational mappers) will give you headaches really soon, it's probably not worth it.
You can use Vite for the frontend part which is more lightweight than NextJS and co. I'd say if you have or your team has already build a web application with such full stack framework once you probably know what is needed and what is not needed in frontend with Vite.
Care to elaborate?
Do you are anyone else have experience with this and can tell me how well it works in practice and if you hit limitations very fast, where you need to hack something to make it work?
https://mdwdotla.medium.com/using-rust-at-a-startup-a-cautio...
2) is it production ready?
2) Yes and no, it really depends on your requirements. We have already created two customer projects with it and are very satisfied (although I personally still prefer the Elm approach to the reactive approach).
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.
- It’s so much easier to manage file-based routing. 1 new page == 1 new file.
- Super flexible about client/server-side code on each page
- It’s concise, and easy to understand. The amount of code in a hello-world project is tiny, but scales up to large apps really nicely
- Easy to share things between client and server, typescript enforces type checking between client/server too
- It’s mature, has a huge community and backed by Vercel.
Some cons… I hope you like JavaScript
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 idea behind these libs and frameworks are that wacky, unique or unordinary.
Prisma ORM, is a little opinionated, and you could swap it out for Drizzle, which is basically typescript side sugared SQL.
TRPC might be also be a little sticky because it is tied to typescript, this is the tradeoff for the buttery smooth coupling for the fullstack experience. I think there exists a typed-rest solution out there, but haven't used it.
Personal anecdata, I used this stack for a little hobby project and it was FUN.
It's not exactly the same as next/remix/kit, but does most of the same stuff and is a delight to work with. I love Svelte as well but SvelteKit, not so much
The loaders and actions for loading and updating data just makes sense. Server side rendering just makes sense.
Next.js, Remix, Astro, and Svelte are another layer of abstraction i dont want to deal with.
I feel like if, down the road, I decided to ditch a framework altogether, writing it in Svelte may help seeing as there are very,. very few framework specific elements in it. I may also be deluding myself.
wanna try Astro though
Looks like there's preview support for joins now, so at least they are getting there...
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 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.