Slang and Node-RED, a Comparison

Both Slang and Node-RED are dataflow programming tools using visual elements for easy and fast development.

Node-RED is great for prototyping applications, especially for the Internet of Things (IoT). Many components exist for Node-RED and a large community has emerged around the open source project originally developed by IBM. Its development has started in 2013.

Slang can be used for many things, including programming for the IoT. It is a very young project and virtually no community exists yet. It is open source as well and being developed mainly by Bitspark GmbH, a small web development company.

We want to take a closer look at both solutions. Keep in mind that Slang doesn’t try to replace Node-RED but offer a slightly different approach to satisfy different needs. I also want to stress that I cannot guarantee that this article is without bias since I am one of the core developers of Slang.

Brief Comparison

The following bullet points give a brief overview over differences and similarities between Slang and Node-RED. Differences are explained in more detail further down.

• Website: tryslang.com | nodered.org
• GitHub: github.com/Bitspark/slang | github.com/node-red/node-red
• Core language: Go | JavaScript
• License: Apache-2.0 | Apache-2.0
• First release: 2018 | 2013
• Paradigm: purely flow-based | flow-based and imperative (JavaScript)
• Components: yes (called operators) | yes (called nodes)
• Typed ports: yes | no
• Multiple in-ports: yes | no (workaround with contexts)
• Multiple out-ports: yes | yes
• Visual control flow: yes (switch, loops, delegates) | partly (only switches)
• Stream processing: yes (stream as basic type) | partly (mostly imperative)

Typed Ports

Slang

Slang requires each port to have a type. All objects must originate from such a port specifying its structure and values. This might seem unnecessarily complex, but it enables Slang to drastically increase reusability of operators and exposing a clear interface.

As you might know, operators are composed of other operators in Slang. It is the same with ports: ports are composed of other ports, until you get the most primitive ports: string, number, boolean, ... All these ports are displayed so that you can connect them to different operators, even if they are logically part of the same object.

Ports always have a type in Slang, indicated by color.

• Operators have clear interfaces
• No need to cope with the internals, just see what matters

Node-RED

In Node-RED, in-ports and out-ports both have no type. They emit and take JavaScript objects of arbitrary structure. Of course, the vast majority expects data of a certain structure which is not visible from the outside.

This is great for prototyping: you can quickly change the kind of objects that are transmitted, add or remove properties, change types, etc. However, you have to look into how a node is implemented to know how to connect them. Apart from that, you cannot split data emitted from a port but have to always pass the whole object.

Ports disguise the structure of objects in Node-RED.

• Nodes do not show the structure of data they consume or produce
• You have to look at the implementation or the read the documentation

Multiple In-Ports

Slang

In Slang, a node can have multiple in-ports. Otherwise typed ports would not even be possible. However, one in-port must only be connected with one out-port.

An operator will always wait until it has received one value at each in-port before it emits exactly one value at each out-port. This is called one-in-one-out principle making operator behavior predictable and avoiding deadlocks.

Quadratic formula with just basic operators.

Same as above with generic Slang evaluate operator.

Node-RED

Node-RED allows only one in-port per node. Still, multiple nodes can be connected to this node. Each time an object arrives from any connected node, the JavaScript callback of that node will be executed.

If you need different kinds of objects to perform a task in Node-RED, you need to collect values in its internal state (called node context) and determine yourself when to emit a value.

Attempt to write a generic node for the quadratic formula.

And the JavaScript of the QuadraticFormula node:

var a = msg.payload.a;
var b = msg.payload.b;
var c = msg.payload.c;
msg.payload = (-b + Math.sqrt(b*b - 4*a*c)) / (2*a);
return msg;

Note that you cannot see that the object QuadraticFormula expects needs to be of the form {a: <number>, b: <number>, c: <number>}without looking at the code.

HTTP Server Throughput

Simple HTTP server handling GET requests.

Simple HTTP server sending “HELLO” to all clients.

Results

The following measurements were done on the same machine, both Slang and Node-RED executed on a local machine. A benchmarker program made as many requests as possible and counted the number of successful requests per second in intervals of 15 seconds.

• Measurement 1: 7021 reqs/s (0.14 ms/req) | 1693 reqs/s (0.59 ms/req)
• Measurement 2: 6381 reqs/s (0.16 ms/req) | 1770 reqs/s (0.57 ms/req)
• Measurement 3: 6468 reqs/s (0.16 ms/req) | 1792 reqs/s (0.56 ms/req)
• Measurement 4: 6041 reqs/s (0.17 ms/req) | 1798 reqs/s (0.56 ms/req)
• Measurement 5: 6969 reqs/s (0.14 ms/req) | 1751 reqs/s (0.57 ms/req)
• Average: 6576 reqs/s (0.152 ms/req) | 1797 reqs/s (0.557 ms/req)

On average, even without any optimizations Slang is about 3.6 times faster than Node-RED.

Of course, this is only one example and one cannot conclude that Slang is faster in all circumstances. However, Slang has the advantage of being able to benefit from Go language features such as channels and go-routines.

If you have questions you are welcome to join our slack community: Join TrySlang Slack