7 ms·
Remix Vite Is Now Stable
- daef 3y agoclicking the link all the text seems to restyle multiple times - the fontsize seems to flash 'bigger' at least twice before settling. looks very unsettling.
- azangru 3y agoInteresting. I am not seeing this at all, even if I disable browser cache. Core web vitals in Lighthouse are stellar; cumulative layout shift is 0.
- ecmascript 3y agoThis 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 3y agoHow would you compare it to sveltekit or next in this regard?
- ecmascript 3y agoHaven'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.
- nobleach 3y agoRemix 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?"
- dham 3y agoTo be fair, you can use a custom server with Next.js too.
- laurels-marts 3y agoAs 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.
- gherkinnn 3y agoA 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 https://remix.run/docs/en/main/route/loader#request [1] - https://nextjs.org/docs/app/api-reference/functions/headers https://nextjs.org/docs/app/api-reference/functions/headers
- robertoandred 3y agoNext's headers function is an elegant layer over the Web Headers API.
- gherkinnn 3y agoBut I want the request. Remix points the reader to the MDN docs. Next invents its own little thing. This is the fundamental difference in philosophy.
- robertoandred 3y agoThe Web Headers API isn't Next's own thing. They point you to the MDN docs. And if you want a route's request object in Next, use a route.js file.
- aniforprez 3y agoRemix 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 3y agoVery 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/route-segment-config 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.
- dbbk 3y agoHonestly 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.
- willsmith72 3y agoi 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
- aniforprez 3y ago1. 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 3y agoHave 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 3y agoi 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
- ecuaflo 3y agoTesla has a nice one that seems to make this easier [0] [0] https://teslamotors.github.io/informed/api-reference/useFieldState https://teslamotors.github.io/informed/api-reference/useFiel...
- CharlieDigital 3y agoThis 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 3y agoVite 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 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.
- zdragnar 3y agoYou 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.
- CharlieDigital 3y 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.
- 3y ago
- boringuser2 3y agoWhat will the new framework next week be?
- twojobsoneboss 3y agoHey now, new framework makes your brain work
- whoishiringbrad 3y agoI 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.
- troupo 3y ago> 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"? --- As a side note, here's how it tells you to add a stylesheet to the app. So simple, much Web API: https://remix.run/docs/en/main/start/tutorial https://remix.run/docs/en/main/start/tutorial import type { LinksFunction } from "@remix-run/node"; import appStylesHref from "./app.css"; export const links: LinksFunction = () => [ { rel: "stylesheet", href: appStylesHref }, ];
- whoishiringbrad 3y agoHere 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.
- h4ch1 3y agoI 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.
- ulimn 3y agoI think one could say that Remix is simple in the sense that there is less magic and reinventing the wheel like in the case of Next. It's not simpler as in less features.
- robust-cactus 3y agoFinding 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.
- azemetre 3y agoWould you care to speak about cases where Svelte added “one more feature” that ruined simplicity? Or were you referring to something else? Genuinely curious as I’m burnt out of the react ecosystem entirely. Svelte seems good but haven’t done much out of demo projects.
- h4ch1 3y agoCompared 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.
- klysm 3y agoI really have a strong distaste for remix because of the way react-router was hijacked
- AprilArcus 3y agoHijacked? Can we not still use react-router in a standalone capacity as we have always done?
- lowboy 3y agoCan you expand on how it was hijacked?
- dcre 3y agoReact 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.
- WuxiFingerHold 3y agoI'd called it an innovative evolution by the creators of react-router.
- Jenk 3y agoI picked solidjs instead of Remix about a year ago. Would anyone familiar suggest I may have a better experience picking Remix next time?
- dimal 3y agoCan 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 3y agoMost 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 3y agoI 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 3y agoThis 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 3y agoJust 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.
- clivestaples 3y agoRemix 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.).
- CuriouslyC 3y agoMy 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 3y agoEveryone 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.
- kenn 3y agoExperienced 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 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
- 0xblinq 3y agoAt 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 3y agoI'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?
- dcre 3y agoSPA 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/ https://github.com/oxidecomputer/console/ Live demo here with in-browser MSW mock API: https://oxide-console-preview.vercel.app https://oxide-console-preview.vercel.app
- JoshGlazebrook 3y agoThis is what I'm referring to when I say BFF - https://remix.run/docs/en/main/guides/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.
- aswerty 3y agoI'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 :/
- jackbravo 3y agowhy do you want to bundle raw SQL files?
- aswerty 3y agoTo 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).
- 0xblinq 3y agoWhile I like and use Remix I do agree with your prediction about its future. Sadly.