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.
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...>?)
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...
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.
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.
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.
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.
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...
* 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.
What use cases do you target with Flwocode? As I see here it seems general purpose.
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.
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?
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?