Cloudflare Workers isn't a drop-in serverless platform (yet?)

I would love to use Cloudflare Workers for hosting all of my work - from static sites to highly dynamic SvelteKit applications. They have the best performance of any serverless platform with 0ms cold starts (with improvements coming often!), are affordable & powerful, and, most importantly, are aware of their responsibility with the planet and actively work on improving the sustainability of their products.

They allow you to set your worker to only run in servers powered by renewables, are certified by the The Green Web Foundation and even provide carbon emission reports to educate clients on the impact of their web properties. You can say I'm a fan.

BUT, given the architecture of their platform, adopting Workers isn't as straightforward as I'd love it to be. The Javascript code you ship to it runs on the V8 engine, similar to Node & Chromium browsers, but it doesn't expose many of the APIs these two have. This makes it so you can't use many packages common in modern JAMstack development:

• dotenv breaks it as it requires fs, a Node API
  • 💡 You can get around this with dotenv-cli, though
• Popular database adapters, such as @supabase/supabase-js, use XMLRequest (not supported in Workers) to handle fetch requests in older browsers
  • For Supabase specifically, the official example for integrating with Workers relies on using patch-package in a postinstall script to modify cross-fetch, one of its dependencies. If you update your packages, you have to do it all over again - not the best experience!
  • I've experimented with the process above inside a slightly complex SvelteKit handler in this repository, and it almost worked! My future self will probably come back to try to fix the last bits.
• Many libraries reference window, a browser-only object

In short, you'll have to be extra careful about your usage of npm packages, and publishing any non-trivial project that will certainly face dependency issues.

There's also the clunky deployment process - I'd need to set-up a GH action to do deployments or do it manually from my machine, both which involve extra work when compared to Vercel, Netlify or Workers' cousin, Cloudflare Pages.

Cloudflare Pages is actually a big step up for them, and will soon power this very blog. However, it's suitable solely for purely static sites, such as those powered by Astro or ElderJS, as it doesn't (yet?) integrate seamlessly with Workers. You need to have two separate processes for deploying the front-end and the dynamic API, which removes the possibility of deploying a NextJS or SvelteKit app using a mix of static and server-rendered routes.

I imagine they're working on solving these issues as I write this, and I trust they'll come around with better solutions for these problems. In my experience, their products and communication are usually very confusing and the UX isn't the best, but the fact that Cloudflare Pages offers a really smooth flow is a sign they're about to change that. They're probably seeing Vercel's success with all of the focus on Developer Experience (DX) & productivity, and are now trying to follow.

If you represent Cloudflare and think I made an unjust statement here, do reach out (meet@hdoro.dev or hdorodev)! I'd love to rectify and learn better 😊