Show HN: Flyde – an open-source visual programming language (github.com)
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!
128 comments
[ 3.1 ms ] story [ 270 ms ] thread- 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!
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]).
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.
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!
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!
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 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).
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.
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.
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.
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?
“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.
https://github.com/nebogeo/scheme-bricks
https://successfulsoftware.net/2024/01/16/visual-vs-text-bas...
It agrees with quite a few of the points you make above.
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.
- 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.
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”
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 :)
[1] Rethinking Visual Programming with Go - https://divan.dev/posts/visual_programming_go/
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)
I want to have a play with seeing how you can demonstrate composition. Do you suggest any good templates for this?
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.
So far, demonstrating to them what's going on here and why this is useful has eluded me.
I've seen professional programmers struggle with that.
Flyde on the other hand is aimed to be used in the application layer of modern web development.
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.
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!
``` 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
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...
https://en.m.wikipedia.org/wiki/Prograph
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
I'm definitely going to check this out.
PS: Here's an older one - https://web.archive.org/web/20230313081811/https://www.flyde...
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'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?
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.
Is your project really better than NodeRED? I mean it does have over 4000 community contributed nodes.
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-i...
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.
Is Flyde entirely focused on TypeScript? Python would be a logical fit too.
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...
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 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.
GraphSCAD addressed that by allowing functions to have custom icons.
I'd really like to see that become more prevalent.
Imagine you had features like zooming, being able to click on nodes to expand them, tabs, ctrl+f/keyboard navigation, etc.
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.
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.
- 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?
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)
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
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
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.
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.
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?
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.
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 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!
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!