4 ms·
Haven't tried sveltekit but I think it's nicer than next because it "uses the platform" more like the standards are supposed to. You will never get a button tha
by ecmascript 3y ago
Haven't tried sveltekit but I think it's nicer than next because it "uses the platform" more like the standards are supposed to. You will never get a button that is not clickable because some javascript is not loaded.
It's also more straightforward to get started and has sane defaults for the different "stacks" that exist. It's also way easier to self-host. So there are many positives for remix.
I would say if you know that you are going to use Vercel, use Next.js but otherwise I would always argue for Remix. I was a bit hesitant towards React before but Remix had me totally converted due to how easy it feels developing a full stack react app. Nothing even comes close in the javascript land imo. I have done years of work with SPA with web components/Vue/Angular and an api but using Remix I feel like I am several times more productive.
You don't need a state machine with remix as long as you use a backend (I haven't tried the new Remix SPA mode yet), even if you have a backend in another language it is a great way to do backend for frontend meaning that you can gather the data you need and provide it to the client in a nice way. No more spinners everywhere, let your fast server do the api calls and serve the rendered page to the client. You won't have the issues that usually comes with a SPA if you use Remix with a backend. You can stream stuff if you know you have requests that will take a bit longer to complete: https://remix.run/docs/en/main/guides/streaming https://remix.run/docs/en/main/guides/streaming
You can read more about why remix is nicer here: https://www.epicweb.dev/why-i-wont-use-nextjs https://www.epicweb.dev/why-i-wont-use-nextjs
- 0xblinq 3y ago> I would say if you know that you are going to use Vercel, use Next.js but otherwise I would always argue for Remix. Exactly. It makes absolute no sense to deal with all of Next's artificially imposed limitations if you're running it on your own servers.
- ervine 3y agoWhat limitations? You mean like not being able to use the full node API in your middleware that's being run by the node server that you control in your own infrastructure? And how about that dev rel... no response since August of last year. https://github.com/vercel/next.js/discussions/46722 https://github.com/vercel/next.js/discussions/46722
- 0xblinq 3y agoThis is done so that you never use it (even in your own servers) because otherwise you won’t be able to move to their cloud. This is why you don’t use VC backed dependencies that are not easy to move away from.
- gedy 3y agoRemix is really cool and agree with most of your link, but: > Next.js is on version 13. React Router (built by the same team as Remix) has been around for much longer this is not a selling point for me. React Router has been such a pain to deal with and upgrade, Next was much nicer to use in apps in comparison.
- colinramsay 3y agoI think (hope) they learned a lesson from this, as Remix is very good at not introducing breaking changes: https://remix.run/docs/en/main/start/future-flags https://remix.run/docs/en/main/start/future-flags
- peterb0yd 3y ago> "if you know that you are going to use Vercel, use Next.js but otherwise I would always argue for Remix" Hmm. I'm using Remix and Vercel for a side-project right now and it's pretty awesome. Lightning fast build times (around 30 seconds). At work, I use Vercel with Next.js and our build times are in the one-three minute range.
- ecmascript 3y agoYeah obviously you can use Remix at Vercel as well, but since Vercel is the company behind Next.js I would think you will probably have a better time using Next.js with Vercel. Altough, I have never used Vercel so that was just an assumption from my part. From my understanding though, they make it really easy to host Next.js apps with Vercel. I guess the good part of using Remix if you use Vercel is that when they pull the rug from beneath you, you can always switch to another hosting provider.
- no_wizard 3y ago> You will never get a button that is not clickable because some javascript is not loaded. I'm open to being wrong here, but this is symptomatic of the developers who implement the components, not the frameworks no? I'm unaware of any major framework that hijacks buttons, you very specifically have to not use the `<button>` element to not get a button. If what you really mean is an action can still take place even though some JS wasn't loaded (e.g. web standard form submission) then I understand, but otherwise I'm not sure how frameworks are at fault for this issue