IO.js or old rake with new sauce

“It is finished! Node.js was developed in the form of fork io.js! Hi ES6! Hello new V8! ”Developers rejoiced. It is useful to look with the hope that now, starting from scratch, the guys have corrected the fundamental jambs!

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

backward compatibility

No, it's not about compatibility with node.js, but talking about the lack of guarantees that after the “next” update of the engine core, something will not fall off. JAVA gives such a guarantee, let a lot of methods be considered deprecated and the compiler will start to swear, however the code written on the 2nd Java works in the 7th and 8th, and we know that it will work in further. Or, C ++ and GCC paths are possible: compile with an indication of which standard to rely on. Also partly there are no guarantees at the level of documentation (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 great! But very dangerous, alas, unstable (in terms of assembly), and even often platform-dependent. Therefore, there is a lack of such a check for a package manager, like “avoid modules with compiled libraries”. Let it be, if I give good. But I need to know that there are any.
The fact that it is easy to assemble on amd64 may not be built on Windows and the deployment simply will not work.
This is critical for the engine, which positions itself as a cross-platform and abstractive developer from the need to track the platform on which everything is executed.

Documentation

The docks have greatly improved, but in some places there are still holes (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” before calling a callback are already documentation. I think Gurus can add to this list.
Particular attention should be paid to the fact that the lack of documentation indicates the lack of confidence of the authors and developers of the engine that everything will remain so. So there are no guarantees that this will not change, the types and order of the arguments will not change, etc.
Critical for a project that is used by many developers, where there is no time to check the behavior, especially in exceptional cases (socket hang, open network file, etc.)

Unstable methods and modules

Who faced fs.watch will understand what I'm talking about. The execution mode suggests itself, in which all the run code will check and output modules or scripts that use unstable methods and / or modules. Since there are templates that allow to bypass 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, chat, or a forum, it’s not clear what is missing in Node.js. For USS Enterprise, both engines are not suitable for a good account. I have already written about the advantages of IO.js, and even quite recently about the development of the engine and they, undoubtedly, should be taken into account.
Given that the engine is developing, actively accepting proposals, I hope that the community will help strengthen IOjs.