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
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.
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.
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.
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.
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
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.
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.
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.
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.
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 :-)
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.
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.
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.
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.
They sponser https://github.com/kdy1 (see the vercel in his profile), who spearheads swc, which is very similar in goals and scope to esbuild. swc may ring a bell, as it's the parser/compiler that is used by deno and bun.
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.
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
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.
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
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
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.).
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.
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.
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)
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?
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).
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.
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.
Ah. In that case, that is not a mode (which is why I misunderstood), that is the default way Remix works and it's more or less what every user of Remix is doing. Some people might implement API endpoints in Remix itself, but for the most part people are calling out to APIs in loaders.
We have an API written in Rust that serves the RFD contents and powers search. For logged-in internal users, we are also talking to GitHub APIs in loaders to pull in PR comments.
Ah interesting. How do you generally handle auth between FE <--> Remix BE, and Remix BE <---> Other services?
I could just keep my auth backend in go, on maybe like auth.mydomain.com, and issue cookies for .mydomain.com, which the remix BE can handle. This way the remix BE is really just a thin "api gateway" in a way.
We use cookie auth only for the Remix server. The API uses OAuth, or something close to it. So when a user logs in, we get a token from the API (scoped to the particular user, not a special backend super-token) and store it in the session (encrypted in the cookie value, Remix server has the key — this is built into Remix: https://remix.run/docs/en/main/utils/sessions). That token is then used by the Remix server whenever it talks to the API.
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.
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?"
As someone who's evaluating both Remix and Next right now Remix makes it very clear and front-and-centre that you can (and perhaps should) bring your server. Next documentation barely mentions it, if you're lucky to find anything at all and in some parts they discourage it and push you to embrace the "serverless/edge" future.
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
What 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.
> 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
Yeah 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.
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.
I haven't tried Remix, but the sentiments in the comments makes me feel it's another framework that sounds like it's sick of the current complexity around stuff like SvelteKit and Next, but that's exactly how I felt when Svelte came out 3-4 years back, so what's to stop this from going down the exact same route where "just one more feature" snowballs into something unrecognizable?
I maybe don't understand the parallels being drawn at the moment, so this view is subject to change when I dig in a little deeper.
Finding the right abstraction is hard. To me in seems clear Next is tuned for Vercel Now. If you build in a compatible way it works great, it's a nice "serverless" setup for serving pages. There's a whole range of use cases this doesn't work for: eg realtime apps, apps that care more than average about security, etc.
> It is an explicit goal of ours to design APIs that are high-level enough to help you just get the job done, but close enough to the web to backfill your fundamental knowledge of Kung Fu the web.
tbh I am not sure I agree that's a selling point, how much can you abstract away till people have no clue what's happening internally and are lost when usecase X is more complicated than simple CRUD.
If I want to learn web fundamentals I SHOULD learn web fundamentals, not through an API that makes it seem like magic, because it's not transferable to other frameworks/platforms. This creates problems for new developers as well, who in this day and age learn frameworks instead of the underlying tech, and then bring that mindset to other domains.
I've had so many React devs being unable to work with say a Svelte or a vanilla HTML/TS applications because their web development skills are actually React skills.
For ex this line here
"When you learn how to handle requests and send responses in Remix, you're actually learning the Web Fetch API that's in the browser already."
I'd rather just use fetch so I know explicitly what I am doing.
I’m one of those using remix and I do like it a lot, but I don’t have much hope. I wish I’m wrong but probably in a couple years we’ll be all hating it. I also liked next a lot in the early days. Somehow they always manage to fuck yo and nothing reaches “Rails” levels of stability/popularity in the js world.
Compared to React, Svelte is great, but compared to Svelte from when it came out, it's pretty different.
I started using when Svelte+Sapper was a thing, simple filesystem routing was the great selling point, then came SvelteKit which introduced plus based routing like +page.ts,*.client/server.ts, inside folders which IMO is a bit more tedious.
and now there are runes, I spent sometime understanding the reactivity syntax using $ and could intuit around it pretty well, but now I've got to re-learn that as well xd.
Note though, I still love Svelte and don't have an issue re-learning since I knew using it before pre-1.0 would certainly involve breaking changes, but the API really did move around a lot and caused some issue.
It's also pretty clean to write and understand Svelte code, feels almost like writing pure HTML/TS.
I personally have built multiple enterprise grade applications (something akin to Substance Painter) using Svelte, and though the reactive dependency chains got long (due to my own faults) they were easily abstractable and resulted in code that's still able to be maintained by junior devs and has survived multiple refactors due to the changing APIs with minimal friction.
I've just started playing with Remix since it seems to be the recommended route for Shopify app development.
I must say I'm not entirely blown away by it. It's unique feature (frontend/backend coupling) kind of feels like it's just a re-engagement with the traditional web app. Or even just akin to a mono repo for a modern frontend/backend.
Beyond that, it's main let down (which is in no way unique to it) is not having a straight forward application entry point that allows you to wire things up as you see fit (composition root). Instead we get a request handler that we hook into another server technology that in turn makes their controller equivalents work like magic.
My struggle with it, as of this afternoon, was to figure out how to bundle raw SQL files in the build until it became apparent that you have to unbox all the Vite functionality and do it that way (which seems to have some depth) or literally have a parallel step outside the build for copying the files into the build dir. Not the greatest experience for what is a pretty basic step (embedding resource files in the build output).
Very much feels like a project that is just a small twist on what already exists in the ecosystem and will fall into the growing black hole of JS web frameworks. Sorry to be glum :/
To execute them against a database during runtime. I'm a little amused as to the question, I'm certainly not using them as tea coasters.
Edit: and maybe to add more context (and a bit less glib). My approach to interacting with an rdbms is to put each query in a separate SQL file (so no dynamic SQL and no query builders - ORM or otherwise) and execute them with a simple db client. In this case pg-promise. I've landed on this approach after many years of using various approaches and seeing how those approaches take affect on a team/product over time. Though of course ORM vs raw SQL is an argument as old as time (or as old as ORMs at least).
clicking the link all the text seems to restyle multiple times - the fontsize seems to flash 'bigger' at least twice before settling. looks very unsettling.
I definitely can appreciate this sentiment, but I will also add that for me Remix feels like a simplification more than something that's added complexity. It also leans heavily into the Web APIs so you get a lot of non-framework knowledge when you use it.
Personally, I haven't experienced that kind of "this is simpler" feeling since jQuery.
> It also leans heavily into the Web APIs so you get a lot of non-framework knowledge when you use it.
This is thrown around by each and every framework so much that this lost any meaning. What does it mean? Which of the 11 custom React elements (including Link, Form, Await) and 26 custom React hooks are "simplification and leans heavily into Web APIs"?
Here are some simplifications that are worth mentioning, I think, of course, it's easy to find fault with any of them. But I'd be curious in what you think is a better alternative.
- loader, action, component colocation
- code splitting without thinking about it
- automatic data revalidation on mutation
- useFetcher for optimistic updates
In terms of the fancier things (the react components) -- none of that is necessary. Personally, I don't use <Await> or <Defer> at all. Although it's nice to know that I need to pull some performance levers, I have those options.
One React component that I do use a lot is <Link>. The thing I love about it is that I can add a <Link prefetch="intent"> to it, and I'll get an near-instant page load when I click it.
The web APIs that I work with in Remix are Request, Response, Headers, Cookie and FormData.
> Here are some simplifications that are worth mentioning, I think, of course, it's easy to find fault with any of them. But I'd be curious in what you think is a better alternative.
Simplification compared to what?
A better alternative to what?
> In terms of the fancier things (the react components) -- none of that is necessary.
It doesn't matter if they are necessary or not, they are there in the framework.
> The web APIs that I work with in Remix are Request, Response, Headers, Cookie and FormData.
That's.... it? You call that "leans heavily into Web APIs"? Have you ever thought of what backend services do all day everyday? These are not "web apis". These are wrappers over HTTP.
It’s the framework of the week because now it’s when it’s getting popular, gaining traction and everyone is trying it out.
Not because of how long has been in the make.
