3 ms·

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

- 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/ 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!

catapart 3y ago
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]).
- o-o- 3y ago
  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.
Herobrine2084 3y ago
Hey, author of https://luna-park.app 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 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!
- gabigrin 3y ago
  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.

catapart 3y ago

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

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

Herobrine2084 3y ago

Hey, author of https://luna-park.app 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 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!

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