3 ms·

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

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?

gabigrin 3y ago
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-4e2a69d0fddb 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/ 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 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.
- ilaksh 3y ago
  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.
  - gabigrin 3y ago
    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.

gabigrin 3y ago

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-4e2a69d0fddb 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/ 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 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.

ilaksh 3y ago
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.
- gabigrin 3y ago
  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.