Non-blocking. Since all code runs in response to an event, we never have to block, or wait for something to happen in our code. This is common in projects based on Arduino–it is common there to sleep for a short time while you wait for a task to finish. This is bad as nothing else can happen while this happens, thus “blocking”. In Node.js we just have an event fire when the task finishes, then something else can run while we’re waiting. This allows our code to get more done on a single thread.
Single-threaded. This can be a disadvantage as we can only do one thing at a time, however in our case we have a single-core processor and a non-blocking architecture, reducing the disadvantages of being single-threaded significantly. The advantage of this is that we don’t have to worry about coordinating data and tasks between threads, which can be quite difficult. Single-threaded code is much simpler and thus both easier to understand, faster to write, and less likely to have bugs. This does mean we must be careful not to spend a large amount of time handling a single event, as that would then block other events–this is easily solved by breaking that code into multiple event handlers and events, which has the side affect of being easier to understand.
NPM. The Node Package Manager is similar to the concept of Ruby Gems, 3rd party IP in VHDL, or DLL files in Windows. It is even better than those, however, as there is a huge number of high-quality libraries available for use, which can be installed with a single command and virtually never conflict with each other, even when different versions of the same library are used at the same time. Most of these libraries are open source and free to use in projects such as ours, most of them run in ARM just as well as on x86, and there are libraries written specifically to help interface with the hardware we use, such as the GPIOs on the BeagleBone Black. The existence of these easy-to-use libraries means we don’t have to spend time re-writing commonly-used code, we don’t have to spend a lot of time searching for and installing libraries, and we can focus on writing the code that is unique to our project.
Cross-Platform. All the code we write will run on any ARM processor, and much of it will run on x86 as well. This means we can change our SoC fairly easily if desired, and we just have to change the pin mappings and device tree overlays. The actual code will not need changed, or even re-compiled. We can also run portions of the robot code within a browser for simulations.
This blog post summarizes why we dislike Java:
Whenever I write code in Java I feel like I’m filling out endless forms in triplicate.
“Ok, sir, I’ll just need your type signature here, here, and … here. Now will this be everything, or…”
‘Well, I might need to raise an exception.‘
The compiler purses its lips.“An exception? Hmmm… let’s see…. Yes, I think we can do that… I have the form over here… Yes, here it is. Now I need you to list all the exceptions you expect to raise here. Oh, wait, you have other classes? We’ll have to file an amendment to them. Just put the type signature here, here, … yes, copy that list of exceptions….