-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does io.js address the problems that TJ Holochuck expressed? #399
Comments
Error handling and callback complains could be partially solved once/if API will be more Promise-oriented. |
Actually, TJ preferred the use of generators for a lot of this stuff. Generators are only available in latest stable Node.js if you re-compile so you can see why he was/is quite frustrated. io.js 1.0.0 has generators by default without even so much as a flag :) |
I think those "problems" cannot be solved anymore in core and stay compliant with npm in the same time. npm + node so big ecosystem and it will be broken if core will be changed to solve problem of callbacks and error handling. |
We actually have a much better idea about how to responsible add small breaking changes to core now, and we have a versioning scheme that helps as well, so I think we can address the "meta" concern that core can't be changed. Some of his concerns about debugging remain but asyncwrap is a step towards solving them. Honestly though, you have to take what TJ said with a grain of salt. TJ is extremely prolific, which is great for everyone else but it also means that he uses almost no code he didn't write himself. The largest benefit of using this platform over something like Go is the ecosystem. For early adopters like TJ, who showed up when virtually nothing was already available, this matters a lot less than the kinds of users we attract nowadays. |
Is it any chance to take a look on it? Or it is not published yet? |
It's sort of buried in the TC calls, which are all public but laborious to go through. Mention is made often to deprecating certain modules and features and thoughts about how to increment the version responsibly in order to do so. |
It would be great to have some sort of guides when this happens like: Idea is to give users some upgrade path so they can stay up-to-date with latest APIs without too much efforts. |
@YuriSolovyov that is the plan for deprecation of the |
@mikeal is that a general strategy for any breaking changes, not only deprecations? |
@YuriSolovyov no, many breaking changes can't be done that way. for instance, v8 might break the C++ API and there isn't much we can do about it other than bump the major version number, but we will be bumping the version number properly according to semver. |
Seems like "performance over usability" was something he complained the most about, where "usability" meant not just that callback-structured code is painful to write and maintain, but lack of language-level guarantees about if/when/how many times callbacks are called.
So I think with those two things io.js is on a path to become more like what TJ wanted (but was too impatient to wait for). |
Great thread, interesting read. Thank you for this. |
Feel free to continue the discussion, but I'm going to close this issue as it's not really actionable. |
Hello.
Just a question really, does this io.js project aim to address some of the problems that TJ Holowaychuk expressed in his Farewell Node.js post? https://medium.com/code-adventures/farewell-node-js-4ba9e7f3e52b
The text was updated successfully, but these errors were encountered: