workerd VS windmill

WorkerD isn't anywhere near a "cutdown version of Chromium," it is an incredible platform with years of engineering put into it, from some of the people behind very similar and successful products (GAE, Protocol Buffers, to name some).

WorkerD is open source: https://github.com/cloudflare/workerd

I personally am not a fan of Deno because of how it split the Node JS ecosystem, so that is not a benefit in my eyes. Of course, Workers can run Rust.

Nothing you said here necessitates an API difference.

You can't really run the Worker code without modifications somewhere else afaik (unless you're using something like Hono with an adapter). And for most use cases, you're not going to be using Workers without KV, DO, etc.

I've hit a bunch of issues and limitations with Wrangler over the years.

Eg:

https://github.com/cloudflare/workers-sdk/issues/2964

https://github.com/cloudflare/workerd/issues/1897

Workerd is a JavaScript & WebAssembly-based runtime that powers Cloudflare Workers and other related technologies. You can think of it like the Node.js runtime used to execute JavaScript files. Workerd has its differences from Node.js, however, you can self-host it on any machine.

Standards bodies only standardize things after they've been proven to work. You can't standardize a new idea before offering it to the market. It's hard enough to get just one vendor to experiment with an idea (it literally took me years to convince everyone inside Cloudflare that we should build Durable Objects). Getting N competing vendors to agree on it -- before anything has been proven in the market -- is simply not possible.

But the Durable Objects API is not complicated and there's nothing stopping competing platforms from building a compatible product if they want. Much of the implementation is open source, even. In fact, if you build an app on DO but decide you don't want to host it on Cloudflare, you can self-host it on workerd:

https://github.com/cloudflare/workerd

In any case, I welcome this initiative with my open hands and look forward all the cool apps that people will now build with this!

[1] https://pyodide.org/

[2] https://github.com/cloudflare/workerd/blob/main/docs/pyodide...

[3] https://github.com/cloudflare/workerd/pull/1875

For ref:

- https://blog.cloudflare.com/workerd-open-source-workers-runt...

- https://github.com/cloudflare/workerd

workerd

I think this is for people who want to run their own cloudflare workers (sort of) and since nobody wants to run full node for that, they want a small runtime that just executes js/wasm in an isolated way. But I wonder why they don't tell me how I can be sure that this is safe or how it's safe. Surely I can't just trust them and it explicitly mentions that it still has file IO so clearly there is still work I need to do customize the isolation further. But then they don't show any info on that core usecase. But then that's probably because they don't really want you to use this to run it on your own, they are selling you on running things on their edge platform called "Wasmer Edge". So that's probably why this is so light on information.. the motivation isn't to get you to use this yourself, just to use this their hosted edge platform. But then I wonder why I wouldn't just use https://github.com/cloudflare/workerd which is also open source. Surely that is fast enough? If not then it should show some benchmarks?

We use https://windmill.dev which is great for this!

Founder of https://windmill.dev here which share many similarities with Maestro.

> Maestro is a general-purpose, horizontally scalable workflow orchestrator designed to manage large-scale workflows such as data pipelines and machine learning model training pipelines. It oversees the entire lifecycle of a workflow, from start to finish, including retries, queuing, task distribution to compute engines, etc.. Users can package their business logic in various formats such as Docker images, notebooks, bash script, SQL, Python, and more. Unlike traditional workflow orchestrators that only support Directed Acyclic Graphs (DAGs), Maestro supports both acyclic and cyclic workflows and also includes multiple reusable patterns, including foreach loops, subworkflow, and conditional branch, etc.

You could replace Maestro with Windmill here and it would be precisely correct. Their rollup is what we call the openflow state.

Main differences I see

Data Handling: Utilizes Windmill for data pipelines, with a primary database powered by PostgreSQL. Auxiliary data storage is handled by MongoDB, with Redis for caching to optimize performance

Look very similar to the script builder portion of https://github.com/windmill-labs/windmill, but not open-source, not self-hostable, and without open-source integrations (https://hub.windmill.dev/)

disclaimer: I'm founder of ^

If you need a job queue on Postgres, https://windmill.dev provide an all-integrated developer platform with a Pg queue at its core that support jobs defined in python/typescript/sql

windmill.dev - Windmill is an open-source developer platform to quickly build production-grade multi-step automation and internal apps from minimal Python and Typescript scripts. As a free user, you can create and be a member of at most three non-premium workspaces.

For an alternative to airplane.dev, you can checkout Windmill.

https://github.com/windmill-labs/windmill

"Open-source developer infrastructure for internal tools (APIs, background jobs, workflows and UIs). Self-hostable alternative to Airplane, Pipedream, Superblocks and a simplified Temporal with autogenerated UIsm and custom UIs to trigger workflows and scripts as internal apps.

Scripts are turned into sharable UIs automatically, and can be composed together into flows or used into richer apps built with low-code. Supported script languages supported are: Python, TypeScript, Go, Bash, SQL, and GraphQL. "

If you search HN, you'll find the creator of Windmill comment on comparisons to airplane.dev:

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...