Some more details:

To take a little step back, I want to illustrate the differences between what you see here in comparison to the flows that I’ve shown in other videos on this channel. The thing that they are sharing is the editor, which is a react component I build. But the way the flows are running, is totally different. 

The earlier flows are interpreted and event handlers are created based on the nodes in the flow. An event handler calls the node-tasks when it receives an event. The connections represent the events. When a node-tasks is done, it calls its output events.

The node-tasks can contain quite some code themselves and from flow perspective they are much more high level. 

But the flow that you see in this video contains much smaller blocks which get compiled to webassembly in real-time in the browser using javascript when you add or change nodes.

It somehow made more sense to layout this flow from top to bottom instead of left to right.

I’ve color coded some blocks to help understand what is going on:

the blue node is the start point

yellow nodes are function definitions or the calling of a function

orange nodes are subflow definitions and the inserting points for a subflow

This flow contains two while loops for the x and y of the canvas so that we can calculate the color for each pixel. The inspiration for this was the tixyland demo from last year. So the flow also has a time parameter that is handled internally by the component that calls the compiled webassembly code from within a requestAnimationFrame.

There are some helper variables which define 3 points and for each pixel the distance is calculated to these points. These 3 points are moving using a sine calculation. The sine function is actually the only javascript function that is called from within the webassembly code because webassembly has no sine function itself and my knowledge is too little to implement it in webassembly myself.

In the future I hope to extend this flow to webassembly compiler to make it Turing complete and I also hope to add some features so that it can be used in more business line of applications and combine it with the other flow solution.

In the editor I’ve added a feature so that I can move through a flow automatically while recording a video. I’ve tried to make it a smooth as possible but I am running into limitations of the browser or my programming capabilities. The problem is probably that it’s a hybrid model that uses both canvas and html for showing a flow. So, I am still thinking of doing a big rewrite using webgl and webassembly. If anybody has some suggestions on how to improve the performance then please let me know.

This is the whole flow as an image, it was made manually using a lot of separate images and stiched together in photoshop since I can't easily export it as one readable image because of the hybrid model... although the readibility of this image can also be improved😅

So cool, thanks a lot for sharing and taking time to record video!

I loved the feature to move through the flow while recording, but the acceleration from node to node is a bit fast for me. I'm afraid I got a little dizzy in some parts!

Thanks for the feedback about the acceleration, in future video's I'll take that into account or maybe make the project available to play with it yourselves so you are more in control