Working on a 1.0.0 launch for Flyde - https://flyde.dev/, an open-source visual programming language. It works great for embedding visual AI flows for backend logic. Integrates with TypeScript code, runs on VSCode & Node.js (via a runtime library, in-repo, no containers needed)
Would love to chat with people looking to combine n8n-ish capabilities in their code!
OP here.
At least a dozen times :) He was the inspiration of starting to work on https://github.com/flydelabs/flyde, the visual-programming language powering Flowcode.
Nope - we're both visual nodes-and-wires based tools, but they create a visual representation of your codebase/architecture, while we allow you to create the applicative logic visually.
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
Thanks for trying Flowcode! sorry it didn't work for you.
The AI should have explained that local scripting isn't supported by Flowcode. Our copilot is under active development and has a lot of room for improvement.
Flowcode is built for cloud-based use cases - you can think of it as a "visual serverless" platform
Perhaps working directly with Flyde https://github.com/flydelabs/flyde + some AI assistant to build the custom nodes you'll need might work for that use case.
When I started Flyde, the underlying visual programming language powering Flowcode, I went for DOM as it was the simplest solution to get something working. I was sure a rewrite to WebGL/Canvas would be needed to be performant, but we managed to render pretty complex flows and leverage the ever-growing React ecosystem. Also, react-flow was in its infancy when I started, but even later, as it evolved, I still prefer to have full control over the experience. I strongly believe that the editor and the ergonomics of the "language" are inseparable, and if you want to build something truly great, you have to control the experience end-to-end.
I do think one day WebGL/canvas might be required to take the editor to the next level. One example I always think of is this one - https://xai-primer.com/tool/ It's a great UX solution for nested flows (something Flowcode supports). But as long as I can stay with DOM, the better.
Re: deepwiki - thanks for that! very cool website and LLM usage
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.
Lowering the barrier of collaboration is indeed a major goal for us. In the DRAKON analogy, Flowcode might help technical product managers collaborate with developers on LLM-heavy logic.
Re: vibe-coding - that matches our vision 100%. Let AI build the nodes while a human (even if heavily AI-assisted) oversees
We imagine 3 use-cases with Flowcode:
- Non-developer, but technical roles (IT, Automation experts) using it as a more powerful and flexible alternative to n8n.io/make.com
- Technical product managers using Flowcode to integrate AI-based flows into their product and collaborating on them with developers
- Experienced developers building LLM-heavy (or any other async/concurrent heavy logic actually) looking to build faster flows
As for the DOM nodes - as a React frontend developer by trade, the DOM was my first choice for simplicity when I started working on Flyde a few years ago.
I was sure I’d eventually need to switch to Canvas or WebGL, but surprisingly, the DOM has held up pretty well. It’s been performant enough to render complex flows smoothly, and being able to leverage the existing React ecosystem has been a huge advantage.
I do think there's an option for a canvas/WebGL based version in the longer-term future, especially to be able to build interactions like this one - https://xai-primer.com/tool/
Thank you!
The main website (https://www.myphotos.site) was built my co-founder Or using Webflow. He's a real pro when it comes to websites - see more of his work here https://gambit.design/
The user galleries and the editor dashboard are built using Next.js, Typescript, Tailwind, and Vercel. For the masonry, we first tried a few libraries (such as https://www.npmjs.com/package/react-masonry-css) but ended up writing our own because all the libraries we tried didn't handle proper column-height distribution.