rubenfiszel

(Windmill Founder here)

Windmill allows you to write code in any places but we have a hub augmented every day with pre-made integrations so that you do not have to: https://hub.windmill.dev. We also have native support for BigQuery, Snorflake, Mysql, GraphQL, with dedicated editors.

Hence, I fail to see how it would be any faster to build workflows in tooljet than in windmill. I do not have a business license of tooljet so I have not been able to do the comparison. Interested to hear feedbacks on that.

Our workflow engine and UX seems to be a lot more advanced from what I can see because we have been iterating on it for longer. Congrats on the launch though and may the best open-source alternative to Retool win.

> Self-hosted Business & Enterprise plans only

(Windmill Founder here) Our workflow part is open-source so it's not 1:1 comparison

Yes since typescript is a superset of javascript and our runtimes support it (you can run javascript with bun)

You can pretty much use tsserver with bun-types and get most if not all the features you get from deno-lsp. I know because we provide both deno-lsp and tsserver for windmill.dev to provide intellisense over websocket/jsonrpc for our monaco webide at windmill.dev and it works great :)

We provide both bun and deno as typescript runtimes for windmill.dev (oss retool alternative) and we get overwhelming feedback that people are confused by the little changes required to adapt to deno and would rather just stick to the node.js mode aka bun. Now that bun is getting close to 1:1 node.js support, I predict we will see a lot more bun everywhere.

@Jarred was super responsive to help me adapt bun to our distributed cache storage, so all props to him.

I see windmill mentioned a few times (founder here). I think we are both anchoring our tools around "Retool for enterprise" because Retool is known and it give a quick overview of the domain we are in: Internal tools, but the audience and pain solved by refine and windmill are likely to be quite different. Windmill caters towards software engineers that want to write powerful backend logic in typescript/python/bash/go, long running jobs and complex workflows for internal use (we compete there with temporal, airflow, airplane), and share them with the rest of their orgs with all permissions handled for them, ability to scale on large clusters, and observability baked in (full history of all executions, including args, logs, and result) AND in addition have a low-code dashboard builder similar to retool because webhooks, schedules and automatically generated UI from scripts are not always sufficient.

Refine looks more like a headless retool for software engineers that are comfortable with frontend frameworks but want an opinionated stack that is tailored toward internal uses and do not want to deal with the rest of the boilerplate, user management, and connection/management of databases etc. I could see myself preferring refine for some use-cases and would probably recommend it if you are comfortable with writing frontend and the logic is limited to CRUD. So I wish them good luck and I am happy to see such diversity in the open-source space!

No need to fine-tune since windmill uses normal code without custom syntax so gpt4 corpus works very well. That's one of the benefit of not using DSL, most tooling work well out-of-the-box including vscode copilot if you were to use windmill using the GitHub/vscode integration.

Currently the context is limited to your database schemas, your resources, and the current script code. But we will soon augment it the rest of your code. The techniques applied here would remain relevant but you would need to find the most relevant context of your codebase first since you can't (or shouldn't) cram all the codebase in your prompt.

Yes, we will do this next and address this in the post. We wanted to validate the approach first using the best model available but using another model is just one endpoint change away in the codebase https://github.com/windmill-labs/windmill/blob/8d550a7ea5708...

As an open-source project ourselves, it is pretty obvious next step!

> The Tiptap AI integration beta is a service where you connect your OpenAI API key to our backend and install the Tiptap editor AI extension to get AI writing experience in your editor. Here’s a demo: https://ai-demo.tiptap.dev/

Congrats, any plan on supporting code/monaco and autocompletion? We had to rebuild it ourselves on top of yjs and gpt4 for windmill.dev and would have happily built it on a service if it existed.

and https://windmill.dev

Windmill is written in Rust so cannot use the javascript serverless driver. I love sqlx and sqlx would not be easy to replace so short of making it an extension for sqlx, the only route is to make believe the sqlx connection pool that it's talking to a pg server, when it's actually just talking to the local proxy.

If we were using javascript/typescript, then yes we would probably just be able to use that library.

> (2) find/write a similar WebSocket proxy, but in reverse — i.e. one that listens out for TCP/socket connections and tunnels them over WebSockets — to run next to the agents.

It's that part that I would love to see. My assumption is that this proxy next to my agents would need to speak pg protocol and then transcribe it to wss. If there is a simpler way, let me know :)

What I would absolutely love is to have a proxy server that would act as postgres, and use this new driver to connect to a remote postgres. This would avoid us having to rewrite our remote agents (which require a postgres connection to the main Database) to use an http api. Instead, we could just keep them as it is, using rust's sqlx queries, point them to the local proxy. Essentially pgBouncer but through http.

Postgres <> Neon HTTP Proxy <---HTTP---> Local Fake Postgres Server <--unix socket--> Agents

We need it for the open-source project windmill.dev and we will build this if no one else does it.

One could build that SaaS on top of windmill :)

We are starting a series cheekily called "Replace a SaaS" with this one as the first one.

There is a trade-off between build and buy and we aim to reduce the chiasm so you don't end up with a billion generic SaaS subscriptions and with a bit of code build truly tailored solutions.

We do and if you do not want to bother self-hosting, our free-tier is sufficient for around 200 answers (1000 executions): https://www.windmill.dev/pricing

That's super cool and this looks more like a POC than a product for now, but if this were to take off, it would complement really well what we do in our own OSS project windmill.dev [1] where users can deploy scripts in typescript/python/go/bash and more complex flows composed out of those same scripts, get a webhook and a UI to trigger them. Users currently have to either set a schedule to regularly poll or setup a webhook on the event source. This would be a consolidated way for them to have all their event sources in the same place.

[1]: https://github.com/windmill-labs/windmill

This is cool, but otherwise you can just use windmill as an open-source internal app builder and use Github Copilot in vscode to get the best AI assistant out there: https://www.windmill.dev/docs/cli_local_dev/vscode-extension

Founder of windmill.dev here, airplane is not backed by YC but the founder is an alumni.

Aside from the obvious open-source aspect, here is one notable difference. We explicitly do not provide an integrated DB but offer simply a K/V store api, and recommend to use some dedicated services for persistence storage like supabase/neon.tech/aurora/s3: https://docs.windmill.dev/docs/core_concepts/persistent_stor.... We do not believe we can build both the fastest workflow engine at scale and the best DB so we leave the last bit to others.

From what I can see, the assumption of the userbase look a bit difference. Although we have a hub (hub.windmill.dev) where users can share premade actions, we focus on script/code in typescript/python/go/bash as the unit for workflows. From there, we focus on building workflows with most of the same primitive as temporal (suspend/resume also called reactivity, error handlers, retry, etc, and some others like caching of step results) and running arbitrary code on your own infra and being able to use your full nodes without overhead. The code for the steps can also be developed locally and deployed from your github repo.

Last we have a retool-like + react app capability which seems to be out-of-scope. So to summarize, although you can use windmill to do backend prototyping or as your product backend given that we generate per script/workflow webhooks, we focus on workflows with code and internal tools with enterprise scale requirements such as complex permission per-user/groups.

Missing windmill.dev :)

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.

airplane.dev itself is not YC backed, but one of the founder is a YC alumni

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?

Ola from windmill.dev which has some overlap but is focused on enterprise and self-hosted infra.

We have exactly the same issues for the cloud and ended up securing everything through nsjail and the deno run sandboxing. I admire that you're willing to allow unauthentified users to run computations. Do you guys have timeout ? How do you ensure resource isolation? We use kubernetes for resource isolation, and we use both timeouts and quotas where each second a background process will kill the job if the user/job is over it. Let me know if you guys are up to chat at some point and congrats on the very nice UX.

For deno to grow, it needs to be used in production systems. Deno seems to be betting most of it business in serverless/edge deployment (deno deploy, supabase functions, netlify functions). We also support it for self-hosted infra/internal tools production use-case at windmill.dev. The #1 feedback that we get is that people are frustrated that they have this one script or library they cannot use and that otherwise work with node. Deno is a marvelous piece of engineering that require a team of very qualified engineers, those need to get paid, so some tradeoffs need to be made.

Hey Max (and jack), I'm actually curious on your feedback of using temporal for this use-case. I'm building an alternative to temporal (and a low-code builder to run arbitrary code on top) at windmill.dev and keen to learn on your experience. I will send you a DM.

x1 carbon with an m1 cpu, I wouldn't care how much it would cost.

Windmill.dev fills this niche (it's AGPLv3, not MIT) and you can use it at scale for production use-case even on the open-source version.

- The queue is in postgres or redis.

- We scale to 0

- We have helm charts for k8s: https://github.com/windmill-labs/windmill-helm-charts

- We support cron and error handlers for cron as functions and we generate a webhook for each functions

- We support local dev and sync from github or deploy directly from our webide

- deployment of a function takes less than 1s

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

Happy customer here too at windmill.dev :)

I guess you could have a script keep a long lived ssh deamon and do this

You could also use the inline script endpoints to ask the worker to execute bash commands directly. But this probably does not compare well to rundeck. If you had time, I'd be very interested to chat and understand what is the optimal experience you'd be looking for: ruben@windmill.dev

Do not worry about us, we are profitable, I have a majority stake, and our investors trust :)