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.
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.
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.