Skip to main content

· One min read

First steps have been made! My endeavour to get rid of nan-type bindings in nut.js, opencv4nodejs, to be precise, is making progress. Slow, but steady.

So far I redesigned how OpenCV itself is built and distributed for further use, solving one of the issues which are bothering me with the existing setup. This redesign eliminates a whole codebase I had to think through and follows a pretty lean approach for providing precompiled libs.

The setup is already automated for all three platforms and I started a new project which uses these new artefacts. The process required some tweaking but right now everything fits together really smooth.

As I already said, first steps have been made and I'm looking forward to take the next ones!

Best regards

Simon

· 2 min read

Sometimes you've got to ask this simple question. Does something spark joy for you? In my case, something that definitely does not spark joy is updating opencv4nodejs-prebuilt. The reason being is the fact that opencv4nodejs relies on  Native Abstractions for Node.js , which in turn means that on every new node or Electron release, I'd have to provide additional prebuilds. In theory, this sound rather straightforward. Add a new node / Electron version to your CI config and off we go, but reality looks a bit different. Hands down, opencv4nodejs is great. It's configurable, compatible with recent OpenCV versions and async. However, it also has its peculiarities.

It relies on a custom npm package which provides a wrapper around the whole OpenCV CMake build. This way it’s possible to configure and build OpenCV without leaving the well known npm ecosystem. While this approach definitely has its benefits, it’s an additional burden for me. When I started building nut.js I just used opencv4nodejs. But since I envisioned the installation of nut.js as straight forward as possible the whole „we build everything for you on install" just didn’t suite me. That’s how I ultimately ended up adopting two codebases by forking both the npm OpenCV build and opencv4nodejs itself to provide prebuilt binaries.

As time went by, I noticed a few things I definitely wanted to change:

  • node ABI dependence: Every new node release requires new prebuilds which is the sole reason nut.js is running a bit late with support latest node versions
  • node-gyp: I don’t know why this build system is still so popular. I’m not a fan
  • Way too much functionality: opencv4nodejs aims to provide general purpose bindings for OpenCV while I’m only requiring a very small set of features
  • Mental load: I’m not particularly interested in deep diving another two codebases
  • Complexity: Even tough the setup works I’m the only one who knows why

To put it in a nutshell (haha): I’m constantly looking for alternative solutions which solve the above points. I recently started digging into something which might be promising, I’ll let you know once I know!

Best regards

Simon

· One min read

Huh? A dedicated nut.js page? Including a blog? Tell me more!

Well, it’s finally happening! After more than two years of active development nut.js receives the home it deserves. It’s all rough an sketchy so far, but I recently thought about the progress I made with nut.js and decided to step things up a little bit.

I won’t go into much detail now, but rest assured that I have great plans for the future!

Feel free to look around, there’s not a lot to see thus far. But also make sure to regularly check this page for updates!

All the best

Simon