Don't try to be compatible with Cloudflare Workers

Deno Deploy claims to be compatible with other serverless platforms. Specifically, the homepage advertises "API compatible with Cloudflare Workers" and "No vendor lock-in".

This already isn't true since you can run TypeScript. Also the great idea to use Deno's native HTTP server API to allow to use Deno CLI locally [^denoapi] [^denoapi2] broke compatibility.

> just feels kinda weird if some of the goals are "no vendor lock in" and "API compatible with Cloudflare Workers" but to test locally you are locked into the Deno apis - [source](https://discord.com/channels/684898665143206084/826085979344470037/892164332010487808)

But more so, trying to be compatible isn't the right thing in the first place. By trying to be compatible, you're shooting yourself in the foot. By staying compatible you sign up to be a copy of the other platform. At best this cripples your platform and at worst makes it useless.

1. You can't provide distinguishing features that would make your platform valuable over others. You can't evolve and must stay a copy of other platforms in order to stay compatible. The only distinguishing feature can be price which is hard to compete.

2. Even if you do nothing you can break compatibility because other platforms can change themselves without asking you. You constantly need to change and copy them to stay compatible. For example, Cloudflare Workers is transitioning away from the Service Worker syntax [^swsyntax] towards using an exported class with a `fetch` method [^nodesm]. A polyfill [^polyfill] here isn't that simple anymore.

3. You require yourself to follow unfortunate decisions of others. This might not seem obvious right now since serverless is largely a single product (multi-instance public FaaS, "Worker") for which it just so happens that most platforms have used the same Service Worker syntax until now. But if you decide to offer more products in the future then staying compatible can become more painful, for example #88.

Compatibility comes from the desire to make it easy for people to come to Deno Deploy and copying existing code over is easy. But you don't need compatibility. You need conversion. For example, you can offer documentation how to convert code from other platforms to Deno Deploy, you can provide a script that people can run to do this automatically, or you can even integrate that script into your UI to allow people to directly create a new project from an existing one on another platform, e.g. "Create project from Cloudflare Worker". This is what so many other platforms do, e.g. Google Docs opening Microsoft Office files, Apples "Move to iOS" Android app, etc. It's all about conversion, not compatibility.

Note, all of this doesn't mean you have to deliberately design your platform to be incompatible. You just don't put in any effort to do the opposite.

[^swsyntax]: `addEventHandler("fetch", event => { ... })`
[^denoapi]: "We're in the process of phasing out `addEventListener("fetch", ...)` in favor of `Deno.listen() + Deno.serveHttp()`". Source: https://github.com/denoland/deploy_feedback/issues/71#issuecomment-889760772
[^denoapi2]: "no more fetch event listener". Source: https://discord.com/channels/684898665143206084/826085979344470037/892154021165563924
[^nodesm]: `export default { async fetch(request, env) { … } }` in a `.mjs` file. Source: https://blog.cloudflare.com/workers-javascript-modules/ and https://developers.cloudflare.com/workers/learning/using-durable-objects#instantiating-and-communicating-with-a-durable-object
[^polyfill]: "We will provide something you can import to polyfill fetch event locally". Source: https://discord.com/channels/684898665143206084/826085979344470037/892187811673948211

No implementation files, tests, or entry point are identified. First review the compatibility claims and the referenced discussions in issues #88 and #71, then clarify whether the intended outcome is a documentation change, a conversion tool, or a change to the platform strategy before defining what done means.

Written by the indexing model from the issue text.