>This is not a democracy. However, there's plenty of room for >everyone's opinion. If you want to make exciting dramatic breaking >changes to node-core, and you can't find satisfaction by writing >userland npm modules, then please fork joyent/node, give it a new name >and logo, and go as completely crazy as you want.
That's an expected answer but unfair to me and try to explain why. I don't feel confidence that what below is 100% truth. However I am going to tell what I tell just to make sure that the idea is clear. So.. *Forking is not an option* Just because there are people with different background, plans and priorities. One could be very smart, experienced and know exactly how particular part should be structured but still not be able to fork. *Inventor bears responsibility* There are many other platforms: Python, Java, Ruby, .NET... Obviously a novice can't choose the most right for him. He will be able after lots of wasted time and full commitment to one or two of them because Just like in real world the popularity/attractiveness of one particular solution has a little to do with technical perfection and sanity. If someone brings attention to his project and claims it's fun and useful he is responsible for that. The argument "I don't force people to use it" doesn't work like doesn't work the argument of fraudster in front of justice "I didn't forced people to be fooled". I don't think it's fair to be too pedantic about that however the fact exists. *There are not so much insane people* If someone tells that the core API sucks probably it's really sucks and it's fair to try to understand him harder to get his point. Or to let him know that you indeed deeply understand him, learned all his arguments but have in mind something he didn't know and educate about that. There are not so much people not able to understand others and place themselves to other's side. That's all. Regards, Eldar. вторник, 13 августа 2013 г., 21:57:44 UTC+4 пользователь Isaac Schlueter написал: > > There's been a lot of debates, theories, and requests about Node's > core API patterns on this list lately. I'd like to clarify the actual > plans of the project on these points. > > > Callbacks will remain the de facto way to implement asynchrony. > Generators and Promises are interesting and will remain a userland > option. > > Streams are more consistent, faster, and 100% backwards compatible as > of 0.10. The "compatibility mode" aka "old mode" is folded into the > API more cleanly. You can `pause()` a flowing stream, and then start > calling `read()` again safely. We'll keep exposing streams from core > APIs, and advocating extending the stream base classes in userland > programs. > > Domains will be refactored to support more generic > continuation-tracking systems, to enable alternative error-handling > mechanisms in userland. Eventually the Domain module will be a thing > that could be done in userland, but it will continue to be bundled > with the Node binary. > > There will be no changes to the module system. None. It's finished. > It's been finished for over a year. Any proposed changes must come > with a clear reproducible bug that cannot be worked around or > addressed with documentation. > > TypeScript and CoffeeScript will not be added to core. However, as > the module system will remain locked, anything that works today will > keep working. > > A stable C API shim will be added such that binary addons can be > code-stable (and perhaps, binary-stable) across stable branches of > Node for the most common use-cases. Note that the V8 API changed > *significantly* in 0.12, so basically every binary addon is broken > today. Also, it's very difficult to bind to the appropriate > openssl/zlib/c-ares/etc. We're addressing that. > > As new language features are added to V8, they'll make their way into > Node. We have no plans to "auto-enable" any specific flags. Sniff > for what you need, and throw with a helpful error message if it's not > available. > > The VM module is being refactored to bring the features of the > "contextify" module into core, so that contexts work like everyone > expects that they should. Multi-context support is being added to the > VM module API as well. > > Synchronous child process execution is being added, at long last. > > v0.12 is nearing feature completion. Once we get there, we'll be > trying to get everyone to use it. After v0.12, there will probably > not be any API changes before v1.0. Between v0.12 and v1.0, we'll be > focusing on performance, bug fixing, and stability. > > > We are done making breaking changes at the Node.js layer. If your > program runs today, we're doing everything we can to make sure that it > will run next year, albeit faster and more reliably. > > This is not a democracy. However, there's plenty of room for > everyone's opinion. If you want to make exciting dramatic breaking > changes to node-core, and you can't find satisfaction by writing > userland npm modules, then please fork joyent/node, give it a new name > and logo, and go as completely crazy as you want. > > OSS FTW. > -- -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en --- You received this message because you are subscribed to the Google Groups "nodejs" group. To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
