That isn't true for native module writers. `nan` is not an entire solution because it doesn't abstract away `libuv` versioning as well. So when I had to get my native module working, I had to support the ancient `v8` in 0.10, the moving target in the 0.11.x series (breakage in 0.11.13 & 0.11.15 -- semver anyone?) and the even newer `v8` in io.js.
The more native code you write for this ecosystem the more you realize there needs to be a complete abstraction away from the JS engine and event loop to allow for the core to upgrade as fast as possible and module writers to ease into the newer versions. This is one of the reasons why the version of `v8` in Node proper lags behind so much -- it breaks the native module ecosystem every time there is an upgrade.
> If you write your code for node.js, it should work on io.js.
Yes, this was one of the points I mentioned however this precludes me from using newer and possibly better APIs and syntax in io.js. If that's the path to take what is the point of io.js if everything will be written to the lowest common denominator?
> Fragmentation is good, it stimulates the eco-system for better products.
Maybe? I'm not sure. It certainly hasn't looked very rosey from Android's point of view but has it worked for other things? I'm skeptical.
> Fragmentation is good, it stimulates the eco-system for better products.
I'm skeptical too. Maybe fragmentation isn't always bad, but flat out "good"? I've also done Android development, and the fragmentation makes developing for the platform more expensive and time consuming. I don't know of any "good" that comes of it.
The more native code you write for this ecosystem the more you realize there needs to be a complete abstraction away from the JS engine and event loop to allow for the core to upgrade as fast as possible and module writers to ease into the newer versions. This is one of the reasons why the version of `v8` in Node proper lags behind so much -- it breaks the native module ecosystem every time there is an upgrade.