Show HN: Flowcode – Turing-complete visual programming platform
app.getflowcode.ioHey HN! I’m Gabriel, and I’m excited to share a project I’ve been working on for the last few years. Flowcode is a visual programming platform that tries to combine the best of both worlds (code and visual). Over the years I found myself repeatedly drawing architectures and logic. It was always my dream to just press “run” instead of having to write them in code afterwards. But none of the visual tools I found were flexible and transparent enough for building real products.
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.
The main link returns a 404 - maybe a griefer deleted example1?
I love your premise here. I think visual programming has such untapped potential even though it has been tried and tried and tried so I hope you crack the code a bit (lol).
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.
Author here. Thanks!
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
I feel like visual programming opens up for paradigms that would otherwise be hard grasp. And it opens up for many alternative ways to interact with "source code" - which feels under explored.
The mobile site is pretty seriously broken in multiple places. This does not inspire confidence in the project.
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.
This is very cool! I’ve used workflow builders for AI-based workflows before, but the ability to add custom code as work blocks is incredibly useful. A great idea would be to include a CLI to visualize the existing code. It might not be trivial, but current-gen AI could help extract modules from the code.
Looks very good, I believe this type of product is the future (instead of vibe-coding that produces heaps of junk new code). A few thoughts:
* 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.
Pretty cool! Congrats on the launch.
Would love more built-in templates. Might be useful to plug this to Zapier, or support MCPs.
Edit: And built-in logs please!
I just want to make an observation based from previous experiences.
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.
It’s all about using the right tool for the job. In control systems I have seen nightmares of for loops and if then conditions replaced by a skilled practitioner to a beautiful block diagram that solved the problem and illustrated to the reader the form of the solution.
IMO, Complexity is still best tackled with text. Low-code for lunch, spaghetti for dinner.
Agree. My understanding of why such visual node programming model exists, is because it is easier to sell to non-technical CEO. What's funnier is that this tool targets back-and developers. I don't know any BE dev who would prefer this over plain text programming.
Congratulation on the launch! I definitely see a future in visual scripting, the best candidate I have for my next project is https://luna-park.app/ but I'll be experimenting with FlowCode/Flyde.
What use cases do you target with Flwocode? As I see here it seems general purpose.
Great reference! Even mentioned it on Flyde's launch on HN - https://news.ycombinator.com/item?id=39628575
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
Unrelated to https://www.flowcode.co.uk/
Let me know if you want to try to collaborate.
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.
Reminds me a little of Node-Red, for me coding is just easier than connecting boxes but it would be cool if someone cracked the visual programming route.
Just to let you know, the name conflicts with Matrix TSL's Flowcode[0], which is for simpler embedded programming.
[0]: https://www.flowcode.co.uk
I remembered Flyde : looks interesting, will definitely try.
Wow, I used to hate myself, but I hate this even more! /j.
Jokes aside, congrats on the release! why choice of DOM for nodes instead of canvas?
Haha, thanks!
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/
[dead]