Readit News logoReadit News
aniforprez · 2 years ago
Remix is a wonderful, sane framework that I highly recommend for React developers. No monkey patching, no global context imports, no undocumented functionality etc etc. Had a hell of a time trying to wrangle Next and it was terrible. Next still doesn't have a way to completely disable prefetches on hovering over Next links unless you use a plain anchor tag which is the kind of insidious, undocumented behaviour that makes for weird bugs (setting prefetch to false does not disable prefetch on hovers). Remix just sends you browser and node objects like a standard request object in all the arguments and just uses the platform with the framework extensions acting as a nice layer on top
throwaway77384 · 2 years ago
Very interesting. Another Next victim here. One of my anecdotes is the bonkers caching / fetch deduplication. Yes, set cache: no-store. But that only works for fetch requests. If you have a 3rd party lib doing the fetching (say, Google Firestore), then you have to declare export const dynamic = 'force-dynamic' at the top of your route segment: https://nextjs.org/docs/app/api-reference/file-conventions/r...

That behaviour wasn't documented when I got started with NextJS 13...imagine the fun I had trying to work out why I can't get updated data from the server. It was nuts.

wyattjoh · 2 years ago
You can actually call `unstable_noStore()` from `next/cache` to do that without needing to set it on the segment level[1]! We're working on improving the DX around Dynamic API's to make it a seamless experience.

[1]: https://nextjs.org/docs/app/api-reference/functions/unstable...

dbbk · 2 years ago
Honestly this whole RSC/app router endeavour just seems like a mistake. So many strange buggy and undebuggable behaviours. To what end? We have a basic SSR React app and it serves millions of users while cached by Cloudflare. Works perfectly.

KISS.

robust-cactus · 2 years ago
Another insidious thing in Next: their middleware is completely sandboxed and you can't use any standard Node functionality. It doesn't matter if you're using vercel now or not, and there's no way to disable this.

This is pretty important for things like sessions with httpOnly cookies. And it forces you make an API call to yourself to resolve.

ervine · 2 years ago
https://github.com/vercel/next.js/discussions/46722

If only this had been brought to their attention recently with a bunch of good-faith discussion.

0xblinq · 2 years ago
This 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.

no_wizard · 2 years ago
Remix has improved substantially since Shopify took over the project. Remix adopting Vite makes it a real choice. Prior to that acquisition, they made some, what I believe to be, bizarre API choices.

now you can simply use the full power of Vite, which means you aren't locked into Remix having to make choices for you.

This is the 3rd time they migrated the underlying tech though, first it was rollup, then esbuild, and now Vite, which is effectively rollup again. I hope they stick with Vite for the foreseeable future though

0xblinq · 2 years ago
I like remix and I have big hopes for it, but the devs do have a horrible trajectory of breaking things and leaving everyone behind. But sadly this is so common in the js ecosystem. There’s no stable option.
steve_adams_86 · 2 years ago
I placed their Link component within a polymorphic wrapper which could switch between Link and plain anchor elements depending on the props given. The typing was gnarly, but it worked well. By default it would be a Link as I recall, but things like a non-relative href or use=“a” props would swap it for an anchor. And maybe other things, I’m not sure. It would reject Link props if it knew it was using an anchor element, though.

I’m ashamed to say this took way too long to get working nicely. It was worth it because our linting otherwise went crazy over misuse of Link and anchor, and people on the team weren’t respecting it. This made it so we could say “only use Link” and make it easy for that to be accomplished.

Trust me, it’s way easier to get stuff done with Next :)

Once you get past the day or three spent making it so links do what you wish they did… And you discover it handles cache headers differently than it’s supposed to… And middleware doesn’t work in several contexts with no explanation… And on and on.

lobsterthief · 2 years ago
This is also how I did it—also played nicely with ensuring MuiLink always get used on our MUI site.
j-krieger · 2 years ago
I hate the added complexity in later releases of React and Next. There‘s always multiple ways to achieve the same thing with surprising side effects.
tshaddox · 2 years ago
Interestingly, I no longer see Next Link prefetching on hover when the prefetch prop is set to false. At some point in Next 13 it was doing that, but in Next 14.1.0 I no longer see it. I’m not sure when or why it stopped.
dimal · 2 years ago
Can anyone who has used Remix comment on the API stability?

AFAIK it’s built by the same folks as React-Router, and I have a distrust of that project because of the tendency to make large breaking changes in order to make things “better” according to some criteria. I’ve been through a few RR upgrades that required a lot of extra work because we were using some previously supported pattern that then disappeared. I like the look of Remix but I don’t want to get trapped in that kind of situation again.

scottcorgan · 2 years ago
Most of RR’s breaking changes were years apart, which is way less often than almost all JS libraries.

But, Remix’s breaking changes start as future flags on the current major release and slowly become breaking changes over time.

That means you can incrementally adopt the breaking change so the upgrade isn’t all at once.

skrebbel · 2 years ago
I don’t know anything about Remix but I was around when React Router was first launched. I remember strongly disliking the API and concluding that it got popular not because of any particular quality, but because its name was exactly what everybody typed into Google. That’s a nasty thing to say, but bear with me. Thing is, today, doesn’t suck at all!

I suspect the original author might’ve very much learned how to do API design on the fly when those first major versions of RR were shipped. Ie: the hard way, because every change they made caused a lot of complaining (for good reason maybe, but still! People complaining about your open source project is not fun)

So maybe if anyone has a nuanced and wise view of API design and versioning, it’s the RR people :-)

joshmanders · 2 years ago
This is exactly what happened. Both Michael and Ryan have expressed this countless times in many talks that a lot of the API churn in early years was because they were learning just like everyone else.
jackbravo · 2 years ago
Just migrated a couple of projects from remix 1 to remix 2. It wasn't a walk in the park, but it was well planned by their team, by first adding feature flags to v1 where you could slowly adopt v2 APIs, and then switch. I think you can even run v2 with a v1 API backport layer. So I think they have a good approach to stability vs improving their product.

The really hard part has been migrating other stuff like CJS to ESM, or upgrading other dependencies like cypress, but that is not related to remix.

0xblinq · 2 years ago
Stable as jelly. As everything in the js ecosystem, sadly.
CharlieDigital · 2 years ago
This makes me think back to the Next Conf when Vercel announced Turbopack and threw out some questionable metrics and reasons why they couldn't adopt Vite. That was the most marketing hype I've seen from a tech conf. Watched the Microsoft Ignite conf afterwards and it was night and day: one looked like a marketing event, the other looked like a nerdy engineering event.
sod · 2 years ago
Vite and webpack (and thus turbopack, which is advertised as a webpack successor) are two different beasts.

While vite is perfect for most users, there are just some usecases that are not doable with meaningful performance. Without boring you with details why, let me assure you that having a performant webpack replacement for those 10% who need it, helps vite staying lean, as they are not bothered with feature creep.

If you want a small detail why: Vite is built on esbuild. Esbuild is carried by a single developer (https://github.com/evanw/esbuild/graphs/contributors) thus every nut and bolt that vite does for you on top is built in javascript, so you are in slow-land again.

webpack and turbopacks promise (and complexity) is that it treats these extras (plugins and loaders) as first class citizens and thus tries to make them as fast as possible by applying tons of caching. E.g. if you'd throw a webpack workflow at vite, you might end up with a slower build then webpack. And this is where turbopack tries to improve.

CharlieDigital · 2 years ago

    > Esbuild is carried by a single developer 
The right answer is to support that developer and contribute to the project.

The VC answer is to build something entirely novel and then fail to deliver.

zdragnar · 2 years ago
You can swap esbuild out for swc in vite and get whatever swc plugins you need. There's not a ton available, but more then enough for my needs at least.
davedx · 2 years ago
Vercel are high on their own supply
reducesuffering · 2 years ago
Vite isn't a drop-in replacement for 90% of JS projects that have existing webpack infra.

Turbopack is made with that in mind.

That's not Vite's priority, it wants to have a novel approach without backwards-compatibility in mind.

willsmith72 · 2 years ago
i love love love remix, am so glad i chose it a couple of years ago and now use it for everything

that said, i wonder if anyone has advice on a couple of things

1. typesafe routing and fetching, e.g. using useFetcher then fetcher.submit({title: 'hi'}, {action: '/blog'}). i would love both the {title: 'hi'} and the 'blog' to be typesafe (as safe as you can get in typescript)

2. i still haven't got onboard with using uncontrolled inputs, so i end up using react hook form again. i feel like eventually i need to "watch" one of the inputs, and the main thing again is the typesafety. with react hook form, i can declare my form with zod and be sure it's exactly what i'm then submitting to the server, and revalidate it there. any good ideas here? i would love to get the progressive enhancement from not using js

jackbravo · 2 years ago
I like using https://www.remix-validated-form.io/, which you would use to get a type safe validated object before doing the submit. And then you could reuse the validator on the backend as well.
aniforprez · 2 years ago
1. There was one library that would generate types for your routes but it doesn't work properly with the new vite config. I think one of the contributors is working on a library to add that to vite

2. I use remix-hook-forms. It's got helpers that validate on server side and lets you send the errors back to the client and that will display the error on the frontend. This way you can have server side additional validations and send those errors to the client

whoishiringbrad · 2 years ago
Have you seen conform.guide? It just became 1.0.0. It's pretty similar to react-hook-forms -- but it's a lot more remix-y.
willsmith72 · 2 years ago
i tried it but it seemed like i'd need to create a new react state field manually to "watch" the fields myself, which was a bit of a turnoff. makes sense you can't watch it before js has loaded, but it's such a common use case for me
clivestaples · 2 years ago
Remix is great and it's my favorite meta framework. I've used it on some quick MVPs and a blog but when it comes to production apps as one-man-shop, I always go back to my safety zone of Rails. For those running robust Remix apps: can you share your stack and where you deploy? How are you doing auth? Are you on a team or doing solo work? I'm genuinely curious because I would love to leverage so much of React (UI components, etc.).
kenn · 2 years ago
Experienced solo Rails dev here.

I'm on Remix / Drizzle ORM / Render.com / Render Postgres / Cloudflare R2 / DaisyUI + shadcn/ui these days.

Drizzle can be a bit tricky if you're coming from ActiveRecord but once you have your own helpers with a base class that implements common method such as find_by({ key: value}) / create({ data }) / update(id, { data }) / delete(id), things get better.

Render is really good - you don't need any specific configs, just set env vars on their dashboard and git push to deploy. Simpler and better than Heroku workflow.

You can take a look at https://github.com/remix-run/blues-stack to learn how you'd manually implement cookie-based auth on this framework.

Remix is the closest thing to Rails in the JS ecosystem IMO

CuriouslyC · 2 years ago
My stack is Remix + Hasura + FastAPI + Postgres, with Apollo client and Tailwind. In my opinion this is the best in slot loadout for the majority of web apps in 2024.
0xblinq · 2 years ago
Everyone thinks their preferred stack is the best in the world and should be used by everyone for everything and everything else is wrong.

It’s so funny.

0xblinq · 2 years ago
At work we are using Inertia.js as an interface between React and Rails (inertia is just a tiny library/protocol that lets you use React or Vue replacing your mvc framework templates)

Check it out, it’s really nice.

JoshGlazebrook · 2 years ago
I've been looking at Remix a bit recently and it looks really cool, but the part I'm not too fond of is having to use Node on the backend. I moved to writing all of my backends in Go after I was burned by the whole ESM/CJS/TS disaster. But there doesn't seem to be any true way to get reliable/feature full SSR with a backend that is not javascript based.

I do see that has has a BFF mode, but I can't really find any instances of many people using it, or at least writing about it. Does anyone have experience with BFF mode?

I think I may just stick with React + Tanstack router + Tanstack query + zustand for now and try the BFF model eventually?

acemarke · 2 years ago
React is a JS library, so it needs a JS runtime to execute outside the browser.

It's hypothetically possible to use a JS runtime as a subprocess from another language to use React for plain HTML SSR, but it probably wouldn't work for React's streaming HTML generation (or at least would likely be very difficult to get working).

dcre · 2 years ago
SPA mode (what I assume you mean by BFF mode) is brand new, so almost nobody has used it. However, a close example would be the Oxide web console, which we build as an SPA because we want to serve it as static assets from a Rust backend. It's very close to your suggested stack: React + React Router + Tanstack query + zustand, though importantly we also use React Router's loaders to give the app a better-than-SPA feel on navigations. I do plan on moving it to Remix SPA mode when I get a chance, but like I said the result should be very similar so it's not that high a priority for me. If I were starting from scratch I'd probably use Remix SPA.

Repo: https://github.com/oxidecomputer/console/

Live demo here with in-browser MSW mock API: https://oxide-console-preview.vercel.app

JoshGlazebrook · 2 years ago
This is what I'm referring to when I say BFF - https://remix.run/docs/en/main/guides/bff

Essentially, its the backend for frontend model, where I guess you really just have a node backend specifically for hosting your frontend app, so you get all of the advantages Remix/SSR/etc provide. The node server usually would handle auth between the frontend and the node backend with a cookie, and then the node backend would call your other backend services, either by forwarding the auth the frontend client sends, or transforming it into maybe a JWT token, or just mTLS? aka a glorified proxy server I guess.

ecmascript · 2 years ago
This is awesome news. Remix has become my standard go-to for all new projects. They have really sane defaults and together with stuff like their indie-stacks etc developing apps goes really super fast.

I have never been so productive as I have been with Remix and it's really good that the finally have embraced Vite so I can use all the different plugins etc that exist for it.

rpastuszak · 2 years ago
How would you compare it to sveltekit or next in this regard?
nobleach · 2 years ago
Remix is _just_ a really nice request handler. That means you can bring your own server (instead of getting locked into some specific implementation). There's a lot of benefit to the Remix team's "Use the platform" mantra. This means that you don't always have to go looking for "the Remix way to...." on Google. This was a major frustration with NextJS. "How do I run a function when the server boots up in NextJS?"
ecmascript · 2 years 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

You can read more about why remix is nicer here: https://www.epicweb.dev/why-i-wont-use-nextjs

gherkinnn · 2 years ago
A telling example from the Remix docs [0]. It is an elegant layer over native APIs.

> This is a Fetch Request instance. You can read the MDN docs to see all of its properties.

Compare this to Next's app router equivalent of fetching the request headers [1]:

> The headers function allows you to read the HTTP incoming request headers from a Server Component.

[0] - https://remix.run/docs/en/main/route/loader#request

[1] - https://nextjs.org/docs/app/api-reference/functions/headers

klysm · 2 years ago
I really have a strong distaste for remix because of the way react-router was hijacked
AprilArcus · 2 years ago
Hijacked? Can we not still use react-router in a standalone capacity as we have always done?
dcre · 2 years ago
React Router is still great, and in fact has gotten dramatically better as a result of its place at the core of Remix. Data router eliminates loading spinners and makes your SPA feel like a real application.
lowboy · 2 years ago
Can you expand on how it was hijacked?
WuxiFingerHold · 2 years ago
I'd called it an innovative evolution by the creators of react-router.