Henri Bergius - Javascript

NoFlo: two years of flow-based programming

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

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

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

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.

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

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

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!

Video: Decoupling Content Management

henri.bergius@iki.fi (Henri Bergius) — Thu, 12 Jul 2012 00:00:00 -0700

Our concept of Decoupled Content Management, together with the VIE and Create.js is really taking off. I've spent in various conferences this summer speaking about them.

Here is a video from the talk I gave in the IKS Salzburg Workshop last month. It is quite a lot shorter than the more comprehensive talks like the one in Symfony Live, but should introduce the ideas pretty well:

Those interested in the background of all this may also enjoy this video where we're talking about the concepts behind Create.js together with the Aloha Editor team back in summer 2010 when things were just getting started.

IKS has also published a video of Sebastian Germesin's VIE tutorial from the same event:

Elegance matters

henri.bergius@iki.fi (Henri Bergius) — Sat, 19 Nov 2011 00:00:00 -0800

CoffeeScript is to producing JavaScript what Markdown is for producing HTML. Elegance matters.

JavaScript in Qt5

henri.bergius@iki.fi (Henri Bergius) — Wed, 16 Nov 2011 00:00:00 -0800

Qt 5 is bringing JS at the same level of support as C++

—

Quim Gil, Nokia

Great news for mobile developers, as with this you can combine declarative user interfaces with the universal runtime

ShareJS: library for Google Wave -style collaboration

henri.bergius@iki.fi (Henri Bergius) — Thu, 13 Oct 2011 00:00:00 -0700

ShareJS is a CoffeeScript library for building Google Wave -style live collaboration features for web applications. MIT license, in GitHub.

ShareJS launch talk View more presentations from Joseph Gentle

Jison: Building parsers in JavaScript

henri.bergius@iki.fi (Henri Bergius) — Wed, 07 Sep 2011 00:00:00 -0700

Jison: Building parsers in JavaScript

CoffeeScript, for example, is parsed using Jison.