Re: Being limited on non-x86 platforms with older versions -- IBM was interested in the work we've done to abstract away from the particulars of modern script engines. At Bloomberg we decided to forego Node itself for the time being and target engines directly. We built an abstraction layer that allows native modules to be completely isolated from the engine they're being attached to while still retaining performance as if they were using the engine API directly. While `nan` provides some abstraction to native module writers, it targets abstraction over `v8` rather than abstracting `v8` itself at a more basic level. I'm working on open-sourcing this layer right now, but even if it was up on GitHub, it doesn't mean the Node (or io.js for that matter) community would be interested in actually adopting it or something like it to not depend directly on `v8`. This was interesting for us and for IBM because Spidermonkey has a bytecode interpreter and does not require a platform JIT to work and we actively use it on both POWER and Sparc hardware right now. It might seem like that is less than ideal compared to building out a JIT backend for each platform, but we've found in practice that for most common tasks the performance characteristics aren't that different. Freely being able to swap out engine backends (we also have it targeting Lua just to prove it isn't tied to JS) also allows direct benchmark comparisons and could help ignite server-side benchmarks that aren't directly tied to browser performance. I'd love to see more people interested in divorcing Node from `v8`, but admit it's a tough sell.
I take it this is different from the NodeRED[0] thing IBM released a year or two ago? So, if node.js proper was closer to v8 HEAD, then they might find that the v8 team has recently been supportive of utilizing "precompiled scripts" (in v8 parlance). And I don't believe divorcing node from v8 is hard. Nobody is interested[1] (long term) in supporting such a divorce. For the most part, creating an API that would support both at the same time is maybe a month's worth of work at most.
I don't know any details about NodeRED, so not sure how that factors in. All I know is IBM was interested in using Node in products, as OP mentioned and their involvement in the foundation shows. Agreed, divorcing Node from the underlying engine isn't hard -- the point was whether the community would accept such a fundamental change in the project or whether a hard dependency on `v8` forevermore and `nan` as a pill to ease the pain is "good enough". (The `spidernode` project was the work of an intern at Mozilla and really was more like the `nan` abstraction, shoe-horning SM into `v8`'s existing API and isn't the kind of fundamental abstraction I'm referring to.)
