Henri Bergius - Javascript

Flow-Based Programming, a way for AI and humans to develop together

henri.bergius@iki.fi (Henri Bergius) — Mon, 20 Mar 2023 00:00:00 +0000

I think by now everybody reading this will have seen how the new generation of Large Language Models like ChatGPT are able to produce somewhat useful code. Like any advance in software development—from IDEs to high-level languages—this has generated some discussion on the future employment prospects in our field.

This made me think about how these new tools could fit the world of Flow-Based Programming, a software development technique I’ve been involved with for quite a while. In Flow-Based Programming these is a very strict boundary between reusable “library code” (called Components) and the “application logic” (called the Graph).

Here’s what the late J. Paul Morrison wrote on the subject in his seminal work, Flow-Based Programming: A New Approach to Application Development (2010):

Just as in the preparation and consumption of food there are the two roles of cook and diner, in FBP application development there are two distinct roles: the component builder and the component user or application designer.

…The application designer builds applications using already existing components, or where satisfactory ones do not exist s/he will specify a new component, and then see about getting it built.

Remembering that passage made me wonder, could I get one of the LLMs to produce useful NoFlo components? Armed with New Bing, I set out to explore.

The first attempt was specifying a pretty simple component:

That actually looks quite reasonable! I also tried asking New Bing to make the component less verbose, as well as generating TypeScript and CoffeeScript variants of the same. All seemed to produce workable things! Sure, there might be some tidying to do, but this could remove a lot of the tedium of component creation.

In addition to this trivial math component I was able to generate some that to call external REST APIs etc. Bing was even able to switch between HTTP libraries as requested.

What was even cooler was that it actually suggested to ask it how to test the component. Doing as I was told, the result was quite astonishing:

That’s fbp-spec! The declarative testing tool we came up with! Definitely the nicest way to test NoFlo (or any other FBP framework) components.

Based on my results, you’ll definitely want to check the generated components and tests before running them. But what you get out is not bad at all.

I of course also tried to get Bing to produce NoFlo graphs for me. This is where it stumbled quite a bit. Interestingly the results were better in the fbp language than in the JSON graph format. But maybe that even more enforces that the sweet spot would be AI writing components and a human creating the graphs that run those.

As I’m not working at the moment, I don’t have a current use case for this way of collaborating. But I believe this could be a huge productivity booster for any (and especially Flow-Based) application development, and expect to try it in whatever my next gig ends up being.

Illustrations: MidJourney, from prompt Robot software developer working with a software architect. Floating flowcharts in the background

asComponent: turn any JavaScript function into a NoFlo component

henri.bergius@iki.fi (Henri Bergius) — Fri, 23 Feb 2018 00:00:00 +0000

Version 1.1 of NoFlo shipped this week with a new convenient way to write components. With the noflo.asComponent helper you can turn any JavaScript function into a well-behaved NoFlo component with minimal boilerplate.

Usage of noflo.asComponent is quite simple:

const noflo = require('noflo');
exports.getComponent = () => noflo.asComponent(Math.random);

In this case we have a function that doesn’t take arguments. We detect this, and produce a component with a single “bang” port for invoking the function:

You can also amend the component with helpful information like a textual description and and icon:

const noflo = require('noflo');
exports.getComponent = () => noflo.asComponent(Math.random, {
  description: 'Generate a random number',
  icon: 'random',
});

Multiple inputs

The example above was with a function that does not take any arguments. With functions that accept arguments, each of them becomes an input port.

const noflo = require('noflo');

function findItemsWithId(items, id) {
  return items.filter((item) => item.id === id);
}

exports.getComponent = () => noflo.asComponent(findItemsWithId);

The function will be called when both input ports have a packet available.

Output handling

The asComponent helper handles three types of functions:

Regular synchronous functions: return value gets sent to out. Thrown errors get sent to error
Functions returning a Promise: resolved promises get sent to out, rejected promises to error
Functions taking a Node.js style asynchronous callback: err argument to callback gets sent to error, result gets sent to out

With this, it is quite easy to write wrappers for asynchronous operations. For example, to call an external REST API with the Fetch API:

const noflo = require('noflo');

function getFlowhubStats() {
  return fetch('https://api.flowhub.io/stats')
    .then((result) => result.json());
}

exports.getComponent = () => noflo.asComponent(getFlowhubStats);

How that you have this component, it is quick to do a graph utilizing it (open in Flowhub):

Here we get the BODY element of the browser runtime. When that has been loaded, we trigger the fetch component above. If the request succeeds, we process it through a string template to write a quick report to the page. If it fails, we grab the error message and write that.

Making the components discoverable

The default location for a NoFlo component is components/ComponentName.js inside your project folder. Add your new components to this folder, and NoFlo will be able to run them.

If you’re using Flowhub, you can also write the components in the integrated code editor, and they will be sent to the runtime.

We’ve already updated the hosted NoFlo browser runtime to 1.1, so you can get started with this new component API right away.

Advanced components

In many ways, asComponent is the inverse of the asCallback embedding feature we introduced a year ago: asComponent turns a regular JavaScript function into a NoFlo component; asCallback turns a NoFlo component (or graph) into a regular JavaScript function.

If you need to work with more complex firing patterns, like combining streams or having control ports, you can of course still write regular Process API components.

The regular component API is quite a bit more verbose, but at the same time gives you full access to NoFlo APIs for dealing with manually controlled preconditions, state management, and creating generators.

However, thinking about the hundreds of NoFlo components out there, most of them could be written much more simply with asComponent. This will hopefully make the process of developing NoFlo programs a lot more straightforward.

NoFlo and GNOME

henri.bergius@iki.fi (Henri Bergius) — Wed, 13 Nov 2013 00:00:00 +0000

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.

My interview on the origins of NoFlo

henri.bergius@iki.fi (Henri Bergius) — Tue, 06 Aug 2013 00:00:00 +0000

Here is a video interview of me talking about the origins of NoFlo, the flow-based programming environment for JavaScript:

You’ve seen short pieces from this in the NoFlo Kickstarter video, but most of the material is new. This was shot when NoFlo turned two, and so I’m obviously spending some time talking about where things came from.

The video should work well to support the hacker’s perspective of our funding campaign. Please support us and spread the word!

It is pretty amazing to think that since my last post on Friday, we’ve almost doubled the amount of contributions. Thanks to all the nearly 500 backers who have already helped us to change the world of programming!

NoFlo Kickstarter, the hacker's perspective

henri.bergius@iki.fi (Henri Bergius) — Thu, 01 Aug 2013 00:00:00 +0000

This has been a big week for NoFlo, the flow-based programming environment for JavaScript. Yesterday we released NoFlo 0.4, which added support for running flow-based programs in web browsers. And today we launched our NoFlo Development Environment effort on Kickstarter. Before continuing, make sure to watch the video!

This is our effort to bring visual and collaborative flow-based tools into the world of mainstream software development. Similar tools are already in use in many specialized industries from movie special effects to hardware simulation, but we programmers still have to construct these complex maps of our software’s control flow inside our brains based on their textual representation. With your support, we could change that!

We’ve already reached a third of our goal on the first day. Clearly people see the need for these tools. Exciting times!

The stories from TechCrunch and GigaOm tell the story well for non-programmers. But based on the questions I’ve received today, I thought it would be good to clarify various points from a more programmer-centric point of view.

Hasn’t visual programming been tried before?

The story of visual programming tools started with the GRaIL system of the 60s, and has progressed to tools like LabView and Pure Data. So far none of these tools has reached mainstream acceptance outside of their (sometimes fanatic) industry niches.

This is partly because these tools were built originally with a particular problem domain in mind, and partly because of the user experience. Execution matters, as we’ve seen so many times in the tech industry. After all, there were tablets a lot before the iPads.

With our team I have the confidence that we have the necessary skills and vision to build something that is actually a pleasure to use, and that makes it truly easier to work with the control flow of your software than it is with the text editors.

This is not a rehash of UML. UML is a diagram mapping out object-oriented constructs, often used for code generation. NoFlo graphs instead are only the coordination layer that manages the control flow of your software. The components are still handcrafted and unit-tested code that NoFlo merely wires together at runtime, following the edges specified in a JSON file. No code generation here.

Why map out the control flow?

All software is inherently a graph. Functions call other functions, sending data along. Signals are emitted and connections are made. But outside of some debugging tools we rarely see this in a visual format. Instead, when starting to work on a program you have to parse the code and build this map in your head.

This imposes a lot of cognitive load that tools like NoFlo could avoid. When you can see visually how things are connected, you can focus on the bigger picture and build the software you need in a more efficient way. This is what Bret Victor talked about recently.

What is the role for code, then?

However, there still remains a role for text-based code. The actual components, the boxes in the graph, are still written out in JavaScript. But since they’re isolated from their surroundings until a NoFlo graph wires them together, each component can focus on accomplishing a single task well.

My original NoFlo UI prototype already included the code editor for modifying and creating new components. By the principles of TDD, each component is always edited alongside its unit tests, and the tests can be run at any point with a single click. We’re now bringing that back into the new UI:

For those who don’t want this UI, NoFlo is still fully usable also without it. As a matter of fact, we don’t have a UI before the Kickstarter succeeds, and yet many companies are already building their applications with NoFlo. One way is by using the .fbp language.

Why now?

Another reason why the NoFlo development environment may succeed where many others failed is that programming has changed.

We no longer target a single protocol — whether the Win32 API or HTTP — in our applications. Instead, we need to talk multiple protocols and with multiple devices at the same time. Even just dealing with both REST and WebSockets is difficult to many traditional programming environments.

The other big change is the usage of different web APIs as part of your applications. Authentication, handling asynchronous requests and services that are sometimes down can be a pain.

NoFlo brings a controlling layer to your software that allows you to map out these scenarios and isolate the handling of each protocol or API into its own set of small, simple components.

Where could this be used?

Many of the nodal editing tools built in the past have been very domain-specific. However, flow-based programming is a general software development paradigm. NoFlo has already been used for a wide variety of tasks, including:

Business data extraction and reporting
Automating billing workflows
Receiving, routing, and sending text messages
Static site generation
Building server-side web applications

Now that we added browser support it will be possible to also build physics-based user interfaces with NoFlo. There should be some interesting examples of that coming up soon.

NoFlo being a general JavaScript library could in future enable us to coordinate the flows also in new kinds of places like desktop applications. There are several desktop environments where JavaScript is a first-class citizen. Combining flow-based interactions with declarative UI definitions could be something very powerful!

Many of the giants of the software industry, like Google, Facebook, Microsoft, Adobe, and Mozilla are all working on improving the JavaScript development tools. It would be awesome to have their support for what we’re doing.

How about open source?

If you’re following this blog, you probably know that I feel strongly for software freedom. Everything I’ve done during my professional career has been possible only thanks to the open source community.

NoFlo and the UI we’re building are and will remain open source available under the MIT license. As a matter of fact, the UI is designed to not only work with NoFlo, but also to be adaptable to work with other flow-based systems. I feel this is an area with a lot of potential for collaboration with the various functional and dataflow projects out there.

We will however be offering a hosted version of the software for a fee. The various Kickstarter rewards will give our backers an early and cheaper access to that.

But still, you’ll always be able to run the whole stack on your own infrastructure if you choose to do so.

What happens next?

Our Kickstarter campaign has been up for less than a day, and we’re already above 30% of our goal. This makes me quite optimistic for the effort. But of course we won’t succeed without the help of the wider open source and JavaScript community!

There are still quite a lot of days left in the campaign. Tonight I’ll be flying back to Europe, and then we’ll focus on the next steps.

One important area of attention is publishing more demos and examples of NoFlo in real-world use. I hope by early next week we’ll be able to show a few applications running on both browser and Node.js. I will also publish our flow-based port of the Jekyll static site generator. These should help people getting started with this style of programming.

We also have quite a lot of content lined up and waiting for editing. Something of interest to everybody working with flow-based or functional programming will be the long cut of the interview we made with J. Paul Morrison, the father of FBP. My hope is that video will be live by the end of the next week.

If you’re interested in the developments, make sure to follow NoFlo on Twitter, Facebook, or Google+. If you back our campaign, you’ll also receive the updates via Kickstarter.

Thanks everybody for helping to make this possible! Keep spreading the world and giving your support!

NoFlo: two years of flow-based programming

henri.bergius@iki.fi (Henri Bergius) — Wed, 05 Jun 2013 00:00:00 +0000

NoFlo — the flow-based programming system I started — is now two years old. I pushed the first commits to GitHub on June 5th 2011 from Hacker Dojo in Mountain View. To get us started with the story, I’ll let Wikipedia summarize:

Flow-based programming (FBP) is a programming paradigm that defines applications as networks of “black box” processes, which exchange data across predefined connections by message passing, where the connections are specified externally to the processes. These black box processes can be reconnected endlessly to form different applications without having to be changed internally.

While flow-based programming is still far from mainstream, it has been great to watch to the community grow around NoFlo.

There are several start-ups using it as their base infrastructure, with several of their engineers contributing to the open source effort. I’ve personally used the system for quite a wide range of tasks from web services and document transformations to handling payments and user on-boarding processes.

Why I started NoFlo

Two years ago I was undergoing a transition from PHP and Python to the JavaScript world, largely lured by the benefits of a universal runtime and the event-based multi-protocol paradigm Node.js offers.

While new programming languages and environments are easy to get into, this transition provided yet another point where I would have to sit down and port over all the little libraries and utilities I’ve grown to rely on over the years.

I wondered if there could be a better way.

To figure that out, I spent the time I had when traveling between conferences and hackathons of the IKS Project reading various computer science papers on different programming paradigms. Eventually I stumbled upon some mentions of flow-based programming. I dug deeper, and finally read the canonical book on the subject — Paul Morrison’s Flow-based programming, 2nd edition.

Having worked with component architectures and Unix pipes before, the idea resonated with me. To think things through, I took the excuse of having some meetings in Portland to drive up there following the beautiful California 1 coastal road. Couple of days alone in a car is a great way to let your mind flow!

Implementing your own is usually the best method for learning a new concept, and so when I got back to the Bay Area, I decided to write an FBP system of my own on Node.js.

I also kept a Qaiku thread on the things I discovered, parts of which I later republished on this site.

Beyond OOP

Object-oriented programming and Model-View-Controller have been the dominant programming paradigms since the desktop computing era of the 90s, even while the world has become more connected and multi-device. While these concepts did improve some things, the big promises of programmer productivity and component reuse have mostly been left unrealised.

Software has become one of the most important aspects of business and the society. As an effect, the demand for programmers vastly outstrips the amount of computer science graduates we’re able to produce.

The tools side of things isn’t looking much better, either. While IDEs are admittedly improving all the time, most of the talented programmers have ditched them and moved back to the console-based editors of the 80s like vim and Emacs, many following the Unix as your IDE idea. Clearly the productivity boost given by IDEs doesn’t yet match the overhead of using them.

These areas are where flow-based programming can help.

The logic is in the graph

When we design software, we usually start by drawing boxes and arrows on a whiteboard. Later on these are then translated to actual software through various text files containing classes, methods, and configuration information.

As the software evolves, people rarely go back to the original drawing and update it, effectively making the source code only place documenting how different pieces of a system fit together.

With FBP, the logic of the software is designed as a graph — much like a flowchart — and stays as a graph.

The boxes of the graph depict various instances of reusable components, and the arrows the wiring connecting their ports together.

The graph is what FBP systems like NoFlo execute, and it is also something that can be easily drawn on the screen, or even edited visually.

We humans are visual creatures. We are much better at recognizing shapes and visual connections than at finding them from a jumble of text files.

Each node (or process in FBP terminology) of a graph is an instance of a component. Just like objects in OOP can receive and react to messages (method calls), NoFlo components react to packets they receive through their input ports, process them, and eventually send something to their output ports.

The graph decides where the output is sent, meaning that the overall behavior of a program can be modified by just rewiring some of these connections. In traditional OOP the connections between various objects are usually hardcoded, or managed by a complicated dependency injection systems.

Component reuse

Because FBP components are just black boxes performing some well-defined task on incoming packets, they can be connected with each other in multitude of different ways to produce a different behaviour. This gives FBP systems a much better scale of code reuse than traditional OOP or procedural environments.

As an example, my typical NoFlo applications only contain some 5-15% of components written specifically for that project. The rest are all coming from the growing ecosystem of ready-made NoFlo components.

Writing and publishing components is already quite easy, and is becoming even faster and more reliable through tools like the Grunt component scaffolder and noflo-test.

The more components are out there the less time we need to spend writing code, and the more we can focus on designing the software logic itself.

NoFlo on the browser

Apart of better tooling and more components, the other big improvement in NoFlo has been support for running FBP programs on the client. Originally NoFlo was designed for server-side flows, but thanks to the improving client-side Component ecosystem, it became feasible to expose the environment also to web browsers.

This is keeping true with the promises of the universal runtime. With the next release of NoFlo, flow-based programs can be run on pretty much any computing device, whether a Node.js equipped web server, or a smartphone with a browser.

The ability to run client-side flow-based programs presents new opportunities. There is a tradition of using tools like FilterForge for visual effects, or Quartz Composer for user interaction design. As a matter of fact, Facebook Home was designed using flow-based tools:

…something like Facebook Home is completely beyond the abilities of Photoshop as a design tool. How can we talk about physics-based UIs and panels and bubbles that can be flung across the screen if we’re sitting around looking at static mocks? (Hint: we can’t.) It’s no secret that many of us on the Facebook Design team are avid users of Quartz Composer, a visual prototyping tool that lets you create hi-fidelity demos that look and feel like exactly what you want the end product to be.

Since NoFlo graphs run on any device including the tablets and smartphones that the application being designed is likely to target, it can provide an even better environment for such prototyping. There are lots of opportunities for a new tool here, especially given that Quartz Composer’s future is quite uncertain.

We are already doing some work on visual interaction components for NoFlo. This could be huge for NoFlo and FBP in general!

UI is the missing part

What we have with NoFlo is already a quite solid programming environment:

Flow-based engine that works well in both browser and Node.js
Growing ecosystem of reusable open source components
Framework for quickly scaffolding and testing new components
Domain-specific language for defining NoFlo graphs

However, the missing part is a tool that would allow viewing and editing NoFlo graphs visually. Sure, DrawFBP is there, and can be used with NoFlo. But something fitting modern touchscreen interactions and more connected to the live graphs would be better.

I did some prototypes on this with noflo-ui, and wrote down bunch of thoughts on how the graphs would be best shown. There has also been some collaboration with Forrest Oliphant of Meemoo fame.

Last week I sat down with Leigh Taylor, the original designer behind the Medium blogging platform, to go through the various ideas and concepts we had. Based on this we’re starting to have a quite solid design to continue working with.

There will be more on that in the near future, but here is a sneak preview:

Telling the story of NoFlo

Apart from the user interface, the other important task ahead of us is to grow the community around NoFlo and FBP in general.

This means producing better documentation, and explaining the concept in conferences and meetups. I gave a talk on NoFlo in JS.Everywhere 2011, but the project has moved quite far ahead since then.

To tell the story of NoFlo and FBP we’re currently filming a set of interviews with the people involved from the different sides. We’re talking with NoFlo contributors, designers, and with people who have years (or even decades!) of experience with flow-based programming. This will hopefully come out next month.

Expect also more posts and tutorials here on my blog.

Automated linking with rich text editors

henri.bergius@iki.fi (Henri Bergius) — Tue, 30 Apr 2013 00:00:00 +0000

The web is built of links, of pages linking to other resources on the internet. But making those links manually is tedious. This is another area where modern inline editors could do better.

Yesterday on Hacker News, there was a thread about Wikidata, Wikimedia Foundation’s new knowledge base. This comment struck me especially:

I was using Wikipedia the other day and it occurred to me how primitive it is to have all the inner links to other Wikipedia articles defined manually, surely these should have been automated by now (i.e., marking a word or two would link you to the relevant article).

And indeed, this is a usability problem that can already be fixed with the Semantic Interaction stack underneath Create.js.

Introducing Annotate.js

Annotate.js is a VIE widget built by Szaby Grünwald. It works very similarly to a spell checker in traditional text editors — you write text, and it highlights the potential entities you might want to link to. You then can either accept or decline these link suggestions by clicking them. In case of multiple potential matches, you can also disambiguate between them by selecting from an offered list.

Here is a quick video of Annotate.js in action:

You can also try it yourself with an online demo.

Currently Annotate.js has been integrated with the Hallo rich text editor, but it would be easy to do the same with other popular editors like Aloha and CKEditor.

Connecting to entities

The big question with automatic linking is where the entities come from. There are services like OpenCalais that can provide these suggestions for your content, but most of them are focused only on shared knowledge bases of big companies, famous people, and major cities.

Unless you’re running a newspaper, it is unlikely that these are the things your content is about.

Apache Stanbol is an open source engine that can provide the enhancements for you. Out of the box it provides suggestions based on the Wikipedia knowledge repository. But more importantly, you can feed it with your own entities.

This way the enhancements you get for your content can be tuned to be meaningful to your content and your audience. If you write about medicine, they could be about symptoms and diseases, or if you’re writing about technology, they could be specific open source projects and their contributors. With Stanbol, the choice is yours.

The current downside of Stanbol is that you’ll have to run it yourself, but there may be solutions coming for that as well.

Beyond editing

Like never losing your content or managing collections, Annotate.js shows what we can do to improve the editing experience when we interact with it in a semantically meaningful manner.

What Annotate.js does is not merely creating links, but it also marking the machine-readable relationship between them and the HTML content being edited. This can then be used by yet another set of tools — like search engines — to understand and organize the content better.

It is easy to see Create.js (like Drupal did, unfortunately) as just an easy way to add nice inline editing features to your CMS. However, while that is a good initial step, the addition of being able to interact with your content on the semantic level can do a lot more. Automated linking is just another demonstration of that.

As the ecosystem around Create.js and VIE matures, and it ships in more systems, there will be things that we can’t even imagine now built on the stack.

If your CMS is properly decoupled, you can benefit from that immediately.

Writing reusable, multi-platform JavaScript with Component

henri.bergius@iki.fi (Henri Bergius) — Thu, 11 Apr 2013 00:00:00 +0000

I’m currently in the process of porting the NoFlo Flow-Based Programming environment to run also in the browser. While there are some obvious differences in things like filesystem interaction and component loading, the goal here is to reuse as much of the same code as possible between these two platforms.

Many of the building blocks are already in place, and so the port should be complete still this week. You can track the work in issue 63.

Update: the post below is mostly of historical value. Nowadays I would recommend using NPM for dependency management and Webpack for browser builds. For NoFlo, grunt-noflo-browser provides automation for this.

A fragmented ecosystem

The current client-side JavaScript ecosystem is quite fragmented. While on general level any code can be used anywhere, there are many different approaches at packaging, code loading, and templating. In many ways this resembles the PHP landscape before Composer solved the problem there.

On Node.js we haven’t had this problem for a while, as NPM provides an excellent way to share and install code. With more than 27000 modules available, it is truly the default solution for JavaScript package management server-side. Some frameworks like Meteor tried to deviate from this by introducing their own package managers, but eventually came back to the fold.

Module definitions

There are many different ways for handling loading and encapsulation of JavaScript code. The module pattern is quite popular building block. Many also expose their code as jQuery plugins even though that really only makes sense or DOM handling.

Here is how you would define a jQuery plugin:

(function ($) {
  $.fn.somePlugin = function () {
    // some code here
  };
})(jQuery);

Some efforts towards standardization have been made, including the Asynchronous Module Definition spec, and the synchronous CommonJS module spec that Node.js also uses.

Here is how an AMD wrapper for code looks like:

define('somePlugin', ['jquery'], function ($) {
  return function () {
    // some code here
  };
});

The CommonJS definition for something similar would be the following. This will look familiar to Node.js developers:

var $ = require('jquery');
exports.someFunction = function () {
  // some code here
});

Harmony is the proposed next generation of the JavaScript language, and it includes a new module syntax:

module 'myModule' {
  import 'jquery' as $;
  export function someFunction () {
    // some code here
  }
}

It is no wonder many developers feel a bit lost on how they should expose their code or widgets!

The Harmony module spec may eventually harmonize this, but it will take a while before you can actually ship code like that for even a reasonably majority of browsers.

Module installation and loading

Once you’ve picked the module pattern to follow, the next question is how to actually get your dependencies installed.

The traditional way is to fetch “known good” versions of the libraries, add them to your project repository, and then just include each library with its own script tag. But this means having to maintain all the libraries in your own project, and cluttering your repository and change log with them.

A variant of this is loading common libraries from a Content Delivery Network like Google. This has the advantage that your users won’t have to download something like jQuery separately from each web server, and that you don’t need to duplicate the library files in your own code repository. But at the same time, this relies on the CDN provider not breaking things, and complicates offline usage.

And you still have to write script tag for each of them.

Bower

Twitter’s Bower package manager aims to help with dependency management. You declare the libraries your code needs in a component.json file, run Bower, and you’ll get the correct versions downloaded to your system.

Bower only handles dependency resolution and downloading, and so you’ll still be writing script tags for all modules you installed. But at least this allows you to keep the library files out of your repository.

Require.js and volo

The Require.js project seeks to solve this by handling module loading for you in an automated manner. They even provide the volo package manager for installing all the libraries you need.

Require.js is a quite popular way of solving this, but means that you will need to follow the Asynchronous Module Definition specification with your code.

Component

Component is a newer solution for this started by TJ Holowaychuk of Express and Mocha fame.

The system is explained a lot better in the introductory blog post, but in nutshell Component is a combination of a package manager and a module loading system based on CommonJS.

With Component you can easily write and distribute reusable JavaScript modules, including user interface components that may include HTML templates and CSS. There is a component writing tutorial available.

The Component installer will pull all the dependencies for you, and construct a single, easy-to-include JavaScript file out of them and your own code. If you want to think of it in that way, this is sort of similar to Composer generating an autoload file for PHP code.

Which to choose?

Given the multitude of options available, it can be hard to choose which one to go with. Eventually a winner may emerge, but in the meanwhile, my approach is the following:

Component for client-side libraries and widgets
NPM for Node.js libraries

If I was just writing client-side code, Require.js and volo may have been just as good option, at least if I want to deal with AMD.

However, the big advantage of Component is that it is based on CommonJS modules, which Node.js also uses. With it, I can share library code a lot more easily between browser and the server, the two main platforms of the Universal Runtime.

CommonJS modules run nicely in the browser, on Node.js, and other server-side JavaScript runtimes.

Writing a multi-platform library

Writing widgets with Component is covered nicely in the building a date picker component tutorial, and so I’m focusing on how to build more general-purpose libraries here.

Getting Component

The first step with Component is getting the tooling in place. Component — like most of the JavaScript dependency managers — is written on top of Node.js. It would be possible to implement the Component spec in other languages for easier integration in their native toolchain, but for now Node.js is what you must install.

Once you have Node.js running, getting the Component tools is easy:

$ sudo npm install -g component

This will give you the component command. You can run it to see the functionality it provides.

Finding dependencies

The next step is to find the libraries you need. Quite a lot of libraries and widgets are already available, and can be found from the Component Wiki.

You can also use the Component command to look up modules:

$ component search underscore

component/underscore
url: https://github.com/component/underscore
desc: JavaScript's functional programming helper library.

nathan7/memoize
url: https://github.com/nathan7/memoize
desc: underscore's memoize

As you can see, the components use a “GitHub-like” naming scheme of <vendor>/<module>. This is again similar to vendor names in Composer:

The package name consists of a vendor name and the project’s name. Often these will be identical - the vendor name just exists to prevent naming clashes. It allows two different people to create a library named json, which would then just be named igorw/json and seldaek/json.

Since NoFlo relies heavily on Node’s event API, we need to find an equivalent library for Component. After a quick look through component search events, it turns out component/emitter does the job.

The component.json file

Each Component module must provide a component.json file where you declare things like the name of the package, the version number, the software license, the files provided, and the possible dependencies. This is quite similar to the package.json file in NPM.

I’m using a very simplified version of NoFlo’s Graph class as the example here, so I can call the library bergie/graph. Like most JavaScript libraries, this will be under the MIT license.

{
  "name": "graph",
  "repo": "bergie/graph",
  "description": "Simple graph class",
  "license": "MIT",
  "version": "1.0.0",
  "scripts": [
    "graph.js"
  ],
  "dependencies": {
    "component/emitter": "*"
  }
}

For Node.js support you’ll also need a corresponding package.json file:

{
  "name": "graph",
  "description": "Simple graph class",
  "main": "./graph.js",
  "version": "1.0.0"
}

Once the dependencies are declared, run the installation:

$ component install

The example only uses Node.js’s built-in libraries, so NPM installation is not yet needed. If you add third-party libraries, you need to install them also:

$ npm install

Module code

Writing a Component module is very similar to writing Node.js modules. Create the file we just declared in the JSON file and open it in your favourite editor.

Since we’re aiming for multi-platform code, the main difference is dealing with platform-specific differences. For example, the event emitter library in Node.js is called events, and the Component equivalent is called emitter.Luckily their APIs are exactly the same, so we only have to do loading conditionally:

var EventEmitter;
if (typeof process === 'object' && process.title === 'node') {
  // Node.js
  EventEmitter = require('events').EventEmitter;
} else {
  // Browser
  EventEmitter = require('emitter');
}

This way, we have the correct event emitter implementation available for our code. Now we just create a constructor function to inherit from that:

// The constructor, just call "super"
function Graph () {
  this.nodes = [];
  EventEmitter.call(this);
}

// Set up inheritance
Graph.prototype = Object.create(EventEmitter.prototype);

// Define methods
Graph.prototype.addNode = function (name) {
  this.nodes.push(name);
  this.emit('node', name);
};

Once the code is there, we need to expose it as a CommonJS module:

module.exports = Graph;

Running the module in Node.js

For Node, this is all we need to do to be able to use our Graph as a module:

// Include the module
var Graph = require('./graph');

// Instantiate
var g = new Graph();

// Hook into events
g.on('node', function (name) {
  console.log("Node added " + name);
});

// Call a method
g.addNode('Foo');

Running this should end up with message Node added Foo shown on the console.

Running the module in browser

To be able to run the module in the browser, we need to run Component’s build process.

$ component build

This will generate a JavaScript file build/build.js which provides CommonJS module loading support, and all the JavaScript code we’ve declared in the JSON file.

Now you can include that file in your HTML, and start using the Graph module:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8">
    <script src="./build/build.js"></script>
    <script>
      var Graph = require('graph/graph.js');
      var g = new Graph();
      g.on('node', function (name) {
        alert("Node added " + name);
      });
      g.addNode('foo');
    </script>
  </head>
  <body>
  </body>
</html>

Conclusion

Component can be used for solving the JavaScript code-sharing problem. They let you build full applications out of smaller, reusable modules. And thanks to the CommonJS module specification, it is quite easy to write these modules in away which enables them to be used also under Node.js and other JavaScript runtimes.

This post, and the date picker tutorial should give you enough information needed for starting to decouple your front-end applications, and to participate in the emerging open source Component ecosystem.

Even with more than 800 components available, it is too early to declare Component the winner in the front-end dependency management space, but it is a well-designed system that works quite well.

I will be utilizing Component for some of my JavaScript projects in the future.

Create.js in 2013

henri.bergius@iki.fi (Henri Bergius) — Sun, 06 Jan 2013 00:00:00 +0000

It is now 2013, and the IKS project, started back in 2009 to improve content management systems through semantic technologies, has ended. Alongside Apache Stanbol and VIE.js, the Create.js inline editing toolkit was one of the major outcomes of this European Union funded effort.

This post outlines the current state of Create, and some of the things that will be happening around it in 2013.

Increased CMS adoption

Thanks to being picked up by major CMSs like Drupal 8, TYPO3 Neos, Midgard, Symfony CMF and OpenCms for their inline editing needs, Create.js is experiencing very strong adoption. Many of these CMSs will be shipping a new major version during 2013.

These releases will bring Create.js into millions of sites out there, giving users a friendlier and faster way to edit the web. By being built on the semantic interaction framework of VIE, this also means a significant expansion of the RDFa Linked Data base.

This amount of new users will be staggering, meaning that we will need to put a lot of focus into stability and ease-of-use of the toolkit. To make life for new integrators and contributors easier, we will also need to improve the documentation and test coverage. All of this is shown also by the fact that Create.js on GitHub has climbed from few hundred watchers a year ago to nearly 1400 today.

Any editor you want

The first versions of Create.js were written exclusively with the Aloha Editor in mind. Later on we added support for Hallo.js in order to provide a simpler, MIT-licensed alternative. However, the needs of CMSs change and new promising editors are released.

With this in mind, we received a contribution from the OpenCms team to have a more generic editor abstraction allowing integration of any new editors that CMSs may want to integrate. With it, the latest versions of Create.js support also Redactor and CKEditor 4 alongside Aloha and Hallo.

The utility of this abstraction layer was proven recently when Drupal switched from Aloha to CKEditor.

Hallo.js:

Aloha Editor:

CKEditor:

Redactor:

In addition to the editors we now support, integrators can use the reasonably simple property editor API to implement their own editors when needed. For example, Drupal provides a custom editor widget that utilizes forms rendered on the server side for editing more complex field types.

New default UI

As many of you probably know, Create.js can be used on two levels: as a full inline editing interface, or as a set of components for building your own editing UI.

In the latter part of 2012, much of focus was put into the components themselves, as that is the way most CMSs leverage Create. But the default user interface is also important, and so I have been collaborating with the Berlin-based designer Marie Schweiz to improve the user experience of stock Create.js. This work is still in the concept stage, but I’m quite happy with the direction we’re headed.

One important concern to tackle with the new UI is handling of non-visible metadata and the other concerns raised by Lullabot’s excellent critique of inline editing. Here you can see some of that in action:

Other important parts is to use colored indicators for showing what can be edited, and its state (published, untranslated, etc.), and to make the process of adding new content clearer:

Clear visuals and bigger touch targets should also make the new UI friendlier for tablets and other new touchscreen devices.

New editing tools

The main purpose of Create.js is to enable inline editing of textual content, but even in the original versions we had additional features like image handling and versioning that most CMSs need.

Adding more functionality related to non-textual content is highly useful, and something that ought to go hand-in-hand with the new UI effort. In the new default UI we have a large overlay (seen in blue in the geolocation editor) that can be used for new interesting editing features, like better image pickers, or even editing images and videos to be inserted to a page.

Another idea I’ve been toying around has been a more semantic way of handling tables. Instead of editing tables in the traditional WYSIWYG way, how about making queries to your CMS system and then presenting the data in tabular manner? Aloha’s Blocks feature can give a lot of inspiration here.

Getting involved

In 2013 the development of Create.js should happen in a lot more community-driven manner. Given the massive adoption of the library, this shouldn’t be a problem.

If you’re interested in getting involved, take a look at the repository on GitHub, file issues, and send pull requests. The most immediate concern is getting the 1.0.0 stable out of the door, which should be helped greatly by the recently-released VIE 2.1.0.

For discussing both development and integration of Create.js, the Create.js Google Group and the #iks IRC channel on FreeNode are the best options. The Create.js change log is also an important thing to watch.

Create.js hackathon in Berlin

henri.bergius@iki.fi (Henri Bergius) — Tue, 24 Jul 2012 00:00:00 +0000

Last week we at IKS organized a two-day hackathon for developers interested in Create.js, VIE, and in new tools for editing websites semantically.

The original agenda for the event can be found from the event’s wiki page, and I believe we got it covered quite well. I’ve been to quite a lot of hackfests, and usually the first day is mostly spent by people arriving, figuring out the WiFi setup, and getting to know the development tools. This time was different: people jumped straight into the code and started working.

The venue at Theseus Innovationszentrum, arranged by DFKI, was a nice one. We had food, coffee, and fast connectivity. And the place even had toys like big touchscreen computers to try Create.js on. On the first evening we continued the event at the c-base hackerspace, and the participants staying after Friday went to the Berlin GitHub drinkup.

More robust Hallo and Create

An important theme in the event was to improve both Hallo and Create. The Create.js theme got a lot nicer, and thanks to the contributions from Alkacon the next versions will run nicely also on older Internet Explorer and Opera versions.

Create’s editor selection mechanism was also rewritten. Now you can easily set up custom editor configurations for managing different content types. For instance:

// Set a simpler editor for title fields
jQuery('body').midgardCreate('configureEditor', 'title', 'halloWidget', {
  plugins: {
    halloformat: {}
  }
});
jQuery('body').midgardCreate('setEditorForProperty', 'dcterms:title', 'title');

// Disable editing of author fields
jQuery('body').midgardCreate('setEditorForProperty', 'dcterms:author', null);

In addition to the other activities, documentation in the Create.js Integration Guide also got a lot better.

VIE and literals

The VIE semantic interaction library is the basis of everything we’re doing in the decoupled CMS space.

Next big step for VIE is better literals handling, which will allow a lot easier management of multilingual content. Several people were working on this in the hackathon, and I hope we’ll be able to release the first beta of VIE 2.1 with this soon.

VIE provides a quite comprehensive entity type system, which most systems don’t really utilize yet. To make its capabilities more apparent, I built an integration with the Backbone Forms library where you can autogenerate quite nice forms on for any type that VIE knows about. For instance, we can generate forms for Schema.org types.

This will be the key feature for implementing a metadata editor in Create.js, and so it would be nice if CMSs would start providing their content type structure to VIE.

New CMS integrations

Several of the hackathon attendees came there to work on integrating Create.js with their CMSs. While the documentation is getting better, it is still good to be able to help developers implement the necessary steps into their systems.

An interesting new integration is with Drupal, worked on by Roni Kantis. While Drupal has their own Spark inline editing initiative, the Create.js module should show that cross-CMS collaboration in user interfaces is also possible. I hope to be able to demo this in DrupalCon Munich.

For PHP projects interested in Create.js, the CreatePHP library should make things a lot easier. In the hackathon its interfaces were clarified quite a bit, and now it powers the inline editing capabilities in both MidCOM and Symfony CMF, with TYPO3 coming soon.

If you consider my secret plan for PHP content management systems from last summer, there is clearly some progress.

There was also work done on integrations into popular frameworks like Ruby on Rails and Django. I hope we’ll hear more of these in the coming weeks.

More visibility for Create.js and Hallo

As more and more CMSs are embracing collaboration on the UI level, these projects are becoming quite popular. As I write this, Create.js has 1062 watchers on GitHub, and Hallo has 664.

While watchers don’t necessarily mean more contributions, it is certainly nice to see views like this:

WYSIWHAT

This week I also participated in the WYSIWHAT event, where Sourcefabric and OERPUB were discussing the approaches at rich-text editing of educational and large documents.

The event is still ongoing, but it seems there is a lot of synergy between what we’re doing with VIE and Create.js and their efforts. I’m certainly looking forward to collaborating with them in the future!