gabigrin

It's far from ideal when it comes to integrating with existing codebases and building backend features.

We're not competing with it directly, as we're aiming to be integrated into applicative production workflows.

Error handling is a first-class citizen in Flyde, the visual programming language powering Flowcode. Any node has an "output pin" called "error" that will emit data if something goes wrong.

You can test this real quick in the playground - throw in a JS expression and write some gibberish and test your flow. Alternatively, use the HTTP node with a non-existent URL

I'm obviously as biased as one can get here, and have a general sense of agreement with your sentiment, but I think it boils down to 2 aspects: 1. The nature of your code. For a linear, synchronous algorithm, no doubt text is the way to go. For async, concurrency-heavy workflows, debugging it in a linear fashion becomes a nightmare. Take an LLM-heavy backend workflow for example, with calls chained and running in parallel. Horrible to debug using textual code.

2. The experience and features set of the editor itself. Making it reactive and not imperative was exactly our goal. Flyde, the visual-programming language powering Flowcode is a functional-reactive visual-programming language. Control-flow is determined by data, unlike existing tools in that space where arrows represent control-flow and all of the dynamic variables are hidden inside implicit "${{node1.input2}}", making it as far from Unix philosophy as it gets.

Also, Flowcode supports custom code in 3 ways: inline code expressions, custom code nodes (you can even fork any of the "stock" nodes with complete access to the underlying API), and codebase SDK integration, so you could supply it with inputs from your code in a typed way.