10 mins would be amazing
297 karma · joined May 30, 2015
Would love to chat with people looking to combine n8n-ish capabilities in their code!
We believe that many programming tasks are better done with textual coding.
Interpreting Flyde (the visual programming language behind Flowcode) flows and running them (see https://github.com/flydelabs/flyde/blob/main/core/src/execut...) ) will not benefit from being visual. It's mostly synchronous, borderline fractal logic.
A great use case for visual programming would be a task that involves several LLM calls, third-party vendors, and some transformation logic on top.
I checked your project, loved the idea and implementation! Played with it a bit, was very slick. Going to read the paper soon. Congrats
PS1: A poster about Flyde, the visual-programming was accepted to VL/HCC 23 - https://conf.researchr.org/details/vlhcc-2023/vlhcc-2023-pos... PS2: We call our AI copilot "Flowpilot" as well :D
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
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/
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.
Anything else you're curious about?
(and server-side secure!)
Thanks for the feedback!
At first, we wanted to auto-sync galleries and were bummed by the way this API works, but tbh it ended up being more private and secure for the user (no auto-syncing that embarrassing picture that shouldn't be online) and helped us avoid implementing a picker on our end.