Show HN: Flyde – an open-source visual programming language(github.com)
github.com
Show HN: Flyde – an open-source visual programming language
https://github.com/flydelabs/flyde
128 comments
That's really great.
I know it's polarizing but I truly think that visual programming remains an entirely unexplored area. I'm convinced that the current state of "text" programming is totally ineffective and in fact we are the last domain producing things with computers which still insist in being limited by the text files in folders abstraction.
It's a shame that in 2024, I still have to search for text in files like it's 1970, guess which file does what based on the dozen of characters of the file name and can't see at a glance which other files are dependencies or uses.
I can't "see" my entire codebase, zoom in and out, I still have to guess the relation between some line of code and another in another file.
My ideal IDE of the future just allows me to see all my codebase like a big fractale.
I know it's polarizing but I truly think that visual programming remains an entirely unexplored area. I'm convinced that the current state of "text" programming is totally ineffective and in fact we are the last domain producing things with computers which still insist in being limited by the text files in folders abstraction.
It's a shame that in 2024, I still have to search for text in files like it's 1970, guess which file does what based on the dozen of characters of the file name and can't see at a glance which other files are dependencies or uses.
I can't "see" my entire codebase, zoom in and out, I still have to guess the relation between some line of code and another in another file.
My ideal IDE of the future just allows me to see all my codebase like a big fractale.
>> visual programming remains an entirely unexplored area
Visual programming languages have been around since at least the 1970s:
https://en.wikipedia.org/wiki/Visual_programming_language
Several are used real-world production cases:
https://en.wikipedia.org/wiki/LabVIEW
https://en.wikipedia.org/wiki/Simulink
https://en.wikipedia.org/wiki/Pipeline_Pilot
https://en.wikipedia.org/wiki/IBM_Cognos_Analytics
While visual programming systems work better for some use cases, they are usually less agile versus text-based systems for several generalized programming tasks: 1) difference comparisons ("diffs"), 2) version control, 3) code search, and 4) code input (Most visual systems require a mouse and careful placement of connectors).
Visual programming systems tend to excel for domain-specific tasks carried out by non-technical or semi-technical users, but for generalized programming, text-based programming systems are more popular for highly technical software developers.
Visual programming languages have been around since at least the 1970s:
https://en.wikipedia.org/wiki/Visual_programming_language
Several are used real-world production cases:
https://en.wikipedia.org/wiki/LabVIEW
https://en.wikipedia.org/wiki/Simulink
https://en.wikipedia.org/wiki/Pipeline_Pilot
https://en.wikipedia.org/wiki/IBM_Cognos_Analytics
While visual programming systems work better for some use cases, they are usually less agile versus text-based systems for several generalized programming tasks: 1) difference comparisons ("diffs"), 2) version control, 3) code search, and 4) code input (Most visual systems require a mouse and careful placement of connectors).
Visual programming systems tend to excel for domain-specific tasks carried out by non-technical or semi-technical users, but for generalized programming, text-based programming systems are more popular for highly technical software developers.
Another problem with visual programming is it forces your program to be planar, or at least nearly planar with some crossovers.
In my experience real code can't be represented legibly on a 2D plane. "Generate code map" features of IDEs usually produce incomprehensible graphs, when you try them on actual codebases.
I never tried CodeSee before it shut down, was it any better?
In my experience real code can't be represented legibly on a 2D plane. "Generate code map" features of IDEs usually produce incomprehensible graphs, when you try them on actual codebases.
I never tried CodeSee before it shut down, was it any better?
What is code in a text editor if not a legible 2D planar representation of the "real code"?
The real difference between text and a graph of definition-use edges and nodes is that the text representation does not have any intrinsic information on the real code's structure and does not display definition-use edges - at least by default. Most code editors provide some way (via LSP/etc) to display the edges however - usually as a list of the other end of the edge in a dialog/window/similar separate from the code.
Given that some textual representation (e.g. variable names) of source and target is possible, a graph-displaying editor can just "abbreviate" an edge (or: make it implicit) by using the other end of the edge.
If a graph editor makes all edges implicit by a certain strategy of using names/whitespace/parentheses/etc, the result would be a text representation a text editor displays.
The main issue is not in difference of display, but in the mode of editing: a text editor allows much more partial input that violates the structure a graph is expected to have: malformed definitions of programming constructs that are neither a node nor an edge in the graph. A graph editor must either allow such partial input in some way (e.g. enter temporary textual representation, transform into group) or use a different input model that doesn't allow such unrepresentable input, e.g. using mostly mouse, or an editing keyboard language like Vim's objects & verbs.
On the other hand a text editor requires you to agree on a formatting style with your colleagues and running autoformatters, looking past useless formatty diffs in code review, fixing syntax errors, dangling else,...
i think the parent meant "planar" in the graph sense, that is, capable of being drawn in a plane with edges not crossing each other.
And text forces you to be linear. It’s no coincidence that everything asynchronous is treated as a minefield of potential race conditions and ephemeral bugs.
“Real code” allows you to hide the mess behind imports (I think everyone had experience of dealing with accidentally circular imports at least once in their career) and abstractions. But once you put your code as a graph on a 2D plane, you realise what kind of horror you are dealing with. And sometimes even this trick doesn’t work: For example, it’s hard to abstract away the states and transitions of a finite state machine; so while they may look fine on a diagram, they often look like a mess of spaghetti as code.
“Real code” allows you to hide the mess behind imports (I think everyone had experience of dealing with accidentally circular imports at least once in their career) and abstractions. But once you put your code as a graph on a 2D plane, you realise what kind of horror you are dealing with. And sometimes even this trick doesn’t work: For example, it’s hard to abstract away the states and transitions of a finite state machine; so while they may look fine on a diagram, they often look like a mess of spaghetti as code.
Or if you do functional Scheme Bricks is perfect visual programming language for scheme/lisp
https://github.com/nebogeo/scheme-bricks
https://github.com/nebogeo/scheme-bricks
Text vs visual programming is a topic that comes round regularly. I've tried to write summary of why both have their place here:
https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...
It agrees with quite a few of the points you make above.
https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...
It agrees with quite a few of the points you make above.
There are also the three graphical PLC languages standardized by the IEC - Ladder, Function Block Diagram, and Sequenced Function Chart.
They're used everywhere - anywhere you see a shiny metal cabinet with conduit running in and out, there's a chance there's a PLC plugging away in there.
Ladder dates back to the 70s and I'm willing to bet is the most used graphical language in existence. It looks like the relay diagrams that electricians use.
They're used everywhere - anywhere you see a shiny metal cabinet with conduit running in and out, there's a chance there's a PLC plugging away in there.
Ladder dates back to the 70s and I'm willing to bet is the most used graphical language in existence. It looks like the relay diagrams that electricians use.
I used LabVIEW for a couple of years. The big issue for me was ergonomics. Coding was physically laborious, and I went home with splitting eyestrain headaches. It occurred to me at the time that a dataflow programming language could support either text or graphical input, depending on the user's ergonomic preferences. I have the same problem with CAD.
If you count flowcharts (which one should, IMO), it has been around older than any text programming languages even.
Hard agree. For me, it's the delegation of concerns that visual programming excels at.
I don't have to care how you're getting a random point in a sphere. Whatever algorithm you want to use works for me. And since you know which algorithms work better for which scenarios, you can put all of that delegation under the hood. All I have to know about is which node to use. And if something starts breaking, I know that it can't be my problem; it has to be a problem with the node's code and that domain professional can address it.
Of course, a good dev might say "That's just having a really good API", which is true! But once you have an API so good that you don't need to know any of its internals, you're essentially trying to write a graph using documents, which is kind of silly. High-level servers are a great example (node servers, python servers, etc). There's not any utility in writing an expressJs server with text that isn't satisfied by writing it as a flow chart. Servers, at that level of abstraction, are so simple that all you really need to do is tell which keys go where, when. And that's most simply done by drawing boxes and arrows that all point to each other.
Put more starkly: there's no difference between writing `Lib.Physics.GetPointInSphere(param1, param2, param3)` and linking a `GetPointInSphere` node to `param`s 1, 2, and 3. So I think that if you're in a domain that is already at that level of abstraction, visual programming is a fantastic way to go. And if you're not already at that level of abstraction, there's value in getting there (even though it's probably going to require fracturing/modularizing existing concepts).
I don't have to care how you're getting a random point in a sphere. Whatever algorithm you want to use works for me. And since you know which algorithms work better for which scenarios, you can put all of that delegation under the hood. All I have to know about is which node to use. And if something starts breaking, I know that it can't be my problem; it has to be a problem with the node's code and that domain professional can address it.
Of course, a good dev might say "That's just having a really good API", which is true! But once you have an API so good that you don't need to know any of its internals, you're essentially trying to write a graph using documents, which is kind of silly. High-level servers are a great example (node servers, python servers, etc). There's not any utility in writing an expressJs server with text that isn't satisfied by writing it as a flow chart. Servers, at that level of abstraction, are so simple that all you really need to do is tell which keys go where, when. And that's most simply done by drawing boxes and arrows that all point to each other.
Put more starkly: there's no difference between writing `Lib.Physics.GetPointInSphere(param1, param2, param3)` and linking a `GetPointInSphere` node to `param`s 1, 2, and 3. So I think that if you're in a domain that is already at that level of abstraction, visual programming is a fantastic way to go. And if you're not already at that level of abstraction, there's value in getting there (even though it's probably going to require fracturing/modularizing existing concepts).
I think lines of code in a text editor is a terrible way of describing state machines and flow diagrams.
And I think flow diagrams are a terrible way of describing many algorithms.
Flow diagrams look great for multi-processing pipelines and event suff.
I'm interested in this as an addition to current coding practices.
And I think flow diagrams are a terrible way of describing many algorithms.
Flow diagrams look great for multi-processing pipelines and event suff.
I'm interested in this as an addition to current coding practices.
100%!
Cherry-picking what makes sense to "elevate" to the visual sphere and having it co-exist with traditional coding is the only way I believe visual programming can be truly useful.
Yeah I completely agree. Simulink works quite well because it's modelling things that are naturally physical networks. DSP/Blender style node graphs also work quite well because you really want an interactive control on every node.
In contrast visual systems that try to recreate traditional programming (add, multiply, loops, etc.) seem to be mostly awful. LabVIEW is a complete disaster (probably not helped by its dire graphic design but even so). UE Blueprints are bad.
Scratch is not too bad, but only because it's basically building a normal text-based program with lego, rather than nodes and edges.
In contrast visual systems that try to recreate traditional programming (add, multiply, loops, etc.) seem to be mostly awful. LabVIEW is a complete disaster (probably not helped by its dire graphic design but even so). UE Blueprints are bad.
Scratch is not too bad, but only because it's basically building a normal text-based program with lego, rather than nodes and edges.
While I agree that text might not be the best way to represent a program, text files have many convenient properties that make them hard to replace:
- Simplicity: every computer and most humans can interptet it without any issues
- Diffing: it's relatively easy to tell what changed in a text file between revisions
- Editing tools: text editors, formatters, etc. exist and many people know how to use them efficiently
Also, modern developer setups allow you to manipulate code as a syntax tree (see tree-sitter text-objects) and intellisense and snipping tools allow you to type much less.
- Simplicity: every computer and most humans can interptet it without any issues
- Diffing: it's relatively easy to tell what changed in a text file between revisions
- Editing tools: text editors, formatters, etc. exist and many people know how to use them efficiently
Also, modern developer setups allow you to manipulate code as a syntax tree (see tree-sitter text-objects) and intellisense and snipping tools allow you to type much less.
This seems more like a matter of having more tooling because 99.999% of programming has been text based.
If we spent the time building tools for visual coding it’s possible we’d be able to do way more.
Just thinking about diffing for example, it would be much easier to see which nodes have changes in the whole codebase by just highlighting them red. It’d be easier also to depict something like “the flow for this process changes from this to this”
If we spent the time building tools for visual coding it’s possible we’d be able to do way more.
Just thinking about diffing for example, it would be much easier to see which nodes have changes in the whole codebase by just highlighting them red. It’d be easier also to depict something like “the flow for this process changes from this to this”
Author here.
Diffing is a great example. The first incarnation of Flyde had naive version control built into it and had such diff features!
Diffing from VSCode already makes a bit of sense (see https://imgur.com/a/WXj89tx). Next step is to color it differently, and finally, add a browser extension to render diffs nicely from GitHub/Gitlab's UI as well :)
Diffing from VSCode already makes a bit of sense (see https://imgur.com/a/WXj89tx). Next step is to color it differently, and finally, add a browser extension to render diffs nicely from GitHub/Gitlab's UI as well :)
I suppose it all depends on personality: some swe's prefer to write, some prefer to draw (I do both, but would hate to only have to deal a 1mil-lines-of-code fractal, but would be (and am) fine with the 1970 approach). The OP's solution then might be a great addition to my toolbox.
That's the outcome I'm hoping to get from all these VR/AR tech people are working on. I believe we have the hardware to make this work and someone just needs to build the software.
Couldn't agree more, which is why I spent the last three years building the tech that gets us there -- a universal document object model for code! If you thought you'd be waiting 10 years for this tech, it's probably more like 2 now.
I was like WAIT that sounds REALLY familiar :D
Not really, most software in your car for example is written in the visual programming language Simulink, which IMO is leagues ahead of the concept of Flyde in layout and composability.
Simulink has been around and in heavy use for at least 2 decades but I think the $20k/yr price point is why we don’t see many other applications of it (even though people HAVE written games and web apps and such with it)
Simulink has been around and in heavy use for at least 2 decades but I think the $20k/yr price point is why we don’t see many other applications of it (even though people HAVE written games and web apps and such with it)
Thanks! I agree, and while no one knows how development will look in 5-10 years from now, I find it hard to believe it'll be _just_ textual based, and I hope Flyde will help inspire that move.
I attempted to do this [1] and explored topic of why VPL are not a mainstream too, but postponed project for maturation of VR/AR ecosystem as I see them usable only in VR now. This year actually I think to return to work on it.
[1] Rethinking Visual Programming with Go - https://divan.dev/posts/visual_programming_go/
[1] Rethinking Visual Programming with Go - https://divan.dev/posts/visual_programming_go/
IDK i started using TouchDesigner and while it was cool...had to watch tons of tutorials before i was remotely effective, and once I figured out how to have it call a python script, everything was much more productive/simple.
I see it as comparing comic book (visual) vs text book (text code). You can express some visual better with comic books, but in the end, I find text books easier to define richer and complex matter.
What you are describing sounds a lot like C4: https://c4model.com/
there's a lot of effort being put into hiding the file based systems underneath (i.e. "libraries" in MacOS, mobiles OSes like android). if something doesn't work or data is lost, it takes people who know what files are, to fix things. Please don't take files away from us, we just want to be able to help.
I will tell you the same thing I tell everyone making visual graphs like this:
PLEASE PLEASE PLEASE PLEASE PLEASE make the nodes snap to a larger grid, and have the grid browsable with the keyboard.
I'd rather use Factorio as an interface than an interface where the nodes and edges just float around.
Excel is a DAG that is browsable with the keyboard (Ctrl+[ anyone?), and that's proven very usable.
PLEASE PLEASE PLEASE PLEASE PLEASE make the nodes snap to a larger grid, and have the grid browsable with the keyboard.
I'd rather use Factorio as an interface than an interface where the nodes and edges just float around.
Excel is a DAG that is browsable with the keyboard (Ctrl+[ anyone?), and that's proven very usable.
And I rather have the boxes stay where I put them and make a mess of the lines than have the lines be all clean but every time I add a condition all the boxes reshuffle like ServiceNow does in their visual low code programming stuff
- This looks great! Very robust and I really like the focus on interoperability.
- As a general design, I prefer the integrated "function with parameters" node type found in systems like Unreal's "Blueprints" far better than having to manage the parameters and functions separately from each other. It's more cumbersome to develop, but no less flexible to use, and loads more simplified. A distinction for the code flow from the data referencing is helpful for me, at least.
- It doesn't fit my exact needs, because I need something that allows me to expose this functionality to users. Essentially, I need something that does what your playground does, as a library. The interoperability is perfect, though! Allowing users to set up flows and then being able to simply import them rather than having to translate them is a fantastic DX. I guess, at the end of the day, I would still like clean, nicely formatted Javascript (not typescript), so I imagine your library isn't really suited for that, either. But I definitely like the architecture of it!
- As a general design, I prefer the integrated "function with parameters" node type found in systems like Unreal's "Blueprints" far better than having to manage the parameters and functions separately from each other. It's more cumbersome to develop, but no less flexible to use, and loads more simplified. A distinction for the code flow from the data referencing is helpful for me, at least.
- It doesn't fit my exact needs, because I need something that allows me to expose this functionality to users. Essentially, I need something that does what your playground does, as a library. The interoperability is perfect, though! Allowing users to set up flows and then being able to simply import them rather than having to translate them is a fantastic DX. I guess, at the end of the day, I would still like clean, nicely formatted Javascript (not typescript), so I imagine your library isn't really suited for that, either. But I definitely like the architecture of it!
- Thanks!
- Re: "function with parameters" you mean so the configuration is exposed on the node itself? It's definitely something I want to consider as an UX improvement. At first, I was very puristic about having all configurations acceptable as dynamic inputs, to ensure Flyde is robust and flexible, but that led to things like the HTTP node having 5 different pins which made it even worse. Now it's a hybrid model - as an author of a node you can choose how to expose it, and many nodes in the Stdlib expose configuration in both ways
- Interesting use-case! Flyde's last incarnation was an attempt to offer this to other SaaS products (before realizing it must start OS) to allow their users to do "Visual scripting" (like https://luna-park.app/, a project I've stumbled upon)
You can check the source code of the playground and try embedding Flyde, should work!
Hey, author of https://luna-park.app here! (I was wondering where the spike in visits came from ^^'... Thanks a lot for mentioning me!).
Luna Park was indeed a npm package that you could integrate to allow users to build their own logic using visual scripting. In the end, I pivoted, and Luna Park is now a visual scripting wrapper around the Vue.js framework, allowing people to build modern webapps without code. (I also made https://roller-coaster.app to create endpoints using the visual scripting system of Luna Park)
In any case, that's super cool to see people building awesome tools like yours in the visual programming space :) ! I love how Flyde show you what node is running, and the way it executes logic is really interesting!
Luna Park was indeed a npm package that you could integrate to allow users to build their own logic using visual scripting. In the end, I pivoted, and Luna Park is now a visual scripting wrapper around the Vue.js framework, allowing people to build modern webapps without code. (I also made https://roller-coaster.app to create endpoints using the visual scripting system of Luna Park)
In any case, that's super cool to see people building awesome tools like yours in the visual programming space :) ! I love how Flyde show you what node is running, and the way it executes logic is really interesting!
Haha glad you found this comment! Love your dedication to the amusement park theme, it's rare to see web products take such a "game design" approach.
Yeah, that's part of what I'm talking about, for sure. Being able to, say, click a little expand icon to see other pins that aren't usually necessary, is great for discoverability. I'm not a big fan of library maintainers deciding that I can only use certain inputs for an underlying function that I know has more functionality. Node authors should, of course, be able to guide, but I don't appreciate them having the ability to control.
More than that, though, it's about the difference between 'data references' and 'execution flow'. It's something that Unreal makes very, VERY obvious. Color coding data types, emphasizing execution flow lines, etc. I can't recommend using it as a guide, enough. Whatever problem I've come up with as 'complicated' for visual scripting, they've got an elegant solution for.
Even stuff like being able to 'break' nodes into other nodes, or pins into other pins. So a "Point" node might be useful for sending into a function expecting a Point data type, but you might also want to send just that Point's x or y value to something else. In that scenario, you might 'break' the exit pins into a Point reference, an x reference, and a y reference. It would be cumbersome and unruly to always have that available. But the UX to make it available is straightforward and satisfying.
And then, all of that aside, I just prefer the visual look of pins integrated into the nodes. The extra lines you get from drawing between the pin and the node is messy and since you can't move them independently, they don't really add anything. Just a lot of extra buffer to prevent a 'crowded' feeling. But at least that's not something unique to Unreal. I don't think I've ever seen a visual scripting system that used pins as separate elements. So maybe it's just saturation bias. But I do like what I like!
Anyway, I'll definitely mess around with it and see if it can help with its embedded version. To be completely honest, I think there's too much friction, overall. I would need something to render as plain javascript, rather than a JSON structure or minified JS (or typescript), so there's a translation there. And then to get it graphically how I want it would be complicated due to all the domain-knowledge required for integrating with your app's underlying library (looks like next js? Not sure, but it's not something I want to work with). Not to be too pessimistic or anything. Most libraries work toward providing a complete solution, not towards providing a composable, compsitable, modular set of utilities, which is what I need. I don't hold any contempt for providing what you've provided because it's a hell of a thing and perfect for a lot of use cases, I'm sure! I'm just very pragmatic about my own use-cases, and my development quirks (like not using libraries that obfuscate functionality [next, react, svelte, etc]).
More than that, though, it's about the difference between 'data references' and 'execution flow'. It's something that Unreal makes very, VERY obvious. Color coding data types, emphasizing execution flow lines, etc. I can't recommend using it as a guide, enough. Whatever problem I've come up with as 'complicated' for visual scripting, they've got an elegant solution for.
Even stuff like being able to 'break' nodes into other nodes, or pins into other pins. So a "Point" node might be useful for sending into a function expecting a Point data type, but you might also want to send just that Point's x or y value to something else. In that scenario, you might 'break' the exit pins into a Point reference, an x reference, and a y reference. It would be cumbersome and unruly to always have that available. But the UX to make it available is straightforward and satisfying.
And then, all of that aside, I just prefer the visual look of pins integrated into the nodes. The extra lines you get from drawing between the pin and the node is messy and since you can't move them independently, they don't really add anything. Just a lot of extra buffer to prevent a 'crowded' feeling. But at least that's not something unique to Unreal. I don't think I've ever seen a visual scripting system that used pins as separate elements. So maybe it's just saturation bias. But I do like what I like!
Anyway, I'll definitely mess around with it and see if it can help with its embedded version. To be completely honest, I think there's too much friction, overall. I would need something to render as plain javascript, rather than a JSON structure or minified JS (or typescript), so there's a translation there. And then to get it graphically how I want it would be complicated due to all the domain-knowledge required for integrating with your app's underlying library (looks like next js? Not sure, but it's not something I want to work with). Not to be too pessimistic or anything. Most libraries work toward providing a complete solution, not towards providing a composable, compsitable, modular set of utilities, which is what I need. I don't hold any contempt for providing what you've provided because it's a hell of a thing and perfect for a lot of use cases, I'm sure! I'm just very pragmatic about my own use-cases, and my development quirks (like not using libraries that obfuscate functionality [next, react, svelte, etc]).
Insightful – commenting to keep a reference as I spent the last four years engineering around this very aspect.
I'm trying to wrap my head around the difference between execution models. On one hand we have real-time node systems like Unreal Blueprint, Modo or DaVinci Resolve, which depend heavily on state nodes, i.e. nodes whose sole purpose is to hold and serve information (a mesh, a transformation, an RGB matrix). These nodes act as complementary inputs to nodes in the main execution flow.
On the other hand we have Node Red and the likes, whose nodes rely on a single input. At first glance this approch might make sense from a UX perspective – simply connect your components and deploy. However with time I've come to see this as a major limitation to the extent that you're often better off writing code. After building a number of flows you start to notice certain patterns... Since nodes are uncapable of fetching data from other nodes ("state nodes" above), it's up to you as a developer to serve the node with the exact data structure it needs. The GUI gives you no hint as to the structure itself, so you're left reading the node's documentation: {payload, action, topic, subject} – different for every node.
At the core, this approach is the FBP version of polish notation in the sense that you first have to fetch all the operands before sending them to the operation. So what you're left with is a flow where every core node is surrounded by data shuffling nodes: "put this into 'action', put that into 'body', take 'payload' and store it away because the next node will overwrite it". As an effect of this "serial execution model", flows often stretch wide from the left to the right where two thirds of nodes are pure data transformations.
Somewhere around here the USP of FBP gets literally lost in the flow – the USP being to offload working memory. During building/debugging/revisiting flows, I often know right away what piece is broken. Nevertheless I spend a lot of time double-clicking on function, change, and switch nodes just to find that piece of code. The irony of it all is that I wanted to use FBP to _visualise_ logic. Instead the same paradigm hides it away.
So what you've accomplished is transforming code that goes from up to down into boxes that go left to right.
The thinking behind it all is that Node Red shouldn't make assumptions about the incoming data, however someone has to make those assumptions, and that someone is you, the developer.
It would be trivial to create a node that takes an arbitrary input (a sample message), analyses the message structure and exposes the appropriate output pins, however as long as Node Red persists with single input ports and the "message-based execution" it entails, it will take tolls on working memory and lag behind the Unreal model which I too consider state of the art.
I'm trying to wrap my head around the difference between execution models. On one hand we have real-time node systems like Unreal Blueprint, Modo or DaVinci Resolve, which depend heavily on state nodes, i.e. nodes whose sole purpose is to hold and serve information (a mesh, a transformation, an RGB matrix). These nodes act as complementary inputs to nodes in the main execution flow.
On the other hand we have Node Red and the likes, whose nodes rely on a single input. At first glance this approch might make sense from a UX perspective – simply connect your components and deploy. However with time I've come to see this as a major limitation to the extent that you're often better off writing code. After building a number of flows you start to notice certain patterns... Since nodes are uncapable of fetching data from other nodes ("state nodes" above), it's up to you as a developer to serve the node with the exact data structure it needs. The GUI gives you no hint as to the structure itself, so you're left reading the node's documentation: {payload, action, topic, subject} – different for every node.
At the core, this approach is the FBP version of polish notation in the sense that you first have to fetch all the operands before sending them to the operation. So what you're left with is a flow where every core node is surrounded by data shuffling nodes: "put this into 'action', put that into 'body', take 'payload' and store it away because the next node will overwrite it". As an effect of this "serial execution model", flows often stretch wide from the left to the right where two thirds of nodes are pure data transformations.
Somewhere around here the USP of FBP gets literally lost in the flow – the USP being to offload working memory. During building/debugging/revisiting flows, I often know right away what piece is broken. Nevertheless I spend a lot of time double-clicking on function, change, and switch nodes just to find that piece of code. The irony of it all is that I wanted to use FBP to _visualise_ logic. Instead the same paradigm hides it away.
So what you've accomplished is transforming code that goes from up to down into boxes that go left to right.
The thinking behind it all is that Node Red shouldn't make assumptions about the incoming data, however someone has to make those assumptions, and that someone is you, the developer.
It would be trivial to create a node that takes an arbitrary input (a sample message), analyses the message structure and exposes the appropriate output pins, however as long as Node Red persists with single input ports and the "message-based execution" it entails, it will take tolls on working memory and lag behind the Unreal model which I too consider state of the art.
Yeah, this is a really tricky space to delve into because the people who are most familiar with it are working on mathematical models and have very strong opinions about the "kind" of graph you're making, or what you're actually doing with the underlying data. Which is all definitely important for a node library maker to know, but the whole purpose of the library is that an implementing dev shouldn't have to know any of that stuff. So you really have to dig through a lot of irrelevant stuff about graph theory and whatnot to get to any relevant programming knowledge on the topic.
What's galling to me is that nodes map 1-1 to function calls. I can't even think of a scenario where a program that can be written as functions and objects couldn't be represented as a node graph. I can certainly shudder at the horrific types of graphs most programs would make, but they can all be mapped out. And, on the flip side, every single program I've written in visual scripting could easily be written as functions and objects. So, with that in mind, it's frustrating to go looking for information about node graphs and getting a bunch of muck about why they're 'not good', and why they don't handle certain things well, and why they aren't suited for x or y, when - in my head - I'm literally just asking for a well-formed API, and I'm getting a bunch of pushback about how APIs aren't really a good way to program. -_-
But because it's so hard to get good comparative information on visual scripting, I've also wrestled with what makes for good abstractions vs what is too broad. And that's what I think the Node Red stuff is: just too broad. Abstracting away everything breaks the value of the abstraction. So it's always about finding a balance, which is why I appreciate Epic's maintenance of Blueprints. A good API abstracts concepts you don't need to understand behind concepts you already understand. "GetDistance()" is a great abstraction because I don't care about the vector math underneath. But "Login()" is a terrible abstraction because a library shouldn't have the intimate details of my login process (meaning that it should be abstracted into more modular parts that I can more easily inject my business logic/keys into). So a node, or a library of nodes, or a node library system - they're all only as good as their abstractions. And Node Red is just way too abstracted to be "good". And, of course, the irony there is that if it were only a little more flexible, it could even be abstracted, itself, into something more use-able! If you could write a node that DID accept two inputs, you could abstract away all of the setting and swapping and trading. But since even that node could only ever be kick started by a single node, you would have to come up with some kind of hacky scheme to make any kind of utility actually function. So it's the one type of abstraction that they don't allow (their node model) which I find to be fundamental to successful visual scripting languages.
Honestly, though, I think there are some fundamental designs that visual scripting languages just need to implement, but I have a very hard time describing those designs with rigor. I would naively say that they need nodes, edges, a variable deck, a node discovery utility, and a good variable property manager. But that's just because that's what I'm used to. I think once someone really serious sits down to formalize these things, we'll have a much richer environment. I just hope they do it soon!
What's galling to me is that nodes map 1-1 to function calls. I can't even think of a scenario where a program that can be written as functions and objects couldn't be represented as a node graph. I can certainly shudder at the horrific types of graphs most programs would make, but they can all be mapped out. And, on the flip side, every single program I've written in visual scripting could easily be written as functions and objects. So, with that in mind, it's frustrating to go looking for information about node graphs and getting a bunch of muck about why they're 'not good', and why they don't handle certain things well, and why they aren't suited for x or y, when - in my head - I'm literally just asking for a well-formed API, and I'm getting a bunch of pushback about how APIs aren't really a good way to program. -_-
But because it's so hard to get good comparative information on visual scripting, I've also wrestled with what makes for good abstractions vs what is too broad. And that's what I think the Node Red stuff is: just too broad. Abstracting away everything breaks the value of the abstraction. So it's always about finding a balance, which is why I appreciate Epic's maintenance of Blueprints. A good API abstracts concepts you don't need to understand behind concepts you already understand. "GetDistance()" is a great abstraction because I don't care about the vector math underneath. But "Login()" is a terrible abstraction because a library shouldn't have the intimate details of my login process (meaning that it should be abstracted into more modular parts that I can more easily inject my business logic/keys into). So a node, or a library of nodes, or a node library system - they're all only as good as their abstractions. And Node Red is just way too abstracted to be "good". And, of course, the irony there is that if it were only a little more flexible, it could even be abstracted, itself, into something more use-able! If you could write a node that DID accept two inputs, you could abstract away all of the setting and swapping and trading. But since even that node could only ever be kick started by a single node, you would have to come up with some kind of hacky scheme to make any kind of utility actually function. So it's the one type of abstraction that they don't allow (their node model) which I find to be fundamental to successful visual scripting languages.
Honestly, though, I think there are some fundamental designs that visual scripting languages just need to implement, but I have a very hard time describing those designs with rigor. I would naively say that they need nodes, edges, a variable deck, a node discovery utility, and a good variable property manager. But that's just because that's what I'm used to. I think once someone really serious sits down to formalize these things, we'll have a much richer environment. I just hope they do it soon!
Great to see more people thinking about this space. Totally agree on the sentiment that we should be able to visualize/describe and build business logic in a very simple manner. The way I've been thinking about this is something like Legos where we can compose any logic, app, workflow we want visually and that anyone can build and share these blocks. This is almost similar to NPM packages, but for non-developers.
My attempt on this is https://openexus.com where the goal is really to create some form of universal plug-and-play building blocks. Your approach is almost very low-level with direct translation to code. My attempt is slightly higher-level (but developers can create as low level as they want). More importantly, the visual diagram build on openexus is a reactive graph (almost like spreadsheet), not a sequential directional flow graph (like node-red, or yahoo pipes).
Would love to chat if you are up for it. m at lominming dot com.
My attempt on this is https://openexus.com where the goal is really to create some form of universal plug-and-play building blocks. Your approach is almost very low-level with direct translation to code. My attempt is slightly higher-level (but developers can create as low level as they want). More importantly, the visual diagram build on openexus is a reactive graph (almost like spreadsheet), not a sequential directional flow graph (like node-red, or yahoo pipes).
Would love to chat if you are up for it. m at lominming dot com.
Open Nexus looks great! The UI design is super clean, and the open-ness of your nodes give it true Bret-Victor-ish vibes!
I started closer to this at first (but still lower-level) and slowly got "down to earth", taking a https://www.dreamsongs.com/WorseIsBetter.html approach.
I started closer to this at first (but still lower-level) and slowly got "down to earth", taking a https://www.dreamsongs.com/WorseIsBetter.html approach.
This looks super nice :) love it
Congrats on the show HN! It looks like you've put a lot of thought and effort into this, and reasearched a number of alternatives.
I'm curious to know more of what you found lacking in the various visual programming languages? You mention a few general things but (other than the integration angle) I'm having a hard time understanding exactly what limits you hit with the other options that caused you to build your own.
And to add some context to the above questions, is this primarily your own research or do you anticipate it being used for production systems?
I'm curious to know more of what you found lacking in the various visual programming languages? You mention a few general things but (other than the integration angle) I'm having a hard time understanding exactly what limits you hit with the other options that caused you to build your own.
And to add some context to the above questions, is this primarily your own research or do you anticipate it being used for production systems?
Thank you! Flyde's first incarnation was more of a "Visual serverless" platform, something like Zapier, but where you could "see the JSON" and change any piece you want. So the alternatives at that time were NodeRED, n8n and NoFlo.js.
I think NodeRED and n8n are both successful products with their own niche, but I was looking for something more flexible. At the time, I was trying to build something very robust, flexible, and generic, that could also be used to build UIs with (see this cumbersome, but working example https://play.flyde.dev/apps/974a3913-1b3b-4a0a-9ca7-4e2a69d0... ) a lower-level visual language that will match the functional-reactive paradigm I was used to code with, and not something too structured. I wanted it to be able to do most things I can do with code, and cater to application-layer developers.
NoFlo.js was the closest to allowing this, but I think that it was too early for the game, and NoFlo took a non-integrative approach. Vladimir Sibirov wrote vastly about that and why he thinks it failed in this great blog post - https://blog.kodigy.com/post/state-of-flow-based-programming... I was happy to see Flyde addressed this
Other purely FBP implementations did not put enough emphasis on the visual aspect, which for me was crucial to nail on a holistic level.
And for your last question - my goal is for it to be used in production systems, yes. I plan to release a Flyde-based visual API builder soon - https://www.trigg.dev as a more specific use-case, and hope that the fact you can download the Flyde flows and run them wherever you want will help potential users overcome the fear of using a low-code tool.
NoFlo.js was the closest to allowing this, but I think that it was too early for the game, and NoFlo took a non-integrative approach. Vladimir Sibirov wrote vastly about that and why he thinks it failed in this great blog post - https://blog.kodigy.com/post/state-of-flow-based-programming... I was happy to see Flyde addressed this
Other purely FBP implementations did not put enough emphasis on the visual aspect, which for me was crucial to nail on a holistic level.
And for your last question - my goal is for it to be used in production systems, yes. I plan to release a Flyde-based visual API builder soon - https://www.trigg.dev as a more specific use-case, and hope that the fact you can download the Flyde flows and run them wherever you want will help potential users overcome the fear of using a low-code tool.
I mean, NodeRED can be used to build front ends with Dashboard 2.0 or UI-buikder or custom nodes.
Is your project really better than NodeRED? I mean it does have over 4000 community contributed nodes.
Is your project really better than NodeRED? I mean it does have over 4000 community contributed nodes.
No, not at all. I'm not trying to build a better NodeRED. Moreover, I can only hope Flyde gets to the popularity of NodeRED one day and believe that while there is some intersection between the projects, each can excel in non-conflicting use cases.
> visual programming
25 years ago when I read that Microsoft has a software development environment named "Visual Studio" I imagined, well, something with graphs and nodes and flow and... Well something visual, right? Now it's 2024 and VS is still not visual.
Of course things are not as simple. Flyde (along with many alternatives mentioned) is visual IMHO. Keep up the good work!
25 years ago when I read that Microsoft has a software development environment named "Visual Studio" I imagined, well, something with graphs and nodes and flow and... Well something visual, right? Now it's 2024 and VS is still not visual.
Of course things are not as simple. Flyde (along with many alternatives mentioned) is visual IMHO. Keep up the good work!
Nice work, congrats!
I do love visual programming and I use n8n a lot for my side projects. I really like its "delayed debug" features, so that I can analyse each step of the flow weeks later than it happened (i.e, I can see why a webhook failed long ago and even replay it step by step).
One missing feature that I've been working on is a "export workflow to code" feature. This way, once you are finished working on a workflow, you could run it everywhere without the need of installing the full IDE.
Again, nice work!
I do love visual programming and I use n8n a lot for my side projects. I really like its "delayed debug" features, so that I can analyse each step of the flow weeks later than it happened (i.e, I can see why a webhook failed long ago and even replay it step by step).
One missing feature that I've been working on is a "export workflow to code" feature. This way, once you are finished working on a workflow, you could run it everywhere without the need of installing the full IDE.
Again, nice work!
Thanks!
Flyde is "just" a library behind the scenes, so you grab your .flyde file, and can run it with an npm package. For example:
``` import { loadFlow } from "@flyde/runtime";
const execute = await loadFlow("./celsius-to-fahrenheit.flyde");
const inputs = { celsius: 0 }; // "celcius" is a main input in the flow, therefore it must be provided when executing the flow const { result } = execute(inputs); // execute returns a "result" promise, along with a cleanup function that can be used to cancel the execution.
const { fahrenheit } = await result; // each output in the flow is a property on the result object
console.log(fahrenheit) ```
(taken from https://www.flyde.dev/docs/integrate-flows/)
But your comment strengthens my feeling that making this more intuitive and discoverable and is indeed something I should prioritize
``` import { loadFlow } from "@flyde/runtime";
const execute = await loadFlow("./celsius-to-fahrenheit.flyde");
const inputs = { celsius: 0 }; // "celcius" is a main input in the flow, therefore it must be provided when executing the flow const { result } = execute(inputs); // execute returns a "result" promise, along with a cleanup function that can be used to cancel the execution.
const { fahrenheit } = await result; // each output in the flow is a property on the result object
console.log(fahrenheit) ```
(taken from https://www.flyde.dev/docs/integrate-flows/)
But your comment strengthens my feeling that making this more intuitive and discoverable and is indeed something I should prioritize
Nice! I definitely will try it :)
I think approaches like this can be good for people learning programming for the first time, but there are two huge aspects that mean it is unlikely to be used for anything serious.
1. A new language. New languages don't go anywhere 99.9% of the time and when they do it takes a massive undertaking by hundreds of people as well as very careful design over the course of decades.
2. Building visually at the expression level. Writing expressions in any modern language is very compact. In this case what takes up a single line now takes up and entire screen.
if(n>1) return fib(n-1) + fib(n-2);
Graphs are much better for working at a high level because that's where the locality isn't there are it isn't clear what data is going where. For expressions drawing lines instead of just using the same variable that was used in the previous line doesn't help clarity.
1. A new language. New languages don't go anywhere 99.9% of the time and when they do it takes a massive undertaking by hundreds of people as well as very careful design over the course of decades.
2. Building visually at the expression level. Writing expressions in any modern language is very compact. In this case what takes up a single line now takes up and entire screen.
if(n>1) return fib(n-1) + fib(n-2);
Graphs are much better for working at a high level because that's where the locality isn't there are it isn't clear what data is going where. For expressions drawing lines instead of just using the same variable that was used in the previous line doesn't help clarity.
This is easily solved by having nodes which serve as a collection of nodes
That's basically a function, and it might work out if one typical line didn't end up taking up so much space. Expressions still end up more clear and more condensed by such a huge margin it makes nodes look silly in general cases. Houdini is able to make it work but it's all data flow, there are no branches or loops.
This gets in to another problem I didn't mention - branches and loops (not to mention class declarations).
Feeding a function result into another function argument is great, but that was never difficult for expressions anyway. Once you get into branches and loops you have another problem that is a huge problem for nodes.
Ultimately programs don't map to data flow nodes, they are imperative. Certain parts of certain programs will end up mapping very well, but when looking for silver bullets in something that isn't 1:1, you end up hacking it up and forcing a square peg in a round hole to make the dream work.
This gets in to another problem I didn't mention - branches and loops (not to mention class declarations).
Feeding a function result into another function argument is great, but that was never difficult for expressions anyway. Once you get into branches and loops you have another problem that is a huge problem for nodes.
Ultimately programs don't map to data flow nodes, they are imperative. Certain parts of certain programs will end up mapping very well, but when looking for silver bullets in something that isn't 1:1, you end up hacking it up and forcing a square peg in a round hole to make the dream work.
But that then creates the problem of lowering expressivity.
GraphSCAD addressed that by allowing functions to have custom icons.
I'd really like to see that become more prevalent.
GraphSCAD addressed that by allowing functions to have custom icons.
I'd really like to see that become more prevalent.
Does it though? With the current file system, you can only reasonably see a couple functions. You have a project directory and tabs for navigation.
Imagine you had features like zooming, being able to click on nodes to expand them, tabs, ctrl+f/keyboard navigation, etc.
Imagine you had features like zooming, being able to click on nodes to expand them, tabs, ctrl+f/keyboard navigation, etc.
Nice! Have you explored showing live values flowing through the nodes? This seems like a good use of animation.
I'll also take a moment to plug my Visual Programming Codex[1], which collects VPLs as though they're butterflies. I'm adding Flyde to the backlog of projects to document, but I'd also suggest looking around there for ideas. There are a ton of valuable new things you can do once you start visualizing programming, especially if you're visualizing the execution behaviour. I'd love to see you push this further.
[1] https://github.com/ivanreese/visual-programming-codex
I'll also take a moment to plug my Visual Programming Codex[1], which collects VPLs as though they're butterflies. I'm adding Flyde to the backlog of projects to document, but I'd also suggest looking around there for ideas. There are a ton of valuable new things you can do once you start visualizing programming, especially if you're visualizing the execution behaviour. I'd love to see you push this further.
[1] https://github.com/ivanreese/visual-programming-codex
Thanks! And yes, definately something I am considering exploring. It's right after auto-layout, and "zoom to view grouped nodes internals" (a-la https://xai-primer.com/tool/)
And I was planning to submit a PR for your codex soon! I've visited your codex dozens of times in the last couple of years. Big fan :)
And I was planning to submit a PR for your codex soon! I've visited your codex dozens of times in the last couple of years. Big fan :)
Nice! https://github.com/enso-org/enso is related as a modern visual lang.
Is Flyde entirely focused on TypeScript? Python would be a logical fit too.
Is Flyde entirely focused on TypeScript? Python would be a logical fit too.
Enso is super cool, been following their work since the time they were called luna :)
Flyde is TS to start with, but Python is the next candidate in language support. Eventually, the plan is to rewrite the core/runtime layer of Flyde to a more performant language (Rust/Go) and enable interoperability, so you could potentially even mix and match node implementations. One node could be built with Python, the other with JS, and the flow itself will be agnostic to it.
I like this, it’s lower-level than Scratch, with a focus on doing stuff more than making funny noises and animation.
I want to have a play with seeing how you can demonstrate composition. Do you suggest any good templates for this?
I want to have a play with seeing how you can demonstrate composition. Do you suggest any good templates for this?
Thanks, exactly what I aimed for (:
Regarding composition, anything you had in mind? I can draft a playground (https://play.flyde.dev/) example for you
I teach a code club to 8-10 year olds. They understand functions, and that the main script can call functions, and that functions can call other functions. Conceptually, they struggle with a function being assigned to a variable, passed in as an argument, or being returned from a function.
So far, demonstrating to them what's going on here and why this is useful has eluded me.
So far, demonstrating to them what's going on here and why this is useful has eluded me.
> they struggle with a function being assigned to a variable, passed in as an argument, or being returned from a function.
I've seen professional programmers struggle with that.
I've seen professional programmers struggle with that.
Author here. It's a valid point, I think once they start entering into Discord and want to build a Discord bot, Flyde might come in handy as an educational tool.
btw, your playground homepage has a date/time error. I see this in the DOM:
Modified <span data-tooltip-id="main-tooltip" data-tooltip-content="3/7/2024, 12:21:48 PM">-12537 seconds</span> ago</div>
You may want to use a timestamp instead of comparing local time.
Modified <span data-tooltip-id="main-tooltip" data-tooltip-content="3/7/2024, 12:21:48 PM">-12537 seconds</span> ago</div>
You may want to use a timestamp instead of comparing local time.
Thanks for reporting! Will check and fix this.
[deleted]
What I love about this sort of tool is that it appears to pair so perfectly with functional programming. Are all expressions constructed in this language referentially transparent?
Yes! As a big fan of functional-reactive programming, it was important to me that Flyde builds on that foundation, and doesn't fall into more imperative paradigms.
With that being said, Flyde does offer an easy way for node authors to set local and global state, but in a functional way - you can pass your own map as the global state, and do whatever you want with it. It's not properly documented yet, but here's the code - https://github.com/flydelabs/flyde/blob/main/core/src/execut...
With that being said, Flyde does offer an easy way for node authors to set local and global state, but in a functional way - you can pass your own map as the global state, and do whatever you want with it. It's not properly documented yet, but here's the code - https://github.com/flydelabs/flyde/blob/main/core/src/execut...
I don't think visual programming language can or should replace code in plaintext. I like the idea of visual programming at higher level. It can be very good at communicating data flow, business logic and processes. But each of the building blocks can still be implemented in programming languages today. I feel like AWS Step Function is very close to what I wanted. They also have a very nice builder UI.
Author here. Agree 100%. While Flyde allows you to group visual nodes together and create new ones with a "visual implementation", I foresee that code-based nodes will still be the majority.
This is interesting, we are building https://github.com/Multiwoven/multiwoven an open-source ReverseETL and workflow orchestration is a big part of our platform, maybe I ca experiment with small use-case like setting up backend tests using flows.
I was just thinking about something where I could design web based workflows that could use online services to perform transformations on items dragged into a dropped and perhaps the output would be downloadable.
Maybe this exists elsewhere, but is is free?. It is still a thought and I haven't dig deep to see what exists, but Flyde seems kind of close.
Maybe this exists elsewhere, but is is free?. It is still a thought and I haven't dig deep to see what exists, but Flyde seems kind of close.
Hey, author here.
Did you try tools like Make or Pipedream for this use-case? Curious about what was missing for you in them.
With Flyde you can do that, and one of the monetization strategies I have planned for Flyde is Trigg - https://www.trigg.dev, a "visual serverless" platform based on Flyde, that can run the work flows for you and expose them as APIs. And for "ejection" purposes, one could always download the flow and use the lower-level Flyde to run it self-hosted.
With Flyde you can do that, and one of the monetization strategies I have planned for Flyde is Trigg - https://www.trigg.dev, a "visual serverless" platform based on Flyde, that can run the work flows for you and expose them as APIs. And for "ejection" purposes, one could always download the flow and use the lower-level Flyde to run it self-hosted.
As someone who routinely uses Node-RED to develop surprisingly long-lasting "micro services" and workflows, I really like this, especially if it can be made to generate WASM or, even better, native code in the future (so that I could use the output in other things).
Very cool, thanks for sharing!
I first tried out something like this in the early 1990s at VPL Research - one of the originators of the VR industry. They had a visual programming language called Body Electric for controlling how things behaved in VR. Some details here: https://news.ycombinator.com/item?id=22788773
And more recently, Google showed PromptChainer for wiring together LLM calls and Javascript: https://www.cs.cmu.edu/~sherryw/assets/pubs/2022-promptchain...
I first tried out something like this in the early 1990s at VPL Research - one of the originators of the VR industry. They had a visual programming language called Body Electric for controlling how things behaved in VR. Some details here: https://news.ycombinator.com/item?id=22788773
And more recently, Google showed PromptChainer for wiring together LLM calls and Javascript: https://www.cs.cmu.edu/~sherryw/assets/pubs/2022-promptchain...
FWIW your VSCode Repository link <https://marketplace.visualstudio.com/items?itemName=flyde.fl...> is 404, it should be https://github.com/flydelabs/flyde-vscode but is https://github.com/flydehq/flyde-vscode
Thanks! Fixing
Wow, impressive! I also have to congratulate you on the landing page. So often I click on something that I think is interesting only to scroll down in confusion before I close the tab.
I'm definitely going to check this out.
I'm definitely going to check this out.
Thanks! this means a lot, as I've been through many iterations with this one. Each affected some other revelation in my journey with Flyde.
PS: Here's an older one - https://web.archive.org/web/20230313081811/https://www.flyde...
PS: Here's an older one - https://web.archive.org/web/20230313081811/https://www.flyde...
Looks cool, shades of Prograph, that's a good thing!
https://en.m.wikipedia.org/wiki/Prograph
https://en.m.wikipedia.org/wiki/Prograph
I always wanted to love ProGraph - I played with it back in the pre-OSX Mac days. But I found it's very hard to "read" ProGraph code, which it would seem is the thing that visual languages are supposed to enable. It could be that my brain had already been shaped into text based programming for too long to adapt.
That said, I did create a visual toy language demo a few years back for the fun of it. It's kinda like a visual Lisp, or maybe upside-down ProGraph: https://github.com/mypalmike/skastic
That said, I did create a visual toy language demo a few years back for the fun of it. It's kinda like a visual Lisp, or maybe upside-down ProGraph: https://github.com/mypalmike/skastic
Thanks!
> Flyde is designed to complement and enhance traditional textual coding, not to replace it. It includes a VSCode extension, it seamlessly integrates with existing TypeScript/JavaScript code and can run on Node.js and in the browser.
And with this you're already leaps and bounds better than the god forsaken azure logic app. Congratulations on shipping!
And with this you're already leaps and bounds better than the god forsaken azure logic app. Congratulations on shipping!
This looks great. I have played with litegraph.js before for fun (image generation via api). Creating custom nodes in that one was tiring.
- Can we make custom nodes in this (e.g. a node which to display images)?
- Can it be used like a client side js library (like litegraph)? or does it have to be used in IDE and its more like an IDE enhancement?
Looking back at the page and examples again, is it not the usecase this is for?
- Can we make custom nodes in this (e.g. a node which to display images)?
- Can it be used like a client side js library (like litegraph)? or does it have to be used in IDE and its more like an IDE enhancement?
Looking back at the page and examples again, is it not the usecase this is for?
Thank you!
1. Nodes with custom logic, structure (inputs/outputs etc) and custom configuration editing are definitely possible.
But I assume you mean custom nodes as in nodes that render the data passing through them, like in litegraph.js, right?
If so, it's not possible, as IMO it's less of a value for "production" use-cases/application level layer. But if the community's interest will slide in that direction, I will consider going that route.
2. It can be used as a library, either Node.js (via an npm package) or the browser (using a custom webpack loader)
If so, it's not possible, as IMO it's less of a value for "production" use-cases/application level layer. But if the community's interest will slide in that direction, I will consider going that route.
2. It can be used as a library, either Node.js (via an npm package) or the browser (using a custom webpack loader)
Eh, I guess slapping some literal, variable, and operation nodes together makes it visual, but I don't think it makes it easier.
Contrast with something like Scratch which is useful because it helps prevent typos, clearly presents expected arguments, and creates snap connected chains of logic.
Even better, contrast something like Drakon which offers visual abstractions such as skewers, happy paths, silhuettes, common fate, etc.
I really like the concept of visual abstractions. Nodes are abstractions but I don't think they are high enough level to improve over text. And I think text will always be awesome even if it is assisted by better ways to animate and visualize logic and systems.
Also, can I grep over Flyde? I'd hate to lose that basic ability.
Drakon: https://drakonhub.com/en/drakon
Contrast with something like Scratch which is useful because it helps prevent typos, clearly presents expected arguments, and creates snap connected chains of logic.
Even better, contrast something like Drakon which offers visual abstractions such as skewers, happy paths, silhuettes, common fate, etc.
I really like the concept of visual abstractions. Nodes are abstractions but I don't think they are high enough level to improve over text. And I think text will always be awesome even if it is assisted by better ways to animate and visualize logic and systems.
Also, can I grep over Flyde? I'd hate to lose that basic ability.
Drakon: https://drakonhub.com/en/drakon
This is something I ponder about a lot.
For those proficient in writing textual programs, a tool such as Flyde as-is might provide value by enforcing modules to be stand-alone and well-defined; the premise of https://en.wikipedia.org/wiki/Flow-based_programming as a paradigm that promised value even without using a visual editor, and just by adhering to the concept.
But for those who lack the understanding of coding syntax and grammar, a visual tool, even in a not-much-higher level of attraction, could make all the difference. I've personally mentored dozens of entry-level developers many struggled with concurrency and asynchronicity. (callbacks, promises, etc). these are concepts that become a no-brainer using a nodes-and-wires editor.
Regarding prepping - fair point. I'm sure it's not what you meant, but here's a grep in a Flyde flow (the second example) - https://imgur.com/a/V9u1ETl
For those proficient in writing textual programs, a tool such as Flyde as-is might provide value by enforcing modules to be stand-alone and well-defined; the premise of https://en.wikipedia.org/wiki/Flow-based_programming as a paradigm that promised value even without using a visual editor, and just by adhering to the concept.
But for those who lack the understanding of coding syntax and grammar, a visual tool, even in a not-much-higher level of attraction, could make all the difference. I've personally mentored dozens of entry-level developers many struggled with concurrency and asynchronicity. (callbacks, promises, etc). these are concepts that become a no-brainer using a nodes-and-wires editor.
Regarding prepping - fair point. I'm sure it's not what you meant, but here's a grep in a Flyde flow (the second example) - https://imgur.com/a/V9u1ETl
Thank you for your reply. I'm usually skeptical of visual paradigms but I'm not trying to be critical.
Looking at flow-based programming, it looks like it could help in visualizing and understanding asynchronous systems that wouldn't be so intuitive from a code listing. In that way, I suppose it would force a functional style as well. So maybe good for gluing those parts of one's apps together.
I did look at the code examples; attributes and code wrapped in json. Obviously greppable, but then if one expected a learner to grep, version diff, author tests?, linting?, etc. they still must dip into and learn regular dev tools. I don't know if Flyde is supposed to eventually subsume that other functionality or if it is a higher scripting layer used in conjunction, and so must eventually be learned anyway.
Or is Flyde just trying to introduce an easier coding path in order to bypass the more superfluous parts of software dev such as tabs vs spaces, editor choice, oop vs functional vs procedural vs whatever.
Looking at flow-based programming, it looks like it could help in visualizing and understanding asynchronous systems that wouldn't be so intuitive from a code listing. In that way, I suppose it would force a functional style as well. So maybe good for gluing those parts of one's apps together.
I did look at the code examples; attributes and code wrapped in json. Obviously greppable, but then if one expected a learner to grep, version diff, author tests?, linting?, etc. they still must dip into and learn regular dev tools. I don't know if Flyde is supposed to eventually subsume that other functionality or if it is a higher scripting layer used in conjunction, and so must eventually be learned anyway.
Or is Flyde just trying to introduce an easier coding path in order to bypass the more superfluous parts of software dev such as tabs vs spaces, editor choice, oop vs functional vs procedural vs whatever.
Interesting take on "visual abstraction" vs "visual representation" (if I may add the wording), where Drakon represents the former and Flyde the latter.
I'm uncertain to what extent visual _representations_ of real code has anything to offer developers as a target group. I think it's the strive to have FBP represent already human-friendly code that gets in our way of thinking.
At the end of the day I want to define and execute logic without having to approach parallelism and asynchronicity as programming concepts. Instead the paradigm should transform such challenges into spatial ones. Instead the paradigm should transform such challenges into spatial ones. (Yes I wrote that twice for effect.)
I have yet to see such a system, but Drakon comes close.
I'm uncertain to what extent visual _representations_ of real code has anything to offer developers as a target group. I think it's the strive to have FBP represent already human-friendly code that gets in our way of thinking.
At the end of the day I want to define and execute logic without having to approach parallelism and asynchronicity as programming concepts. Instead the paradigm should transform such challenges into spatial ones. Instead the paradigm should transform such challenges into spatial ones. (Yes I wrote that twice for effect.)
I have yet to see such a system, but Drakon comes close.
I like the "visual abstraction" vs "visual representation" distinction, and agree with your point that Flyde falls into the latter.
Regarding parallelism and asynchronicity, Flyde manages to answer that need. You simply connect 2 nodes in parallel - for example - https://imgur.com/a/GJewFHd this fetches data from 2 apis, maps them and collects them into a new object. It's low-level for sure, but parallelism and asynchronicity are completely spatial. Do you mean it in a different way?
Regarding parallelism and asynchronicity, Flyde manages to answer that need. You simply connect 2 nodes in parallel - for example - https://imgur.com/a/GJewFHd this fetches data from 2 apis, maps them and collects them into a new object. It's low-level for sure, but parallelism and asynchronicity are completely spatial. Do you mean it in a different way?
That way, yes. I mean a transformation into spatial problems in much the hardware design way, e.g. the "I need to find a way to add that node without crossing any wires" way. Your example is surely elegant for Promise.all(), although it's a happy path. Can users manage rejected promises, Promise.any() or Promise.allSettled() through nodes and wiring (i.e. not through hidden configuration)?
I think so, yes.
A rejected promise is equivalent to a node that throws an error. Flyde exposes a default "error" output pin for each node. As everything in Flyde is async, any error thrown can be viewed as a rejected promise.
Promise.any can be achieved with 3 promises and a throttle node
Promise.allSettled translated to connecting the error output pin and hooking it to whatever you wanted the fulfilled value to go.
There's a project I keep wanting to start that involves a visual programming language and the JVM. Java supporting JS natively through Nashorn, is Flyde capable of doing this? Others I looked at like Node-RED seemed to have Node.js as a hard requirement, but Flyde supporting the browser environment makes me wonder if it can support this too.
This looks very cool!
I have just a couple of wishes on top of this:
- I wish the file format were JSON-based instead of YAML-based. Then you could import .flyde files with standard `{type: 'json'}` import attributes and not need fetch or a webpack loader.
- I wish the editor were distributed as web components so taht they could be easily embedded into any framework.
I have just a couple of wishes on top of this:
- I wish the file format were JSON-based instead of YAML-based. Then you could import .flyde files with standard `{type: 'json'}` import attributes and not need fetch or a webpack loader.
- I wish the editor were distributed as web components so taht they could be easily embedded into any framework.
Thanks!
I plan to move it to JSON sometime in the future, but it won't remove the need for a webpack loader, at least not the way it is built now. The webpack loader exists to resolve dependencies. If your flow depends on Node1 from @flyde/stdlib and Node2 from @spankalee/flyde-nodes, "something" needs to resolve the code for these nodes.
A possible way around this is to bundle/compile a flow and its dependencies using tooling on Flyde's end, but that's just shifting what the loader does to another end of the pipeline :)
Regarding shipping in a web component - you could always wrap https://www.npmjs.com/package/@flyde/flow-editorin a standalone renderer. It's cumbersome and adds many extra KBs, but doable.
Appreciate the feedback!
I plan to move it to JSON sometime in the future, but it won't remove the need for a webpack loader, at least not the way it is built now. The webpack loader exists to resolve dependencies. If your flow depends on Node1 from @flyde/stdlib and Node2 from @spankalee/flyde-nodes, "something" needs to resolve the code for these nodes.
A possible way around this is to bundle/compile a flow and its dependencies using tooling on Flyde's end, but that's just shifting what the loader does to another end of the pipeline :)
Regarding shipping in a web component - you could always wrap https://www.npmjs.com/package/@flyde/flow-editorin a standalone renderer. It's cumbersome and adds many extra KBs, but doable.
Appreciate the feedback!
For me (Firefox; Linux; X11) right-clicking on the background when editing a visual flow causes to a menu to appear then disappear almost instantly. Everything else seems to work (clicking run, adding nodes from the menu, right-clicking on nodes and editing them that way). Does anyone else have this problem?
Does it sync bi-directionally from code to flow visual representation and back? Because that seems pretty useful to mass adoption. I notice you said "Flyde is designed to complement and enhance traditional textual coding, not to replace it."
Bi-directional sync would help a lot with that idea.
It's a question I get many times and while the point makes sense, I think that the value of translating a piece of code as-is to Flyde isn't that high. The resulting visual representation will resemble the AST of the transformed code and be less of a value. It's like converting assembly to C and vice-versa. It might be useful, but data will be lost and a 1 to 1 conversion doesn't really exist.
On the other hand, you can easily take a single piece of your code, say a business logic of a controller in an MVC-based web service, and transform it into a Flyde flow and call it from the original controller.
With that being said, I have no doubt that for Flyde to be truly mass-adopted I have to invest more in easier onboarding and safer ejection.
On the other hand, you can easily take a single piece of your code, say a business logic of a controller in an MVC-based web service, and transform it into a Flyde flow and call it from the original controller.
With that being said, I have no doubt that for Flyde to be truly mass-adopted I have to invest more in easier onboarding and safer ejection.
Sometimes I'd be happy to just be able to give key functions in my code a 2D position in a zoomable map to aid code navigation. Maybe even just the title of the object could be helpful.
How does this compare with Pure Data?
Author here. The main difference is the target use case. I'm far from being a Pure Data expert, but it seems more aimed towards music/media generation.
Flyde on the other hand is aimed to be used in the application layer of modern web development.
Flyde on the other hand is aimed to be used in the application layer of modern web development.
The model seems quite similar to a subset PD, with only object and message boxes. Objects can have only a single output port. (edit: I was mistaken, they can have multiple ports, though as far as I can tell there's no port-sequencing rules a la PD). Objects don't seem to be addressable: the only messages that can be sent are via the visible connections.
The type system seems to be directly leveraging the host JS type system, but the docs seem a bit sparse on that.
The documentation on control flow is empty, so it's not clear what the model there is precisely, but it apprears that the entire system is message-based, given the way the Hello, World is written: "output hello, wait a bit, output world".
The documentation suggests that what's novel about Flyde is the integration with other codebases, but it's JS/TS so it requires that whole enviroment. PureData is embeddable in any C application, so any language with C FFI can integrate.
The type system seems to be directly leveraging the host JS type system, but the docs seem a bit sparse on that.
The documentation on control flow is empty, so it's not clear what the model there is precisely, but it apprears that the entire system is message-based, given the way the Hello, World is written: "output hello, wait a bit, output world".
The documentation suggests that what's novel about Flyde is the integration with other codebases, but it's JS/TS so it requires that whole enviroment. PureData is embeddable in any C application, so any language with C FFI can integrate.
Looks interesting! However, the tutorials link on the website footer 404s for me.
Oh, snap! Deploying a fix now.
Forgot to remove that after a docs rehaul. Tutorials still need to be re-written after some major changes, but perhaps this old blog post can give a sense - https://medium.com/@gabrielgrinberg/visual-programming-in-vs...
Forgot to remove that after a docs rehaul. Tutorials still need to be re-written after some major changes, but perhaps this old blog post can give a sense - https://medium.com/@gabrielgrinberg/visual-programming-in-vs...
I have yet to find a language/ide with good discoverability. Does the visual metaphor enable the blocks/objects/functions to tell you what they do and how to use them?
Author here.
Not really. I mean, there are tooltips and icons, but not in the sense that you'll be able to grasp what it does just by taking a look at its structure.
This is good to teach programming.
I have used IBM Cognos before and may be biased, for complex logic text programming will be better than visual programming.
The playground button on the front page https://www.flyde.dev/ links to localhost:3030
Oh damn! thanks for reporting! Fix going live now
Please try a different example (it changes the link based on the example on the right side).
Looks great! Is it capable of doing real-time editing? For example hooking it up next to a canvas element and having the nodes change the colors or shader uniforms.
As a visual person (traditionally trained as a graphic artist), I've wanted this sort of thing for a long while, and I've been trying to use it for 3D.
Surprisingly, there are multiple specialized tools for this:
- https://www.blockscad3d.com --- an adaptation of Google's Blockly to OpenSCAD
- https://github.com/derkork/openscad-graph-editor --- wires and nodes, it has the advantage of exposing _all_ of OpenSCAD's commands (the above has a subset)
- https://github.com/Tanneguydv/Pythonocc-nodes-for-Ryven --- a module for using PythonOCC in Ryven --- when I finally succeeded, I found the language inscrutable, even when provided w/ quite nice examples (definitely a failing on my part, not that of the tool)
- https://github.com/graphscad/graphscad --- it took a long while for the source code for this to be made available, and for a while it had compatibility problems (why was "cube" redefined?) --- probably defunct for political reasons, it had some interesting ideas, in particular the ability to have custom icons for modules
- https://www.nodebox.net --- if memory serves I got hung up by not easily being able to do 3D, and when doing 2D having precision problems (or maybe that was Processing.org)
and I've been using these tools to make various things:
https://willadams.gitbook.io/design-into-3d/3d-project
(and maybe eventually I'll finish something)
The problem I've been running into is there doesn't seem to be an answer to the question:
"What does an algorithm look like?"
I recently had occasion to mention Herman Hesse's _The Glass Bead Game_ (also published as _Magister Ludi_) and I'll bring it up again --- what is a meaningful graphical representation of a program?
The Drakon folks argued that there should be one true path but that's not really communicative and I would note that if this was a simple thing it wouldn't be decades since I last saw a physical Flowcharting Template:
https://americanhistory.si.edu/collections/object-groups/flo...
(and it's pretty rare to even see a well-done electronic drawing of a flowchart since Visio made its splash and vanished into the bowels of Microsoft)
The main problem seems to be one of expressiveness not scaling up well, hence:
https://blueprintsfromhell.tumblr.com/
https://scriptsofanotherdimension.tumblr.com/
Presumably, one doesn't want to define modules/variables unnecessarily --- but the question becomes where is that dividing line?
If you define too many, then you're back to the "wall of text" which one was trying to avoid (but wrapped up in nice boxes with some lines or shapes), and if one doesn't use them (well, look at the pretty/awful images in the links above).
Ideally, a well-coded visual program would have a pleasing aesthetic appearance which is expressive and communicates flow and function, and I've tried for that at:
https://willadams.gitbook.io/design-into-3d/programming
(though I wish that there was an easy way to export an SVG version of a program)
I believe that what is needed here is some graphical equivalent to Literate Programming: http://literateprogramming.com
Is there a nice tutorial for GUI toolkit integration which would allow easily making a graphical application with this? I have an idea I want to try it which might be a good fit.
Surprisingly, there are multiple specialized tools for this:
- https://www.blockscad3d.com --- an adaptation of Google's Blockly to OpenSCAD
- https://github.com/derkork/openscad-graph-editor --- wires and nodes, it has the advantage of exposing _all_ of OpenSCAD's commands (the above has a subset)
- https://github.com/Tanneguydv/Pythonocc-nodes-for-Ryven --- a module for using PythonOCC in Ryven --- when I finally succeeded, I found the language inscrutable, even when provided w/ quite nice examples (definitely a failing on my part, not that of the tool)
- https://github.com/graphscad/graphscad --- it took a long while for the source code for this to be made available, and for a while it had compatibility problems (why was "cube" redefined?) --- probably defunct for political reasons, it had some interesting ideas, in particular the ability to have custom icons for modules
- https://www.nodebox.net --- if memory serves I got hung up by not easily being able to do 3D, and when doing 2D having precision problems (or maybe that was Processing.org)
and I've been using these tools to make various things:
https://willadams.gitbook.io/design-into-3d/3d-project
(and maybe eventually I'll finish something)
The problem I've been running into is there doesn't seem to be an answer to the question:
"What does an algorithm look like?"
I recently had occasion to mention Herman Hesse's _The Glass Bead Game_ (also published as _Magister Ludi_) and I'll bring it up again --- what is a meaningful graphical representation of a program?
The Drakon folks argued that there should be one true path but that's not really communicative and I would note that if this was a simple thing it wouldn't be decades since I last saw a physical Flowcharting Template:
https://americanhistory.si.edu/collections/object-groups/flo...
(and it's pretty rare to even see a well-done electronic drawing of a flowchart since Visio made its splash and vanished into the bowels of Microsoft)
The main problem seems to be one of expressiveness not scaling up well, hence:
https://blueprintsfromhell.tumblr.com/
https://scriptsofanotherdimension.tumblr.com/
Presumably, one doesn't want to define modules/variables unnecessarily --- but the question becomes where is that dividing line?
If you define too many, then you're back to the "wall of text" which one was trying to avoid (but wrapped up in nice boxes with some lines or shapes), and if one doesn't use them (well, look at the pretty/awful images in the links above).
Ideally, a well-coded visual program would have a pleasing aesthetic appearance which is expressive and communicates flow and function, and I've tried for that at:
https://willadams.gitbook.io/design-into-3d/programming
(though I wish that there was an easy way to export an SVG version of a program)
I believe that what is needed here is some graphical equivalent to Literate Programming: http://literateprogramming.com
Is there a nice tutorial for GUI toolkit integration which would allow easily making a graphical application with this? I have an idea I want to try it which might be a good fit.
Kinda reminded me of Pure Data or MaxsP.
Did you just reinvent Node-RED?
Valid point. Node-RED is a successful and popular tool and has a great ecosystem, especially around automation and IoT.
NodeRED is a standalone tool than a "language", and although it's possible, using it to integrate with (and from) existing code is not trivial.
Flyde on the other hand, takes more of a "library" stance. It is agnostic to the code running it and can be easily embedded into other codebases.
NodeRED is a standalone tool than a "language", and although it's possible, using it to integrate with (and from) existing code is not trivial.
Flyde on the other hand, takes more of a "library" stance. It is agnostic to the code running it and can be easily embedded into other codebases.
Quick feedback: put a screenshot (or even better: a gig/video) on the readme!
There should be one :o
Perhaps it took time to load on your end?
You're right, I'm on a really slow connection today, and you didn't put any alt text ;).
Caught me there! Fixing :)
I have a use case that I tried to build something for. I am about ten iterations in, and the one I still use is an excel file, alas. I am al domain expert and not a programmer, and I just can't wrap my head around how to build it. My MVPs are below minimum, and what I want is out of reach of my capabilities.
I am a mechanical engineer and a big part of my job is simple high school level math. A lot of these calculations are repeated, but differ ever so slightly, that you end up with tens or hundreds excel files or python scripts.
What I would like to have is something that looks like UE blueprints (only know them from screenshots) where each box takes a couple inputs and gives probably just one output. I want these box to be composed of boxes itself, potentially ad infinitum. This is where my brain can't fathom how to build something like that.
I've build this with python functions, you can reuse them, put them in each other. But it becomes hard to maintain spaghetti. I would like the visual program to constrain the spaghetti, and to make it easy for my less programmer inclined colleagues to reuse my boxes, expand my boxes, add their own, in a visual environment.
There would be a box calculating the capacity of a bearing ball. This would be inside the box for a whole bearing. The bearing together with a bending shaft would be a bigger box, etc. Most of it would be a tree structure, but I don't think you can fit the whole thing in a tree, some more general linked nodes would leak out. I even build something with Flask, but my head is losing it when I tried reusable boxes, and when my tree structure needed to become more general, it was quite a big hit and I lost momentum.
We have visual software for very complicated finite element calculations, but none for the simple "import math" calculations.
The potential is huge. Many mechanical engineering work is still done in excel, and it's just impossible to scale or reuse old work. The industry does not see this as a problem because it hampers everyone equally. Only very specialised calculations are elevated and usually end up being a specialised company, or a dedicated (GUI) software package.
Imagine you are a programmer but there is no standard library, and no way to import code. You have to write, or copy paste, everything from scratch. All. The. Time.
Either I'm a dumb guy who just doesn't get it, and the industry is doing fine, or I have a hunch that could create a product that would serve a world wide, cross industry market.
Is this something you could do with Flyde?
I am a mechanical engineer and a big part of my job is simple high school level math. A lot of these calculations are repeated, but differ ever so slightly, that you end up with tens or hundreds excel files or python scripts.
What I would like to have is something that looks like UE blueprints (only know them from screenshots) where each box takes a couple inputs and gives probably just one output. I want these box to be composed of boxes itself, potentially ad infinitum. This is where my brain can't fathom how to build something like that.
I've build this with python functions, you can reuse them, put them in each other. But it becomes hard to maintain spaghetti. I would like the visual program to constrain the spaghetti, and to make it easy for my less programmer inclined colleagues to reuse my boxes, expand my boxes, add their own, in a visual environment.
There would be a box calculating the capacity of a bearing ball. This would be inside the box for a whole bearing. The bearing together with a bending shaft would be a bigger box, etc. Most of it would be a tree structure, but I don't think you can fit the whole thing in a tree, some more general linked nodes would leak out. I even build something with Flask, but my head is losing it when I tried reusable boxes, and when my tree structure needed to become more general, it was quite a big hit and I lost momentum.
We have visual software for very complicated finite element calculations, but none for the simple "import math" calculations.
The potential is huge. Many mechanical engineering work is still done in excel, and it's just impossible to scale or reuse old work. The industry does not see this as a problem because it hampers everyone equally. Only very specialised calculations are elevated and usually end up being a specialised company, or a dedicated (GUI) software package.
Imagine you are a programmer but there is no standard library, and no way to import code. You have to write, or copy paste, everything from scratch. All. The. Time.
Either I'm a dumb guy who just doesn't get it, and the industry is doing fine, or I have a hunch that could create a product that would serve a world wide, cross industry market.
Is this something you could do with Flyde?
[off-topic] I used to follow another visual language a while ago. It seems that it is still alive.
Tersus Studio:
http://www.tersus.com/#Id=178
[may be some good things to take there, as an inspiration]
Tersus Studio:
http://www.tersus.com/#Id=178
[may be some good things to take there, as an inspiration]
I'm so immersed in this space that it's rare to find a related project I haven't heard of before. Thanks! Looks interesting.
[deleted]
In my last role as an engineering manager for a B2B-oriented product, I authored and reviewed many diagrams for backend applications, mostly for integrations between 2 third-party services. Some of these diagrams were elaborate enough that I started dreaming of a way to simply run a diagram as is; I imagined a “run” button on the top-right corner of the screen that would execute the diagram without the need to translate it into code.
That led me down a rabbit hole of exploration and experimentation, from tools like Zapier, Pipedream and Make, which are great for automating “backoffice” stuff, and up to NodeRED, NoFlo.js and the great work of J. Paul Morisson on Flow-Based Programming. I failed to find a tool that would answer my needs - a tool that balances a new level of abstraction, manages to stay powerful and flexible, and most importantly, integrates with the existing ecosystem, and doesn’t replace it. I built Flyde as an attempt to answer that need.
Flyde is designed to complement and enhance traditional textual coding, not to replace it. It includes a VSCode extension, it seamlessly integrates with existing TypeScript/JavaScript code and can run on Node.js and in the browser.
I believe that as we delegate more coding tasks to AI, we’ll assume the role of an architect rather than a programmer. This shift will require tools that focus more on orchestration and high-level troubleshooting and less on low-level functionality.
I’d love to hear your thoughts and feedback on Flyde’s direction!