Consider using Vite

[pacexy]

Remix is great but features about DX is missing (e.g. HMR) or not good enough. While Vite is a new build tool, it has a rich ecosystem now and can be leveraged by Remix.
Related: #2384

[sergiodxa]

Remix uses esbuild which is what Vite also uses internally.

The lack of HMR is intentional, because of the SSR nature of Remix it cause inconsistency errors, I have personally saw those errors on Next.js applications using HMR and SSR.

[agcty]

I don't agree with this take. I've worked on very large next.js applications and HMR is an absolutely crucial feature, especially when you use something like react-three-fiber and have lots of 3d models being loaded.

[bernhardw]

I also think HMR (and Fast Refresh) massively improves the developer experience. I've worked on several React websites and applications and never experienced any problems. However it may not be so easy to implement in Remix, see: #2384

[designbyadrian]

I thought Vite uses Rollup internally?

[sergiodxa]

Vite uses esbuild

[redbar0n]

Both are right:

Vite pre-bundles dependencies with esbuild but currently uses Rollup to build for production.

https://vitejs.dev/guide/why.html#why-not-bundle-with-esbuild

[ztcollazo]

I would support this feature also; I've used Vite and HMR in general with a few full-stack applications. I recently rewrote my portfolio in Astro (possibly a major Remix competitor, now that it supports SSR), which uses Vite under the hood. Before that, I used Next.js with HMR with no problems. Even before that, I used it with Ruby on Rails, and it was amazing. This would also bring about several other features that I feel are helpful to a good developer experience, such as a plugin system and module aliasing. It would also provide easier styling integration with things like windicss/tailwind or even just Sass.

I understand the concern with HMR causing you not to notice when stuff breaks as it changes, but you could use something like vite-plugin-full-reload for when certain files change. I believe that many opportunities are open when the build system is accessible (and I say that in general; see this comment).

[tiagoad]

I believe this would bring DX improvements that I miss a lot working on a reasonably large remix project.

[fezproof]

With Vite 3 out now, this would be a great chance to use it. It has much more stable SSR support, and the remix codebase could be simplified a lot by taking advantage of things like Import globs for the routes folder. It would also give things like easy Vitest integration, HMR, worker support, wasm support, etc...

Also with the constant HMR disagreement takes with consumers and the dev team for Remix, why not use an opt in toggle in the Remix config? Let devs know the risk in the docs and let them decide if the risk is worth it.

[kiliman]

I'm sure the Remix team might consider Vite if somebody took the initiative to work on an implementation. From the comments here, it sounds like such an easy task to add HMR, etc. Any volunteers?

[ztcollazo]

I'm not sure just how easy it would be. I may be able to try rewriting the framework as a Vite plugin, but it might take some time. Especially the server adaptors. That's one thing that makes Remix special, so trying to replicate that in Vite would be hard. I could also take a look at the Astro codebase to see how they programmatically implement Vite so that I wouldn't have to rewrite the entire codebase. I can try, but don't expect me to succeed (at least for a bit).

[agcty]

I don't think it's going to be a cakewalk, Remix has some very fine-grained compiler specifics. However, Vite 3 seems like it could potentially be used with Remix. Especially the HMR part could be a lot easier to implement, see: vitejs/vite#7309. Vite 3 now supports partial HMR which could alleviate a lot of HMR issues the Remix team has pointed out. There are a lot of other things to consider though and I'm sure that if Vite was or becomes the best solution to build Remix with, the Remix team would go that route.

[ztcollazo]

I'm not saying that I'll be completely redoing it; I'll probably just end up building a POC. If others like the strategy (whatever that ends up as), then they can help develop it more. I'll post any updates here.

[ceopaludetto]

Solid Start which uses vite, has a similar API to Remix. The codebase can be considered for research too.

[bramvanneerven]

Vite is 'on the radar': https://twitter.com/pcattori/status/1552697763342815237?t=WWnMf2ooSL8v98DL-H3PsQ&s=19.

The meaning of that remains to be seen, but it seems the Remix team is considering it.

[redbar0n]

an alternative is using Vite + vite-plugin-ssr + React Router now that React Router in v6.4 got upgraded with a lot of the Remix goodies since it’s made by the same team.

[dn-l]

In the meantime ... https://twitter.com/jarredsumner/status/1574030332843552769

[sudomf]

Hey all. I just started sudomf/remix-vite. It's in the very beginning. But I think I'll be able to support most of remix apps asap.

Give it a try by running.

npx remix-vite

[mjackson]

We’ve definitely considered using Vite, and I think it’s a great project with a great ecosystem. My main concern with it is that Vite may not support everything we’d like to eventually support.

Vite is basically a better webpack. Which is fine if you like webpack. But that implies an entire paradigm. We all know what that paradigm looks like. You build before you deploy, extend with plugins, etc. We also know the limitations of this paradigm and it’s pitfalls. HMR “works” for most things, but has bugs in the corner cases. Build before you deploy can be cumbersome. Also, most bundlers are node-only, which means you can’t run them in environments like CF workers.

What we are more interested in is what an alternative could look like. What if your bundler could run in any arbitrary JS environment? What if you ran pieces of it at runtime instead of building everything ahead of time? Can we develop something better than current HMR?

There has been a ton of interest in using Vite, and I fully expect a community maintained version of a Vite compiler for Remix to exist and be quite popular. But I’m personally more interested in exploring alternatives.

[ceopaludetto]

For me the main reason to use Vite is extensibility, if Remix can offer a plugin system with or without Vite I would like it. People who want to try Remix are annoyed because when they need to use tailwind or svgr they need to take a second step, usually a concurrent build. Vite is the failsafe option because it already has plugins and solutions for these tools. For me if we allow people to use esbuild plugins, dx will be much better and most of the lack of tools will be avoided.

[shaunnbarron]

My main concern with it is that Vite may not support everything we’d like to eventually support.

Have you tried just having a chat with the Vite team? Given their pedigree, it's highly likely that they'd be interested in collaborating. After all, they've collaborated with nearly every modern framework:

• SvelteKit
• Astro
• Solid Start
• Nuxt
• Qwik City

It even runs on Deno now...

This has become the single biggest downer for me about this framework. Issues like hmr, css modues, the bizarre tailwind setup, etc all get solved with Vite adoption.

[fezproof]

@mjackson with the release of Vite Node could this be more enticing now? Having really strong SSR and Client side DX could really push Remix to the next level.

[CanRau]

Adding to @fezproof as I just saw this yesterday that vite is working on (exactly) this
https://youtu.be/qXZzXvyqPpc

[ScottAwesome]

full stop my only blocker for my team adopting Remix over Next.js was the lack of modern developer experience features, by far. Building on top of Vite would be the tipping scale for the this.

[jrestall]

I've created a Vite based development server and alternative compiler for Remix called RemixKit. It's an early release so please test it out, raise bugs and/or contribute.

It has a lot of functionality that's been mentioned in this thread:

• Vite 4 / Vite Node
• HMR for both client and server code.
• Extensible compiler with plugin support and hooks.
• Separate development server.
• TailwindCSS / PostCSS and other Vite functionality built-in (no separate CLI's).

I'm most proud of the on-demand tree shaking of each route module in < 10ms in the dev-route-loader.

It's only NodeJS at this stage and an alpha release, so use it for development and test the production bundling. The dev server's architecture is client/server so support for Cloudflare workers could be feasible in the future with a rewrite of the small client.

I'm sure the Remix team will create a DX that beats Vite in the medium to long-term and they should be focussed on that, but this I believe provides the best possible DX until then.

https://github.com/jrestall/remix-kit

[cliffordfajardo]

Also remix-kit makes it so that you don't need purgeRequireCache meaning you won't need to attach things to the global scope and have lots of places in your code where you're doing this:
https://gist.github.com/cliffordfajardo/ba23bf8f42c664466742fc43cd46f775

No purgeRequireCache needed, keep objects in-memory between requests to match production behavior. - RemixKit README

Also has these nice URL's after your dev server starts, that you could visit from any device on your wifi network, so view your code on you phone/ipad etc and see updates in real time. vite, create-react-app and similar tools have this, I'd forgotten how awesome that feature was

remix-kit-hmr--reloads-across-devices.mp4

[aniravi24]

My thoughts are a bit different to many in this discussion so I thought it's worth commenting - I'm specifically moving to Remix because it doesn't use Vite. I love Vite's ecosystem, but using it on a decent sized React SPA has been a rough experience. It uses a ton of memory to build our projects, often requiring us to max out memory in CI or get bigger machines. Refreshing the page causes vite to dynamically load a ton of modules onto the page, which is really slow in our project and makes it so developers on Linux can't even use the Chrome browser with the dev server without making sysctl modifications. On top of that, HMR doesn't work correctly causing the page to render twice on the screen and also takes several seconds to load so we usually refresh instead (an issue likely specific to our strange codebase, but true nonetheless). I wish HMR did work though because it's amazing when it does.

Some of these are well documented issues in Vite, brought up at least once in their roadmap GitHub discussions with the community. For example, see here

In contrast, moving to Remix keeps our dev and CI machines alive, and even though it can take 2-5+ seconds to compile, it's still way faster than vite at the moment (albeit with less support for DX/bundler tooling than Vite).

Maybe using Vite with Remix would provide a better experience, and I may have just been unlucky with inheriting a React codebase I moved to Vite, but something to consider!

[cliffordfajardo]

@sudomf - is this something you've experience with remix-vite or does remix-vite use esbuild like remix during local development as well?

[sudomf]

@sudomf - is this something you've experience with remix-vite or does remix-vite use esbuild like remix during local development as well?

remix-vite uses Vite plus some custom plugins to support remix. But Vite itself uses esbuild under the hood.

[ScottAwesome]

Now that Remix is now with Shopify, is there any way to leverage their excellent toolchain they built out with Hydrogen?

[yracnet]

I build a plugin in https://github.com/yracnet/vite-plugin-remix but it is only for development mode

[rolanday]

+1 for Vite in place of bespoke build system. Based on thread so far, it appears unlikely to happen anytime soon (if ever) but using Vite would attract a lot more developers to Remix IMO -- esp. once Nextjs Turbopack finishes baking. I use Remix in spite of its build system because HMR feels painful slow after working in a Vite project and doesn't benefit from Vite plug-ins. Also, the current solution provides Remix with no differentiated value from my perspective, except for the recently added fast (stateful) refresh -- a fantastic addition that I'd trade for Vite w/o so much as a second thought, if asked.

[birkskyum]

• feat: add unstable Vite support #7590