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 5 hours ago | parent | next [-]

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

▲

jFriedensreich 5 hours ago | parent [-]

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 3 hours ago | parent | next [-]

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

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

▲

shimman 4 hours ago | parent | prev [-]

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 3 hours ago \| parent \| next [-]
		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.
	▲	Dylan16807 3 hours ago \| parent \| prev [-]
		> 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 5 hours ago | parent | prev [-]

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 5 hours ago | parent [-]

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 3 hours ago \| parent [-]
		> > 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.