Hi! Thanks for asking -- the main difference is that devs build tools on Onu completely in backend code. Airplane requires some react code to build more robust frontends.

founder of windmill.dev here, a fully open-source alternative to airplane.dev

Congrats on the launch.

I am not sure that is accurate. Both airplane and windmill supports defining your task as plain backend code and deploying them from CI/CD using our respective CLIs. The react part that we both support is if you want to build more advanced views that goes past the need of a single form. One difference between airplane and windmill is that airplane require a yaml configuration to define the inputs while windmill automatically infer them from the main function signature. What mechanism do you use yourself?

Hi! Yes, thanks for the clarification! And by "robust frontends" I meant "advanced views," so you're totally right! The goal with Onu is for you to be able to build those advanced views completely in backend code instead of using React. We made this choice so that pure backend engineers wouldn't have to learn React to build internal tools. In fact, I didn't know any react while being an infra eng at lyft! We've heard this from a lot of other backend engineers as well -- they don't want to deal with react components.

To define inputs in Onu, devs use our SDK! This is actually what Airplane does as well (I think they deprecated their yaml config).

Agreed, backend engineers do not like writing frontend code. From there, for advanced views, I believe interval.com chose the route of having the frontend being defined in the task itself with an SDK (which I think is what you seem to hint towards?), and for windmill we have a drag-n-drop/retool-like UI builder if react is too much.

interval.com founder here, this is correct! Everything w/ us is defined in our SDK.

So instead of writing React code or using a drag-and-drop builder, you define everything ranging from simple forms to more complex views in Node.js or Python code using our SDK.