As the readers of this blog know, I’ve been working on a Flow-Based Programming implementation for JavaScript in the form of the NoFlo project. The idea of FBP in nutshell is to separate the control flow of software from the actual implementation. Developers build reusable “black box” components that are then connected with each other through a graph that you can define either visually or textually.

FBP has been around for quite a while, having been invented by J. Paul Morrison in the 60s, but is now becoming more and more relevant thanks to the need for talking to multiple asynchronous APIs and different devices. While NoFlo has been stable enough for production use for about two years now, we ran a successful Kickstarter earlier this fall to push the development tools to a new level.

I attended the FSCONS conference last weekend, and gave a NoFlo talk. Since quite a few GNOME regulars were there as well, we ended up chatting about how NoFlo and FBP could be utilized in the desktop environment. I’m writing this to Planet GNOME to introduce some of those ideas.

The video from my talk isn’t online yet, but you can watch a video from the talk I gave at c-base couple of months ago:

NoFlo on gjs

An interesting development that happened this fall was that NoFlo was ported to the gjs JavaScript engine by Lionel Landwerlin. This allows us to take the ideas of Flow-Based Programming and connect them with the desktop. GNOME is an excellent candidate for this, given that JavaScript is a first-class citizen on the development platform, meaning that with the right set of components your FBP programs could integrate with all the relevant parts of the GNOME ecosystem.

Lionel posted a screencast of window management with Clutter coordinated by NoFlo:

This is of course only the first steps, but shows a little bit of the potential. While NoFlo’s low overhead could mean making actual GNOME applications with it, the initial sweet spot for the integration would be:

Having a fast UI prototyping tool in GNOME, a bit like how Quartz Composer is used on the Apple platforms

Allowing users to automate parts of their desktop workflow through simple FBP programs

Vinod Khosla summarized the significance of this quite well:

An author can write a book, a musician a song, a painter a painting. Most UI designers cannot realize their creation

Zeeshan also wrote about similar ideas for GNOME in his Pentu project proposal two years ago.

Bringing the GNOME platform to NoFlo

The big part of enabling flow-based GNOME development would be to provide NoFlo components for the various APIs in the GNOME ecosystem. This could be done manually, but quite possibly we could automate at least parts of the process by some smart GObject Introspection hacking.

This would be quite similar to how we integrated the Polymer Web Components with NoFlo.

As I’m currently quite busy on the NoFlo Development Environment, I won’t be able to do this personally. But this sort of work would be the perfect fit for something like OPW or GSoC. I’d be happy to mentor that effort.

The NoFlo Development Environment

We’re building a quite nice graphical editor and debugger for flow-based programs. You can see the current state in a UI walkthrough I posted last month.

The NoFlo UI is a web application that could be brought to the desktop by running it inside a webview. To control the NoFlo runtime inside gjs we would also need a GNOME library for dealing with WebSockets, as that is the way we talk with non-browser runtimes like Node.js or the microflo environment for Arduino programming.

By supporting the NoFlo network protocol on gjs we could easily start, stop, modify, and monitor FBP programs running inside GNOME.

In the long run it would also be possible to build a native flow-based editor as well. After all, since the data model and runtime interactions are standardized, there is no reason why multiple different tools couldn’t interact with the same NoFlo graphs.

To find out more about NoFlo, visit the website, read the code on GitHub, or read the various press stories that appeared during the Kickstarter.

While I’m currently working outside of the desktop context, having been around GNOME since early 2000s I’m still following the project with interest. Having NoFlo there would be a great way to revitalize this connection.