Inspired by a horrible Jenkins CI workflow I thought about a GUI app that could help compose and request/monitor CI jobs. Node based GUI seemed like an interesting option for that. I've tested several technological stack to develop something like that and here are my observations.

Nodes in Haxe/Heaps

I've started with testing Haxe + Heaps. I like the flexibility Haxe gives. Outputting a web app based on JavaScript is pretty easy. Unfortunately Heaps engine can't be easily outputted as a C++ target.

My main takes for Haxe are:

  • workflow - setting up a project is super easy and quick. Compiling with .hxml meta files is cool. Compiling to JavaScript is pretty quick but debugging using web browser is less than perfect.
  • language - Haxe itself is a pretty elegant language. I didn't use a lot of the advance features. What bothers me the most is the hard object oriented design for both Haxe and Heaps. I find it to be very constraining and not fitting an app like this.

Nodes in Godot

This version didn't get far. I've created a node object and added dragging functionallity. Moving mouse quickly made Godot loose the node from under the cursor.

Godot approach:

  • workflow - Godot is pretty well designed. I thought I'll have to build a node using the graphical editor but the scripting API allows you to override the draw function for an object. That means you can compose a node in the code and draw it in one go.
  • language - Godot's scripting language is similiar to Python. It's very quick to develop in.

I honestly like working with Godot. What I don't like about it is that I confined to an engine. There is not much flexibility. I was also worried that loosing the node from under the cursor point to redrawing not being fast enough.

Nodes in SDL2/OpenGL/Nuklear

I do like low level programming. Nuklear, header inly GUI library is awesome for a low level project which uses OpenGL directly.

I already had a skeleton for an app using SDL2, OpenGL and Nuklear. I've plugged the node-based GUI example from the Nuklear repository and started modifying it.

Takes for this one:

  • workflow - I'm used to working with C and setting up a project was pretty quick. It compiles quickly and makes it pretty easy for me to compile the code on Windows and on Linux. Debugging is pretty easy with either Visual Studio or GDB.
  • language - it's C… It's great, dangerous, flexible, exhausting, performant, enjoyable but slow to develop in. Using Nuklear library is a bit constraining but it's pretty easy to render whatever you want by using OpenGL directly.

Nodes in Raylib

The last experiment I've done was using Raylib. I find this game development framework very interesting. It gives you all the foundations and still allows you to code in C. That means you can pretty quickly modify even the OpenGL calls.

Unfortunately the workflow, using Notepad++ and a MinGW/TinyC Compiler means you have to use GDB on Windows. At this point the code is crashing and I didn't feel like going through the hassle of debugging through GDB.


It was very interesting to drag this idea through a different workflows. It was a very quick experiment which means that nothing actually got a fair shake…

I might update this post. I find the idea very interesting. Writing an app like this takes a lot of time and effort so results won't come any time soon.