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.
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
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.
Great stuff, wish you every success with Flowcode.
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.
Interesting discussion. How do you see BPMN (Business Process Modeling Notation) fitting into this picture?
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.
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.
What is the error handling story? I'm shocked that Control Flow doesn't contain Try-Except
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
History shows that visual programming can work very well in particular domains (data wrangling, signal processing, 3d image rendering etc) but has never really been successful for general purpose programming.
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:
I totally agree but Id also like to point out that visual debugging on itself is impractical (although cool and easy to pick up). It has its place in education though.
>I totally agree but Id also like to point out that visual debugging on itself is impractical
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.
We use an internal 'no code' tool to do complicated data transformation logic. Our flow has become so large and convoluted, it is extremely difficult to put feature and debugging is absolute nightmare.
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.
If your nocode tool was a graph, a TUI debugger [0] like this could have helped. The problem is that people usually try to use the graph UI for debugging as well.
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.
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.
"The past is never dead. It's not even past" - William Faulkner
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.
Visual workflow tools, particularly those that are able to support a human-in-the-loop, MUST exist for the world to adapt and effectively use LLMs.
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...
Yea! Just like how the electricity grid of an entire country is guaranteed to be operating every day. And if it wouldn't, then we'd be quick at finding out what the cause is.
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.
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.
> In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code
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 :)
Agree that these tools are enormously useful for non-programmers to automate things. I think the biggest area where all visual programming languages is in scalability, flexibility, and speed compared to a skilled (text) programmer. There is absolutely space for these tools, but I think that the wide majority of people who spend enough time programming will prefer text.
The tradeoff between visual and text programming feels like a classic learning curve vs. skill ceiling tradeoff.
Devs may take time to adopt visual programming, but SME will more readily try this to improve execution. Visual programming will be the way SME and LLM build consensus on execution.
So far there are zero data points on the success side of the fence when it comes to visual programming. The exceedingly rare times I come across it professionally it's a toy project or something that's basically in the state of "We wish it was just code but we don't dare touch it".
In the era of vibe coders, visual programming seems like an interesting way to build consensus with an LLM when making a decision. LLM shows you a visual for its execution and the vibe coders feel like its approachable enough to tinker with the visual to improve execution.
Hey — not sure if you noticed, but that is just a fork. The main repo (they rebranded as Enso) is still under active development. That said, I’m not too excited about the direction they’ve gone with it over the past few years.
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.
Looks very interesting. I am currently researching node-based developer tools and libraries, and after a quick look at your code I wonder why you chose to create your UI from scratch instead of using a diagramm-ish utility (react-flow and many others)? I know there are some tradeoffs with each, like one might be geared toward drawing, another for graph visualization, another for lots of nodes etc, and so maybe you didn’t like these tradeoffs?
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
Would be nice to see some screenshots instead of needing to jump into the demo. Sometimes I like to skim a bit to understand what I'm getting into before I "do."
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.
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.
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
Node-RED is mentioned deep in the thread. But just to say that Node-RED is over a decade old and is very widely used. Including some very large organisations like Siemens and Hitachi. It has thousands of packages and is Node.js/JavaScript based and so relatively easy to expand.
Worth noting that Software AG has an integration product called webMethods Integration Server (now all owned by IBM, I believe) that has visual language called Flow[0].
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.
Congrats on your launch! Looks very good! We are building a similar product at www.midio.com and it seems you have come to some of the same conclusions as us about visual programming.
I'm starting to see line-of-business folks start jumping into Python using LLM. It's going to be hard to compete with that with your custom flow diagrams.
If you can't write the software that runs the flowcode with flowcode it kind of makes it simply a different notation and not a revolutionary paradigm shift?
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.
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.
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.
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.
"No one wants to write ifs, fors and whiles as connected nodes"
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.
I was imagining this kind of product the other day, in the context of building content creation pipelines(I was looking into extending Blender to call out to ffmpeg and similar tools), and now here's a full example of where it could go - I'm on my phone but I'll dig in later.
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.
Really cool! I love programming with nodes and this seems like an awesome start!
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!!)
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/
> 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.
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?
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 tried creating a workflow:
>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.
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.
My pleasure!
My problem has been to find a front-end which will actually work with local files....
Great stuff, wish you every success with Flowcode.
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.
Interesting discussion. How do you see BPMN (Business Process Modeling Notation) fitting into this picture?
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.
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.
What is the error handling story? I'm shocked that Control Flow doesn't contain Try-Except
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...>?)
Re: docs, 100%, it needs tons of improvement.
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
History shows that visual programming can work very well in particular domains (data wrangling, signal processing, 3d image rendering etc) but has never really been successful for general purpose programming.
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 totally agree but Id also like to point out that visual debugging on itself is impractical (although cool and easy to pick up). It has its place in education though.
>I totally agree but Id also like to point out that visual debugging on itself is impractical
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.
We use an internal 'no code' tool to do complicated data transformation logic. Our flow has become so large and convoluted, it is extremely difficult to put feature and debugging is absolute nightmare.
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.
If your nocode tool was a graph, a TUI debugger [0] like this could have helped. The problem is that people usually try to use the graph UI for debugging as well.
[0] http://assets.asyncmachine.dev/video.gif
If it is an internal tool, why can't they add a flow that calls Java/Python?
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.
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.
"The past is never dead. It's not even past" - William Faulkner
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/
Visual workflow tools, particularly those that are able to support a human-in-the-loop, MUST exist for the world to adapt and effectively use LLMs.
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.
Re: HTTP Flows.
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...
Yea! Just like how the electricity grid of an entire country is guaranteed to be operating every day. And if it wouldn't, then we'd be quick at finding out what the cause is.
Love the idea!
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.
Thank you!
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
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.
Hey, author's co-founder here.
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.
> In the right use case (standalone API/workflow, multiple LLM calls, concurrency etc.) working visually is going to be 10x better than code
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 :)
Agree that these tools are enormously useful for non-programmers to automate things. I think the biggest area where all visual programming languages is in scalability, flexibility, and speed compared to a skilled (text) programmer. There is absolutely space for these tools, but I think that the wide majority of people who spend enough time programming will prefer text.
The tradeoff between visual and text programming feels like a classic learning curve vs. skill ceiling tradeoff.
Devs may take time to adopt visual programming, but SME will more readily try this to improve execution. Visual programming will be the way SME and LLM build consensus on execution.
So far there are zero data points on the success side of the fence when it comes to visual programming. The exceedingly rare times I come across it professionally it's a toy project or something that's basically in the state of "We wish it was just code but we don't dare touch it".
>So far there are zero data points on the success side of the fence when it comes to visual programming.
What about Alteryx, Blender, LabView, Unreal Blueprint and any number of other node based tools?
What about Blender nodes? I’ve seen some pretty cool and fairly complex generative modeling using nodes.
For a simple example, here is Conway’s Game of Life. I’ve seen much more complex things implemented as well.
https://www.reddit.com/r/blender/s/ehejxLqiiR
In the era of vibe coders, visual programming seems like an interesting way to build consensus with an LLM when making a decision. LLM shows you a visual for its execution and the vibe coders feel like its approachable enough to tinker with the visual to improve execution.
Visual coding as domain stuff DSL has seen success in a variety of areas, as others have given examples to.
It's general purpose programming where it's yet to really succeed.
Node based programming is pretty common for visual effects, like shader graphs (Unity), animation (Houdini), colour grading (DaVinci), etc.
Puredata, Max/MSP for realtime audio/visuals, Touchdesigner
That reminds me of a very beautiful flow based language years ago, Luna-Lang[1] but it seems that the website died and it is no longer maintained.
[1] https://github.com/binary132/luna
Hey — not sure if you noticed, but that is just a fork. The main repo (they rebranded as Enso) is still under active development. That said, I’m not too excited about the direction they’ve gone with it over the past few years.
I went to the Enso website, but it looked like spam, so I left
Have you seen Bret Victor's talk? You might want to contact him: https://www.youtube.com/watch?v=PUv66718DII
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.
Looks very interesting. I am currently researching node-based developer tools and libraries, and after a quick look at your code I wonder why you chose to create your UI from scratch instead of using a diagramm-ish utility (react-flow and many others)? I know there are some tradeoffs with each, like one might be geared toward drawing, another for graph visualization, another for lots of nodes etc, and so maybe you didn’t like these tradeoffs?
btw, https://deepwiki.com/flydelabs/flyde
Hey, author here. Thanks!
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
Would be nice to see some screenshots instead of needing to jump into the demo. Sometimes I like to skim a bit to understand what I'm getting into before I "do."
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.
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/
Node-RED is mentioned deep in the thread. But just to say that Node-RED is over a decade old and is very widely used. Including some very large organisations like Siemens and Hitachi. It has thousands of packages and is Node.js/JavaScript based and so relatively easy to expand.
Node-RED is a great tool, especially for IoT and pure automation use-cases.
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.
Worth noting that Software AG has an integration product called webMethods Integration Server (now all owned by IBM, I believe) that has visual language called Flow[0].
[0] https://en.wikipedia.org/wiki/WebMethods
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.
Lovely visual and ergonomics from the few I've seen of flyde (your link is still returning a 404)
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
Congrats on your launch! Looks very good! We are building a similar product at www.midio.com and it seems you have come to some of the same conclusions as us about visual programming.
Looks like it! Best of luck with midio.com, looks like a great product.
I'm starting to see line-of-business folks start jumping into Python using LLM. It's going to be hard to compete with that with your custom flow diagrams.
If you can't write the software that runs the flowcode with flowcode it kind of makes it simply a different notation and not a revolutionary paradigm shift?
You theoretically could. Not sure it's the right tool for the right job.
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.
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.
I remembered Flyde : looks interesting, will definitely try.
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.
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!
Are you similar or competiting with https://icepanel.io/ ?
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.
I swear it would be harder to make a non Turing complete visual programming platform
Sigh.
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.
"No one wants to write ifs, fors and whiles as connected nodes"
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.
https://labviewwiki.org/wiki/For_loop
OP here.
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.
I'd love Excel where such visual language is used instead of their crap formula syntax. Image how powerful it could be
The main link returns a 404 - maybe a griefer deleted example1?
Thankfully because it loads so much JS I was able to click before it navigated back to the homepage. These are the two examples they link to:
https://app.getflowcode.io/playground/cc12cce1-265f-4c2a-b17...
https://app.getflowcode.io/playground/cc52f949-ec8d-408a-b54...
I was imagining this kind of product the other day, in the context of building content creation pipelines(I was looking into extending Blender to call out to ffmpeg and similar tools), and now here's a full example of where it could go - I'm on my phone but I'll dig in later.
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.
Really cool! I love programming with nodes and this seems like an awesome start!
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
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/
checkout Node-RED[1], they use a giant SVG as their canvas.
Has nice features such as vector image exports of flows ...
[1] https://nodered.org
[dead]
> 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.
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?