[jFriedensreich]

Cloudflare is not a CDN anymore but the workers edge platform, if you can move to bunny.net, you were not really using cloudflare. I don't understand how none of the alternatives really embrace WinterTC

If i see something horrific like:

import * as BunnySDK from "@bunny.net/edgescript-sdk" BunnySDK.net.http.serve(async (request: Request) =>

Thats a proprietary lock-in worse than what it tries to replace!

[whh]

FWIW, Cloudflare's edge platform is pretty proprietary too.

[jFriedensreich]

The platform yes, but the runtime and the APIs are apache 2.0 licensed and uses web standards wherever possible. Thats way more open than most alternatives i am aware of.

[mark_and_sweep]

Their fetch handler [1] is not a web standard.

[1] https://developers.cloudflare.com/workers/runtime-apis/handl...

[jFriedensreich]

but not to lock people in but to avoid the context overhead of service worker api, which they tried first and which still works btw.

[mark_and_sweep]

Sorry, what? I never mentioned lock-in.

I assume by Service Worker API, you mean FetchEvent? [1] As in:

self.addEventListener("fetch", (event) => {});

That is a web standard indeed, but not one that was designed for use as a general-purpose HTTP handler, but rather for use in a Service Worker proxy.

[1] https://developer.mozilla.org/en-US/docs/Web/API/FetchEvent

[jFriedensreich]

Maybe i misunderstood what you were going for. Just saying: Yes, their web fetch handler is not a web standard but the only standard there is to accomplish something like that had a few issues and they picked something that looks as generic as possible. vs import {pretendToStartServer} from ('our:global-injected-pseudo-sdk')

I really loved the idea of using service worker sdk and having something that works in browsers too so the conceptual model of edge functions are spanning backends, edge POPs and browser runtimes.

[shimman]

Unless the project is controlled by democratic committee where cloudflare doesn't have a majority of seats it's not open source in any meaningful sense of the word, maybe we should stop acting like corporate sourced software is anything but an attempt to get free labor from the commons.

[kentonv]

I can assure you that nobody at Cloudflare ever thought that open sourcing workerd would be a way to get "free labor from the commons". On the contrary, we are wary of external contributions. The Workers Runtime is a complicated codebase, and we invest a lot of time into getting new team members up to speed on how to write code correctly. We cannot make such an investment in external contributors who are only there to land one PR. Usually, a one-time contributor trying to do something complicated will waste more of the team's time than they save.

But in practice, we almost never receive major contributions from outside the team. Which is fine. We're happy just to have our team working in the open.

The reasons we open sourced it are:

1. Support a realistic local dev environment (without binary blobs).

2. Provide an off-ramp for customers concerned about lock-in. Yes, really. We have big customers that demand this, and we have had big customers that actually did move off Cloudflare by switching to workerd on their own servers. It makes business sense for us to support this because otherwise we couldn't win those big customers in the first place.

[jFriedensreich]

Have you seen the codebase? Please don’t blanket reply like that just because it is a corp. Workerd is one of my favorite piece of engineering and its not comparable at all to openwashing projects that have extreme internal garbage not possible to free from the companies infrastructure. Kenton and others fought hard to make the abstractions among the cleanest and well designed in the industry and while it is not a multi contributor apache foundation style project it is a codebase that you could hard fork if cf decided to close it or go a direction you cannot accept.

[Dylan16807]

> maybe we should stop acting like corporate sourced software is anything but an attempt to get free labor from the commons

The point of this discussion is that you can self-host, and you have a good chance of migrating the code away entirely. That's a big benefit that isn't "an attempt to get free labor". For that use, not only does it not matter if it's meaningfully open source, it doesn't matter if it's open source at all.

[mark_and_sweep]

AFAIC, WinterTC doesn't specify how to start an HTTP server. Their minimum common API requires, among other things, that the Request and Response interfaces from the fetch specification are present. Unfortunately, it does not specify any sort of serve function.

[jFriedensreich]

Because an edge runtime should not directly start servers in the first place. You provide handlers that fulfil requests from the system. Edge runtimes that pretend to start the servers in the edge worker context are flawed and ugly from the very start. APIs like that leak implementation details and increase vendor lock-in for no added benefit.

[mark_and_sweep]

> > I don't understand how none of the alternatives really embrace WinterTC

> You provide handlers that fulfil requests from the system.

As I said previously, though I wish they were, such handlers are not part of WinterTC.

And then again, how those handlers are registered is also not part of WinterTC, which I also wish it were.

> APIs like that leak implementation details

How?

Almost all runtimes, like Bunny Edge Scripting, Cloudflare Workers, Deno, Bun, etc. use the same basic signature for the handler:

(request: Request) => Promise<Response>

Only how you register said handler is, unfortunately, different for each runtime.