IO.js or old rake with new sauce

“It happened! Node.js was developed as a fork of io.js! Hi ES6! Hi new V8! ”The developers rejoiced. It was useful to watch with the hope that now, starting from scratch, the guys fixed the fundamental jambs!

What fundamental mistakes are made and why without their correction the industrial scale is controversial or simply unattainable. This is not a horror article, as it can be understood, it is a request for help, because the node has stalled exponentially, and hope is only in this project.

backward compatibility

No, it’s not about compatibility with node.js, but it’s about the lack of guarantees that after the “next” update of the engine core, something will not fall off. JAVA gives such a guarantee, even if many methods are considered deprecated, and the compiler will look obscene, nevertheless the code written in Java 2 works both in the 7th and 8th, and we know that it will work in further. Or, the path is C ++ and GCC: compilation with an indication of which standard to rely on. Also, partly, there are no guarantees at the documentation level (see below).
Many projects lost popularity and “burned” precisely because of the loss of backward compatibility. Some of her “left”.
This is critical for a developing platform, engine.

Compiled modules

Compiled modules are a great thing! But it is very dangerous, alas, unstable (in terms of assembly), and even often platform-dependent. Therefore, such a check for the package manager as “avoid modules with compiled libraries” is not enough . Let them be if I give good. But I need to know what those are.
What builds easily on amd64 may not build on Windows and deployment just doesn't work.
This is critical for an engine that positions itself as a cross-platform and abstracting developer from the need to track the platform on which everything is executed.

Documentation

The docks have greatly improved, but in some places holes are still (FS, Zlib, ...). The enumeration of methods and functionality is not documentation, but rather its draft.
Arguments, their types, arguments and types returned in callback functions, fatal errors that are “thrown out” even before calling callback are documentation. I think Gurus can add to this list.
Particular attention should be paid to the fact that the lack of documentation indicates the uncertainty of the authors and developers of the engine that everything will remain so. That means there is no guarantee that this will not change, the types and order of the arguments will not change, etc.
Critically for a project that many developers use, where there is no time to check the behavior, especially in exceptional cases (socket freezing, opening a network file, etc.)

Unstable methods and modules

Whoever comes across fs.watchwill understand what I'm talking about. This begs the execution mode, in which all the executable code will check and display modules or scripts that use unstable methods and / or modules. Since there are patterns that allow circumventing instability, I would like to see them in some annotations in the documentation.
Critical for projects that value reliability.

Conclusion

If you need to rivet a business card site, a small online store, a chat room or a forum, then it is not clear what is missing in Node.js. For USS Enterprise, however, both engines are not suitable for a good score. IO.js has already been written about the pros and, even more recently, about the development of the engine and they, no doubt, should be taken into account.
Given that the engine is developing, actively accepting proposals, I hope the community will help strengthen IOjs.