This blog post is a long one – and where I share our startup’s experience of trying out both Remix and Next.js as technologies to serve hundreds of thousands of developers interactive coding courses through codedamn (the website you’re reading this on).

Note: This article is one man’s PoV and might hurt feelings if you blindly like a platform or a technology. Do not read if you have blind favorites. Appreciate any feedback.

It was around the last week of April this year when I decided we should try out Remix for a few internal websites we have. Why? Because of extreme hype on Twitter, and how Remix fights with Next.js – the strongest in the market right now.

At codedamn, we love Vercel (except for their pricing) and Next.js. Then why did we decide to try Remix? Simply because:

We were not on Vercel at the moment (because of pricing issues – high bandwidth cost. C’mon Vercel, who charges $55/100GB today? Not even AWS does that)
We wanted to try a new technology that could SSR on the edge and potentially unlock us out of Vercel’s vendor lockin.

Next.js is powerful (only when on Vercel)

Next.js middleware, SSG caching, insanely fast build times, preview links, etc. are not Next.js features. These are platform features too. And there is no better platform than Vercel for using them.

This means, that if you deploy Next.js on your own, chances are you’ll end up compromising on at least 1-2 mentioned things. I love Vercel as a company – they have the perfect strategy.

But as a startup, I hate their pricing model where they only have $20 tier or $XXXXX yearly enterprise tier. (Can we have a nice $300-$400 startup tier too that grows sanely with the usage?)

Anyway, let’s come back to Remix. Remix is software. That’s it. As a company, they do not bring their own official platform which is fine because Cloudflare Pages promises first-class support for Remix.

Honestly speaking, cloudflare was the only reason I considered Remix. Cloudflare is an extremely solid PaaS platform with ridiculously low-priced products and a collection of very high quality of products (only when they work).

Remix deployed on Cloudflare – doing SSR on the edge using workers with 0ms cold boot time and serving users fresh content every single time seemed like the perfect way to build a site. Until it didn’t. Let’s get into why Remix in fact is a worse choice for pretty much any large-scale website.

Remix wants you to SSR – everything

The things that sound very nice as a marketing gimmick are actually not very practical. When migrating our app to Remix, the first thing we saw was that Remix pretty much wants you to render all of your data and everything on server which is great.

However, there are certain pages that are best served static. For us, it was our landing page, it was all of our blog posts, it was our marketing pages, it was our course landing pages, it was pretty much everything except a bunch of pages – like dashboard, settings, course item pages (customized to users), etc.

Now you could say – why not generate these pages and use Cache-Control headers to cache “using the platform”? Because you should not Cache-Control personalized pages for obvious reasons.

At codedamn, we display your user avatar and personalized navigation links in the header section. This means that if we want to SSR it, we cannot SSG it (or in Remix’s terms – cache it on CDN using the platform). Either we have to always SSR pages, or we have to keep the header blank, perform API requests on the frontend, and then we can probably cache the pages on CDN.

If you go with the first option – you are doing a huge mistake. For example, we use a less powered WordPress backend to host our CMS for blog editing, and we render everything statically in Next.js on run-time. Once generated, the pages are never revalidated until the content changes (thanks to the new revalidation API).

However, with Remix, we pretty much would have to render the whole page again, and again, on every single visit. Why? Because we also have to SSR the header data (remember that we’re considering the first choice right now – to always do SSR). This is bad, because your low-powered wordpress instance is now going to go down due to huge traffic, and you lose the benefits of Vercel where if SSG fails to revalidate, it keeps on serving the last good page. Remix @ Cloudflare Edge would just transparently DDoS your low-powered backend thanks to SSR.

If you’re thinking of going with the second approach, then it is obviously not a great choice for us because it is too much effort for us to migrate Next.js to Remix only to have the same behavior as Next.js – but even worse in performance (in our tests, Vercel pretty much has the best CDN in the town, therefore, shortest TTFB)

Next.js on the other hand offers the ability to selectively render pages on the server. Now when deployed on Vercel, it wouldn’t be as great as Cloudflare Pages because Vercel doesn’t do rendering on edge (yet), but still – could get the job done for most users.

Cloudflare is just – broken –

This has strictly been our experience for the past month, but Cloudflare Pages is broken for deploying Remix. Any worker that receives multiple requests quickly crashes – leading to your whole app crashing down.

We pretty much spent about a week migrating everything from Next.js to Remix – and then deploying to Cloudflare, then even switching on Remix build for production – only to realize that Cloudflare Pages workers break brilliantly on production for multiple users.

We had to immediately roll back to the Next.js build to save the day. I’m not sure when Cloudflare Pages would fix this, but here is a reproduction of what I’m saying:

The crash you see in the above video “Worker threw an exception” is not from the code layer. The code is rock solid (and in fact very simple – with just one HTTP request that too in try-catch in the loader function). Cloudflare Pages is unusable for production Remix as of June 2022.

No other platform makes sense

Except for Cloudflare, no platform makes sense as no other platform is the true edge. Coming from Next.js which is deployed on edge even on AWS through Cloudfront, we wanted to have better performance for end users, not worse.

Also, because our architecture for the frontend and backend is decoupled, we did not necessarily want a fully blown Node.js backend rendering Remix. Even if a platform like Cloudflare workers could work with Remix (workers, limited memory, and run-time) we would have been happy. But there is no player in town except for Cloudflare right now (even Vercel doesn’t SSR on edge). AWS Lambda@edge of course comes with a huge setup curve.

We tried fly.io as well, but our experience was horrible with autoscaling and soft/hard TCP limit connections. In our initial load testing, fly.io failed to upscale properly, failed our E2E tests, and it was a pile of a hot mess. It might be because we didn’t properly understand what was happening with fly.io, but it just didn’t click us as a platform to serve our frontend (our backend is deployed on AWS lambda inside VPC)

Remix has horrible DX

Sorry, but I’ll say it. I really do not get how people appreciate Remix on Twitter. Get yourself a MacBook Air/Pro M1, and create fresh Cloudflare pages + remix project (starter template). Try editing multiple files simultaneously and start saving little changes. You’ve reached hell:

The compilation times that start from 60-70ms on esbuild quickly jump to 15-16 seconds.
In those 15-16 seconds, everything would go down – literally. Your development IDE, your patience to work with Remix, your desire to live. Then everything would come back to life – only for you to see that Remix hasn’t reflected the changes yet in the browser.
So you try to look under the hood and for some reason, it is still refreshing the page, then you close the tab, kill the process, restart the process, open the tab again, and wait for 4 more seconds for everything to appear.
There is no hot reloading, live reloading is extremely slow even on the best laptops (tried with M1 MacBook Air with Cloudflare Pages template), and you’ll spend more time restarting your process than working on code.

There’s already an (unanswered) open issue by me on this: https://github.com/remix-run/remix/issues/3123

Remix works on experimental technology

Esbuild is great – fast bundlers are the future. But it really is the future. It is in future. Remix doesn’t allow patching esbuild config out of the box, which is a nightmare in itself – coming from Next.js with a fully custom webpack config.

If that wasn’t enough, Remix pretty much cannot support a few packages as of now (when using Cloudflare Pages, in this instance) – https://github.com/remix-run/remix/issues/3120 because of some polyfill issue from Esbuild’s side.

Conclusion

Remix might be a great technology in the future. It might be great for users and it might use “the platform” a lot. But I’d take shipping 10kb of extra JS and keep my sanity as a developer and keep our deployments fast, robust and predictable every day of the week over half-broken DX and flaky production environments. As of now, we are talking with the Vercel sales team, and we’re back on Next.js – doubling down on SSG/ISR and on-demand revalidation + bringing in dynamic data from APIs even faster – as we have been doing for a long time.