I think that visual programming fits perfectly with modern backend dev tasks that revolve around connecting different services with basic logic. Flowcode is meant to speed up and simplify those tasks, leaving more time to think about design and solve design problems. Visual programming also works really well for developing workflows involving LLM calls that are non-deterministic and require a lot of debugging and prompt tweaking.
There are many other visual/low code tools, but they all offer limited control and flexibility (no concurrency, loops, transparency) and most suffer from the same problems (vendor lock-in, hard to integrate with existing code etc.).
Flowcode is built on an open source visual programming language (Flyde https://github.com/flydelabs/flyde, which I launched last year here on HN - https://news.ycombinator.com/item?id=39628285). This means Flowcode has true concurrency, no vendor lock-in (you can export flows as .flyde files), is Turing-complete (loops, recursion, control flows, multiple IOs etc.), lets you fork any node, integrates with code via an SDK and more.
I’d love to hear your thoughts and feedback.
I think you're exactly right on the idea of "I just diagrammed all the control flow why can't I just push run". It's kind of crazy to introduce a point of failure (and a menial translation step) by writing code to match the diagram.
Another huge benefit that I learned when reading about drakon (obvious in retrospect) is that good visual programming makes the software development process more accessible to other smart people involved instead of locking it away behind computer jargon and tools (the drakon example was rocket scientists able to now work on, review, and validate the logic and control flow instead of having to just hope it ended up right).
I hate that I'm saying this but this would actually make me feel a lot better about the vibe coding going on right now. If the control flow was right, hand crafted, and easy to review I'd feel a lot better about throwing the implementation details of many individual nodes over the wall to the ai without worrying about the house falling down.
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
>Given a folder of scanned files, create a .bat file with move commands which renames each file using the information from the scan of the form and superimposed check using the naming convention: $<amount of check>_<date of check in YYYY-MM-DD format>_<Invoice ID>_<PWS ID>_<name of company from population line>.pdf
https://app.getflowcode.io/api/run/7344545b-116c-44f1-83e0-2...
and when I run it, I get:
>{"message":"No matching HTTP trigger found"}
but I was expecting to be prompted for a folder.
It reminds me of Node-RED which seems very similar but is aimed at IIoT applications.
I’m working on a version that is based on Erlang and not NodeJS which isn’t a true concurrent language.
For me, flow based programming makes the most sense with languages which are truly concurrent and message passing is baked in, ie Erlang.
One thing I’ve come to realise is that visual programming is a hard sell, hence my effort to create a visual environment for Erlang - to introduce visual programming to a different set of developers.
I feel that something like BPMN should be the starting point becomes at it from the business person or business analyst's point of view and then us more developer types can fill in the missing pieces, rather than starting from the developer POV and trying to foist that on the less technical stakeholders.
Anyway, I ask because Write File returns nothing <https://docs.getflowcode.io/docs/reference/file-system/write...> but there's also no discussion on that page of what happens when one cannot Write File (and the ways that can fall over are almost unlimited)
Also, please fix the inputs bullet list, that's a pretty glaring "no one reads these docs" bug. While you're there, never, ever, ever, ever, ever just have the documentation for anything be a repetition of the input variable's name. I can read, what I can't do is know what the domain of possible encodings are available (base64? base85? uuencoding? gzip+base64 <https://docs.cloud-init.io/en/24.3/reference/modules.html#wr...>?)
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
A lot of the issues related to visual vs text based programming have been debated here many times. As someone with a foot in both camps, I tried to summarise the various arguments here:
https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...
I'm not entirely sure what you mean. But I think a visual data wrangling tool (like my Easy Data Transform) is easier to debug than it's code based equivalent (like Python + Pandas) because you can click on each node in turn and see exactly what is happening, step by step.
You have no idea how many times we had wished all this data transformation was in vanilla Java/Python. Our life would have been so much easier. But at this time, it is too large to ignore.
These styles of programming environments are not new. We have seen many such tools in the past. I think they are useful (to an extent) when dealing with high-level compositions such as orchestrating a video pipeline, shaders, simple logic.
They start to fail very quick when you need to implement more advanced algorithms and processes that are not yet abstracted in reusable blocks. Needless to say, it is easier to write code at this point. Just less cognitive load and frankly the visual model does not help when you have a solid mental model - you can keep more information in your head in abstract forms than the eyes can scan and process.
I am lurking in the n8n community and I have noticed similar patterns. The more elaborate workflows are just not as robust as they could be if you write code - and they happen to be very difficult to maintain too and full of bugs.
Other than that... these types of framework have their place and as I said, overall I think they are useful as long as they are used in the right way.
Visual code is all over the place if you look; Any time something advertises itself as "low code" or "no code" it's a drag-and-drop flow based UI like this one. Most (if not all) ETL systems work this way, and all kinds of low-code AI Agent frameworks are cropping up.
I do agree that there very high prices to be paid for this stuff, and worst of all most of those costs are hard to see, and only crop up late in the project, when, as you point out, the more complex algorithms and processes crop up.
https://en.wikipedia.org/wiki/Extract,_transform,_load https://nifi.apache.org/ https://hop.apache.org/
Literate Programming - coined by Donald Knuth and at the heart of Jupyter Notebooks - is powerful means of making software development a tool in the pockets a lot of people. I agree that just pressing "run" is critical to making a tool like this accessible.
I'm one of the core contributors to SpiffWorkflow. We are also visual programming platform and echo your belief of the power of combining visuals with programming. I shared this article here a few months ago that delves into our methodology. - https://medium.com/@danfunk/5-ways-bpmn-python-will-simplify...
conartist6 mentioned elsewhere in the comments of a need for a common standard for editors - I think BPMN could be that standard, or new revolutions of it, such as POWL.
collingree mentioned "good visual programming makes the software development process more accessible to other smart people" -- I think this maybe the MOST important long term benefit of these tools. More people in organizations need to understand what the hell is going on - and stop shrugging their shoulders when it turns out all the business logic is buried in 100k lines of code. Important shit should be easy to find and change.
As many others have mentioned here, visual tools are not likely to see wide adoption by software engineers for all of their work. But as middle groud in which to plant business rules, so those rules can be cultivated - it could change the world and the way we collaborate on software efforts.
Would love to talk to you both sometime, share war stories, dreams, and go to market strategies.
As we know networks never fail, read timeouts aren't a thing and error handling is not necessary as networks never fail and read timeouts aren't a thing and error handling is not necessary as networks never fail and read timeouts aren't a thing...
I’ve been exploring something similar: combining visual programming with LLMs to teach computational thinking by hiding most of the syntax.
- Paper https://www.computer.org/csdl/proceedings-article/vl-hcc/202...
- Related demo https://flowpilot.trx.li/
I poised that we could merge Visual+LLM to teach Computational Thinking skills by abstracting the code syntax.
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
* Flowcode is a clever name but since you are positioning yourself as an alternative to code ("Code is messy and complex") the name is contradictory, just call it "Flow" (or "flows" or "Flower" something)
* You are replacing the legacy of code with something new, embrace new ideas that get out of the "one running process" paradigm, e.g: durable functions. There are a bunch of companies in the space (inngest, DBOS, trigger.dev) who are doing very interesting things, copy/steal/leverage all the great things they're doing -- your product's value is the visual programming
* Most developers today are already writing code so getting out of their code flow to do something visual might not fit well, whereas there are lots of non-developers who would love a product like this (see: the success of Make.com, Zapier etc.) because you're offering the AI integration for creating workflows which gives them confidence to go beyond what Make, Zapier etc. offer
If I were marketing this product, my pitch would be reframing programming as something anyone can do when it doesn't involve code, i.e:: your users can become a developer without writing code, AI-assisted visual programming builds production-ready systems without a single line of code. Code is archaic, (visual) programming is the future. Vibe coding is faster horses, AI-assisted visual programming is flying cars.
You're right that getting developers to switch to visual programming will be tough. But we believe that: 1. In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code 2. There's a growing segment of non-developer-but-technical people: Self-taught builders, Product Managers, IT/Automation specialists. We think these people are currently stuck with existing tools that are very limiting. And once they're able to deploy real products with visual programming it will be a gamechanger for them. 3. Collaboration - Even if developers prefer textual code when on their own, when they're working with non-developers (product teams, clients etc) there's a big benefit for being able to share and present how things work.
I completely agree but I think that's a very hard sell. People who write code are often years deep in their preferred workflows and asking them to reconsider how they build things is a very big ask.
> Even if developers prefer textual code when on their own, when they're working with non-developers (product teams, clients etc) there's a big benefit for being able to share and present how things work.
The problem here is that developers lead implementation. The ideal implementation for a stakeholder is rarely the implementation that is delivered, because developers are taking requirements and translating them into the things they want to build. That's why so many products end up bad: developers have too much power by virtue of code being seen as some sort of magic spell that only a true genius can master. Can you imagine a non-technical person successfully dictating that the solution must be built with visual programming?
Low code / no code is powerful because it turns the relationship between product owner and developer on its head, it puts the product owner back in the driving seat (instead of a passenger begging the developer to go in the desired direction and accepting they'll probably end up somewhere... nearby, hopefully). Hiring the wrong developer(s) can be very bad for a company because of how much a developers choice's influence the product and business.
The proliferation of low code / no code in business often comes from outside engineering, many developers, regrettably, love to write code. Often you'll find that non-technical departments of companies have secretly started using things like Make and Zapier and n8n without telling the engineering department because they feel like they finally have the opportunity to make technology work for them.
Developers that exist in service of product are already using platforms like Make and Zapier and n8n because they understand how much value there is in programming without writing code, but for them visual programming probably isn't that much of a differentiator because they already have a vision in their head of how programming works.
Anyway, your product is great, I am sure you'll succeed regardless of the approach you take :)
What about Alteryx, Blender, LabView, Unreal Blueprint and any number of other node based tools?
For a simple example, here is Conway’s Game of Life. I’ve seen much more complex things implemented as well.
It's general purpose programming where it's yet to really succeed.
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
What use cases do you target with Flwocode? As I see here it seems general purpose.
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
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.
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.
One major breakage is that I can't watch the demo video on a modern device (S24U, firefox).
If I press play, the video comes up and begins playing with a massive play button over it. If I press the maximize button, the video goes away and it locks the view into a horizontal orientation centered on apparently some random part of the webpage.
Other broken parts made me think I hate Dark Reader installed (I don't), and the testimonials at the bottom overlap—maybe they're meant to be swiped through, but that doesn't work.
I'm working on the same idea, but I'm trying to take it several steps further by letting any syntactic programming language be rendered, edited, and run as no-code.
This is a response to my observation that the limit to the growth of these things is that they always have "meh" editors because the editor and the programming language are tightly coupled -- right now if there are ten visual programming languages there are ten different visual programming language editors.
This is probably the biggest reason these tools don't catch on professionally: you can't learn the editor tool and take that skill with you to a new language/project as you can with a text editor and syntactic languages. Fortunately this is the problem I have solved.
Would love more built-in templates. Might be useful to plug this to Zapier, or support MCPs.
Edit: And built-in logs please!
Firstly, and to be fair, this is more for the comments than OP, can we please stop kidding ourselves? People have been trying to make tools to allow "non-developers" to code without coding since COBOL, and they all either failed, or end up requiring that users learned how to code anyway. Except maybe Excel.
Secondly, this has some good ideas, but makes the same cardinal sin of, seemly, all visual programming tools: try to encode control flow visually. No one wants to write ifs, fors, and whiles as connected nodes. It sucks. Text is MUCH better for that. You probably are very, very rarely writing flowchart diagrams in real life. I know I don't. I write state machine, architecture, data flows, etc., unless I'm being forced by some braindead tool to write control flow logic with little boxes and arrows.
The thing that is actually interesting here is the boxes that provide higher level abstractions, like HTTP requests, LLM calls, etc. Give me one or two different nodes in which I can just write some code to process input and return output, and maybe some dispatch and map nodes, and focus on providing higher level abstractions out of the box, and allowing me to build my own abstractions too (i.e., parametrised graphs). Think more functional, less imperative.
As is, that doesn't look like a tool I'd be excited to use, but I won't deny it has some potential to be interesting.
For what it's worth LabVIEW presents those structures as container boxes, which IMO works well enough. To put it another way, visual coding has many problems, but when programming LabVIEW I didn't find the representation of control flow to be one of them.
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.
https://app.getflowcode.io/playground/cc12cce1-265f-4c2a-b17...
https://app.getflowcode.io/playground/cc52f949-ec8d-408a-b54...
My thought is that flow graphs are a great fit for the AI wave since the weakness in the graphs is mostly around "random access" problems that need to model a broad technical vocabulary, while the weakness in using the AI is in it not knowing the boundaries of the problem space and just generating endless text slop instead of using it to generate a configuration or remake a common algorithm with a small tweak. Tying the two together into a system that looks like "human oversight over automated coding details" should be a major step in the right direction.
One thing I didn't like much was when dragging a node that has an input connection, to the left: The shape of the connection snakes behind the node and has some very sharp corners on it. Apart from being a bit of an ugly shape for a spline to be in (personal opinion) I think going far behind the node like that might have the potential to obscure the connection in certain cases. Legibility of the network should be a top priority for a project like this in my opinion (and you've already done very well! this is more of a niggle, not a real criticism!) Good old adage says that reading code is much harder that writing it and node-networks don't really revolutionize things on that front even though they can help a bit in quite a few cases.
I've used SideFX Houdini a lot and am very familiar with Vops: Node-based Vex code editing in Houdini (to see an example get inside (doubleclick or Enter-key after selecting) a 'Point Vop' inside a 'Geometry'/Sop subnetwork). I'm a massive fan of the way that Vops works! Plus you can inspect the actual code that the overall network is generating by RMB->"Vex/Vop Options"->"View Vex Code" on the containing node. Ah I see flowcode has 'View/Fork Code' for the code of individual nodes, which is awesome!.. but is there a way to see the code of the 'overall network' too? (ie what the wires become in terms of calling, if the nodes are like methods).
So yeah, I think Vops is great, and super fun! If you haven't played with it a bit I think you should! (and you totally can check it out for free!)
I've added a LOT of additional accelerator/helper tools to Vops that I think make the overall workflow much more pleasant. Would be happy to go into what they do in an email or something. I think Vops really shines when you want to quickly belt out a small data processing/generation task quickly without heaps of typing/syntax. The results are generally great too I reckon (certainly run very fast when processing huge batches of similar things).
It's not good for future editors when the number-of-nodes+wires gets too large inside any given subnetwork-level though! I think it's totally fine if there is heaps of nodes/substructure inside loads of 'subnetwork' (slash Houdini-Digital-Asset '.hda' ('.otl') levels as long as the function of the node is well 'encapsulated' (just like a good function/method should be!). Once networks get too big and complex it can become a bit of a maintenance burden, and it can often be sensible to switch to editing Vex as text instead, and putting things in headers/libs and so on when Vex things get reeeally big.
Aaaanyway I shouldn't go on about it I just want to make one main point about the wires in Vops: There are 2 'wire styles' (Shift+S to toggle): Rounded (my preferred style) and 'Default' (which I think is maybe also called 'Straight' in some places but it certainly isn't straight lines, just as straight as possible!). With both of these wire styles, if you have two Vop nodes stacked vertically, and an output on the right of the upper one is connected to the first (uppermost) input on the left of the lower one, you can move either of the nodes vertically about as close as you like to each other (without touching) and the wire will still go through the gap! This is especially so for the 'rounded' style as the line can literally go straight-horizontal through the gap! Of course it's still perfectly possible to make a wire to go behind a node, but in general I think they've done it very thoughtfully! I haven't really stopped to appreciate how well-done it really is, but I think it's top notch and encourage you to check it out, wire then drag some 'null' nodes around and see how it behaves and maybe it might yield some inspiration for flowcode? (And I'll feel quite silly indeed if you reply with 'yeah I know Vops plenty well myself', so apologies if that's the case!!)
Edit:Clarity
Jokes aside, congrats on the release! why choice of DOM for nodes instead of canvas?
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/
Has nice features such as vector image exports of flows ...
Sounds intriguing! ...so why doesn't the website actually say any of this?
When a person visits the site, the only things they can do are log in, sign up, or "get started", without any indication of what they're even getting started with. Can I please know what the product/service is before I have to decide whether I want to try it out?
