from an underlying implementation stand point which one would have been written with an intent for best performance?
We have to be careful not to compare apples and oranges here as Johnny-Five doesn't perform the actual low level IO on the Raspberry Pi, the IO-Plugin does.
Quite a bit of effort went into making onoff as fast as possible at what it does which is DigitalRead, DigitalWrite and interrupt detection from userspace using the
sysfs files located at
/sys/class/gpio. I'm unaware of another package that uses
sysfs files and is faster than onoff. The advantage of
sysfs files is that they exist on many platforms like the Raspberry Pi, BeagleBone, C.H.I.P, ... On a Raspberry Pi 3 onoff can do up to 300,000 digital writes per second.
Because onoff uses
sysfs files it functions on multiple platforms. There are also platform specific packages like pigpio that only run on the Raspberry Pi and that take advantage of platform specific hardware to make things faster. For example, pigpio can do up to 2,000,000 digital writes per second on a raspberry Pi 3.
There are two Johnny-Five IO-Plugins for the Raspberry Pi; Rasp-IO and Pi-IO. I implemented Pi-IO and can confirm that Johnny-Five was implemented in a way that makes it possible to write IO-Plugins that are fast. Johnny-Five brings very little additional overhead and performance is highly dependent on how the IO-Plugin is implemented. For example, Pi-IO which uses pigpio internally can do up to 1,700,000 digital writes per second on a Raspberry Pi 3. The corresponding test program can be found here.
In summary, both onoff and Johnny-Five offer excellent performance.
Jhonny-Five seemed to have bigger community
This doesn't just seem to be the case it is the case :)
will we be missing on anything if we chose onoff as that's what I'm considering.
I don't know what the requirements are so I can't tell.
Also due to the event interrupts.
Don't overestimate the capabilities of interrupt detection from userspace on Linux systems. Linux isn't a realtime operating system and there are no guarantees about interrupt latency.
t2 run file.js?