|The Future of Programming in Node.js||Isaac Schlueter||8/13/13 10:57 AM|
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
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
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
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
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.
|Re: The Future of Programming in Node.js||Isaac Schlueter||8/13/13 10:58 AM|
To clarify one point:
What I mean is, v0.12 is 100% backwards compatible to v0.10.
|Re: The Future of Programming in Node.js||Bert Belder||8/13/13 12:15 PM|
Agree that not breaking node apps and modules is a good thing. However, as long as node is relevant, we shouldn´t stop innovating.
* People might have found some 'pain killer' patterns to deal with callback hell. However that doesn't mean there isn't a real solution for this.
* Error handling sucks. There's gigantic room for improvement here.
* What happened to the original dream that node would run in a network of nodes, which would together make up your app? This was really sort of the justification for coming up with a programming model that uses only on one cpu/core. Nowadays to do this you have to hand-roll everything yourself and node does nothing.
A 5 minute brainstorm would probably yield a dozen more things.
So me and StrongLoop intend to keep working on improving it. It may be called node or it may not.
|Re: The Future of Programming in Node.js||Radford Smith||8/13/13 2:24 PM|
On Tuesday, August 13, 2013 10:57:44 AM UTC-7, Isaac Schlueter wrote:
Is the old mode to be used only with old libraries that rely on it, or is it a subset of the new functionality? Does it still make sense to say `on('data', ...)` when we're just consuming things off the stream one by one?
|Re: The Future of Programming in Node.js||Michaël Rouges||8/13/13 2:25 PM|
See my topic, about the yielded style programming... and say goodbye to the callback hell. ;)
|Re: The Future of Programming in Node.js||Isaac Schlueter||8/13/13 2:29 PM|
On Tue, Aug 13, 2013 at 12:15 PM, Bert Belder <bertb...@gmail.com> wrote:When and if a clear winner arises from userland, if it can be merged
into core without breaking backwards compatibility, then we can
consider it. You and I have had that conversation before, and I'm
sure we'll keep having it :)
Yes, I expect that we'll see interesting things by exposing the
continuation-tracking mechanisms and making Domains less baked-in.
Lots of people are doing this now. (Walmart, stackvm, Joyent, and the
npm website all come to mind.)
Currently that is called "StrongLoop Node Distribution". This is a
paradigmatic example of what "userland" is for.
Yes, that is fine. It is a subset of the new functionality. In 0.10,
using `on('data')` triggers a permanent switch to
pause()/resume()/on('data') mode. In v0.12, adding a data listener
starts the flow, but it's not a permanent modal switch. Streams3 is
thus a relatively straightforward refinement of the intent of
|Re: The Future of Programming in Node.js||Eldar||8/13/13 2:50 PM|
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.
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.
вторник, 13 августа 2013 г., 21:57:44 UTC+4 пользователь Isaac Schlueter написал:
|Re: The Future of Programming in Node.js||Nathan Fritz||8/13/13 3:01 PM|
These two points are in conflict with each other. Either there's critical mass for forking or there is not.
|Re: [nodejs] Re: The Future of Programming in Node.js||Mark Hahn||8/13/13 3:01 PM|
> If someone tells that the core API sucks probably it's really sucks
Not true. When someone (or even a few) say it sucks and no one agrees then he is usually wrong.
|Re: [nodejs] Re: The Future of Programming in Node.js||Mikeal Rogers||8/13/13 3:07 PM|
There will always be people who don't like a particular decision in the core API.
There are problems/bugs that are being fixed and there are others that are unlikely to change in core because they would break compatibility (which node can no longer tolerate).
In the end, all of this mailing list complaining doesn't really amount to anything. While several of the most vocal people here put their code where their mouth is and maintain libraries for alternatives to node's core patterns most of the people who complain here contribute very little and the overwhelming number of people who are producing growth in the ecosystem don't say anything here, they're busy writing code.
For every person that complains on this mailing list about an API there are a hundred libraries written to that API by people who are making the ecosystem and the platform successful.
Criticism is necessary to move the project forward but it's a mistake to think that criticism in and of itself is somehow indicative of any specific failure. With success comes criticism, we're unlikely to see an end to it any time soon.
As much as you might think Isaac should spend his time listening to people who are vocal here he has a great ear for the silent masses building the world's fastest growing ecosystem as well as the people deploying very large scale solutions entirely on node.js.
|Re: The Future of Programming in Node.js||Bruno Jouhier||8/13/13 3:17 PM|
What matters most to me at this stage is:
* Backward compatibilty
* Backward compatibility
* Backward compatibility
* New platforms (AIX would be cool but we can do without).
TCP/IP will still be TCP/IP
HTTP will also still be HTTP
files and directories will continue to be files and directories.
So if node continues to be node, I'll be happy!
Creativity is for userland. We found creative solutions to all our showstopper problems so the last thing I want is creative experiments in core that may destabilize or impact performance. I don't think we used much new features from core since 0.6 anyway.
There are probably things that could be improved in core (like streams API) but as the saying goes, Perfect is the enemy of Good!
|Re: The Future of Programming in Node.js||Rouan van der Ende||8/13/13 3:29 PM|
Thank you Isaac, and all node contributors.
I am glad the focus is now on refinement and longevity in a non-breaking way. You mention performance improvement and I am curious how much there is left to squeeze out and where do you think the gains are to be made?
|Re: [nodejs] Re: The Future of Programming in Node.js||Bruno Jouhier||8/13/13 3:40 PM|
Sure. Always follow the majority rule! Even if you think it sucks, it really doesn't!
"Suddenly, I do not know how, it happened, I did not have time to think, Panurge, without another word, threw his sheep, crying and bleating, into the sea. All the other sheep, crying and bleating in the same intonation, started to throw themselves in the sea after it, all in a line. The herd was such that once one jumped, so jumped its companions. It was not possible to stop them, as you know, with sheep, it's natural to always follow the first one, wherever it may go." --Francois Rabelais, Quart Livre, chapter VIII
|Re: [nodejs] Re: The Future of Programming in Node.js||Nuno Job||8/13/13 3:42 PM|
While I agree with the sentiment in most of this email I would argue Streams are not backward compatible. There's an effort so that what was coded in 0.8 still works in 0.10, but it's impossible to code things that work in both 0.8 and 0.10 without different code. Might seem minor, but since I found this in the crypto api i would argue it's something that should be tackled. As we reach newer versions of node 0.8 compatibility will be less of a problem, but fore now most production systems are in 0.8 or 0.6 and this has delayed people adopting 0.10. By having less people use newer versions, it also makes maturity take longer.
Error handling does suck but in all honesty it seems to suck everywhere but erlang. It does suck a bit more in node tbh.
As for those who say "forking is not an option" — I would argue it's the only option. It's super common practice for companies to keep a private fork of a OS product. If someone chooses to do a "different node" I'm sure that by now there would be adoption. Actually someone already did that in a sense, meteorjs. The downsides are fragmenting an ecosystem but the upside is vaster, since it's normally a symptom of huge success in a os product (e.g. linux distros)
Thanks Isaac and the Node team to keep honest to the ethos of Nodejs. As a user I appreciate knowing what to expect from you guys. I'm sure companies feel the same way when they rely on the product to do business. If you are looking for commercial alternatives to accommodate your needs, there's a few out there. Reach out to them and see what they can do for you.
|Re: [nodejs] Re: The Future of Programming in Node.js||Mark Hahn||8/13/13 3:42 PM|
> Sure. Always follow the majority rule!
I wasn't saying anything about what action to take. I was just stating a statistical fact.
|Re: [nodejs] The Future of Programming in Node.js||Rick Waldron||8/13/13 4:00 PM|
I'd be interested in seeing the data your referencing.
|Re: [nodejs] The Future of Programming in Node.js||Mark Hahn||8/13/13 4:27 PM|
> I'd be interested in seeing the data your referencing.
Ok, a statistical assumption based on experience. If a lot of people say it sucks then it probably sucks. If just a few say so then it probably doesn't.
I've been reading this discussion group religiously for over two years and I've not heard about things in node sucking before today.
To post to this group, send email to nod...@googlegroups.comnodejs+un...@googlegroups.com
|Re: [nodejs] The Future of Programming in Node.js||Stephen Belanger||8/13/13 4:46 PM|
I've heard people complaining about things in node sucking pretty much since day 1, but then complaints are usually louder than compliments.
|Re: [nodejs] Re: The Future of Programming in Node.js||// ravi||8/13/13 6:15 PM|
On Aug 13, 2013, at 6:07 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:> <snip happens>
>If “criticism is necessary to move the project forward” then how can it be that “all of this mailing list complaining doesn’t really amount to anything”? I think your last part is quite right (that criticism, especially the “you suck” variety, is par for the course) but the first part paints all speakers with a broad reactionary brush.
P.S: Personally, I appreciate the philosophy outlined in the first part of Isaac’s message and what I know/see of the history of Node (through my novice eyes). I wish require.paths had not been removed and that certain aspects of npm/node_modules structure were different (both of which I have wrapped around), but those are minor issues, and I have no complaints.
|Re: [nodejs] Re: The Future of Programming in Node.js||Arunoda Susiripala||8/13/13 6:50 PM|
I agree with Issacs and Bert.
We should have node as it is. Error handling and callbacks are sucks. (for most/some of the people).
But still we build apps.
As bert said, we need solutions for those problems. Fibers, promises does a good job. It need to be better. Meteor is a good example, which tries to solve some pain in nodejs. And it is not node. Something else.
|Re: The Future of Programming in Node.js||Andrew Kelley||8/13/13 8:14 PM|
I'm glad that people like Isaacs are leading the charge here instead of some of these wild opinions being thrown about on this list.
I think that I speak for a silent majority when I say that I honestly don't understand why people say that callbacks are the root of all evil. Callbacks are amazingly convenient. They're simple to understand, simple to use, and have surprisingly effective abstraction power.
|Re: [nodejs] Re: The Future of Programming in Node.js||Isaac Schlueter||8/13/13 9:44 PM|
On Tue, Aug 13, 2013 at 3:42 PM, Nuno Job <nunojo...@gmail.com> wrote:Yes, that's why I posted the followup, explaining that I meant "as of
v0.10, streams are going to remain backwards compatible". Meaning,
streams3 is mostly indistinguishable from streams2, except that it
fixes some of the irregularity and some weird edge cases, and is
When I speak in the present-tense about Node, I usually mean "The
version that hasn't been released yet" (ie, v0.12). When most people
speak in the present tense about Node, they mean "The stable branch
that came before the current release" (ie, v0.8).
It's all about where your head's at. Working on a platform, you tend
to live a bit in the future of that platform :)
|Re: The Future of Programming in Node.js||John Kennedy||8/13/13 9:45 PM|
Root of all evil is not the exact term I would use, but they do make writing decoupled code that is testable, and easy to read and maintain more difficult than when using alternatives such as promises.
I think the complaints stem more from the superiority of the alternatives to the status quo than they do from any truly demonic attributes of callbacks.
That said, I agree with the approach outlined here. Once there is a clear winner in userland, bring it into core. Until then, roll your own.
|Re: The Future of Programming in Node.js||Trevor Norris||8/13/13 11:33 PM|
On Tuesday, August 13, 2013 3:29:12 PM UTC-7, Rouan van der Ende wrote:
To put it simply, a lot and everywhere. Two main points:
1) v8 is constantly evolving and each release contains little surprises that allow us to do things better and more efficiently.
2) Now that core is stabilizing it easier to see how the internal mechanisms can be improved. Trust me we have no shortage of performance improvements we're working on, and you should expect them to be coming for a while.
|Re: The Future of Programming in Node.js||Vladimir Varankin||8/13/13 11:35 PM|
Any mention about changes in HTTP core module? A couple of months ago you (Isaac) had a talk where you said that there are some rooms (and plans) for rewriting HTTP core-module as well as current Buffer implementation.
And the second question is about NPM. Are there similar long running plans for it?
|Re: The Future of Programming in Node.js||Trevor Norris||8/14/13 12:00 AM|
On Tuesday, August 13, 2013 11:35:11 PM UTC-7, Vladimir Varankin wrote:
The new Buffer implementation is done. Has been since April for master, but it'll never reach v0.10.
|Re: [nodejs] Re: The Future of Programming in Node.js||Fedor Indutny||8/14/13 1:56 AM|
Another flame war here :) Obviously, stability is good. There're definitely some problems in core that worth fixing, but lets do a big 1.0 release first ;)
|Re: The Future of Programming in Node.js||Floby||8/14/13 2:25 AM|
Hello, I'm the silent minority and I heartily endorse this event and/or product.
|Re: The Future of Programming in Node.js||Bert Belder||8/14/13 3:52 AM|
I don't feel any heat. I don't think that anyone could reasonably disagree with Isaac.
It's just that the strong emphasis on "node is done" concerned me a bit. IMO it's not, although some future directions might warrant a name change. Nobody knows at this point.
But Node 1.0 is definitely done.
Yes, and I agree that this is not the time.
It's just that I don't want to shut that door forever, and I actually don't mind people discussing it on the mailing list, as long as they understand that it's not going into core soon (at least, not before 1.0) and it might never.
(Also bringing up these topics in unrelated conversations is kind of annoying and people should refrain from that. Hello Michaël Rouges, we can all read the topic index ourselves, thanks.)
I'll hold my breath (proverbially) until the conference season starts again.
And how's the experience been so far?
In comparison to developing and running a single-process app, this quite super difficult and the experience is bad.
I don't think StrongLoop Node Distribution is going to be a playground for experimental core features, but we can think of something else.
But let's be fair here. If "userland" and "fork" are the answer, why are people so mad about meteor?
It's also a matter of culture. If the suggestion is to fork, then we shouldn't berate people for doing it afterwards.
|Re: The Future of Programming in Node.js||Isaac Schlueter||8/14/13 8:54 AM|
> But let's be fair here. If "userland" and "fork" are the answer, why areOh, I'm not mad about meteor being a fork. As far as I've seen,
they've done nothing towards Node that is unsporting or rude.
I have criticisms about how they've gone about building a community,
of course. That is, in several ways, I think meteor is Doing It
Wrong, but that doesn't mean that it's bad or anger-inducing, beyond
the typical "People are wrong on the internet!" reaction.
Specifically, their module/package system is basically the exact
opposite of the design decisions in npm, which I believe have been
essential to Node's ecosystem scaling to the size it is now.
Meteor has (last I checked, anyway) a "single point of curation" model
for publishing modules, which drastically limits how fast they can
grow a community, and thus how relevant they can ever become. By not
retaining compatibility with the huge, growing, prolific OSS Node
community, they're leaving a lot of functionality on the table. (I'm
sure that someone on this list will probably point out the programs
out there that meteor-ize npm modules, and others that de-meteor-ize
your meteor program into a standard Node program, but my point is,
it's not compatible by default.)
In the spirit of "may the best platform win", yes, I'd like to see
someone do what meteor is doing *better*, and take advantage of the
ways in which meteor is sub-optimal. But the team seems to be a bunch
of really smart and dedicated people, and they are delighting users.
So, even if they are leaving a lot of potential behind, out-meteoring
meteor will still be a tough task.
|Re: [nodejs] Re: The Future of Programming in Node.js||Arunoda Susiripala||8/14/13 9:11 AM|
A note on meteor.
I've played a bit with meteor and things are not so bad.
meteor's package system is different from NPM. But it has a reason. Since those packages need to have content/code related to both client and the server.
There is no official NPM like tool/service for meteor. But there is something called meteorite(cmd tool) and atmosphere(app registry) which hosts community powered packages. It is maintained by the community. It is quite small but growing.
If you need to use a npm module with meteor, it is little bit hard. But there are some good work arounds.
meteor's packaging system is so powerful and allow maximum power to the developer. I've changed meteor's realtime engine but I never had to fork meteor.
Meteor is not bad a thing for node or to the community. It is something different.
|Re: [nodejs] Re: The Future of Programming in Node.js||Chris G||8/15/13 5:11 AM|
I'm extremely novice to node.js, which for me has been an intimidating framework. But Meteor pulled me in and introduced me to Node (and MongoDB) in a way I felt was less intimidating somehow. In this way, I see Meteor as complementing Node. Though this is just my own personal experience, I'd wager to bet that my experience is not unique.
Arunoda: keep doing what you do... I follow you closely and respect your contribution. Furthermore, I learn so much from you!
|Re: The Future of Programming in Node.js||Eric Elliott||8/15/13 3:39 PM|
> > * What happened to the original dream that node would run in a network of
You can add Adobe to the list, and so far I've found that there are trade-offs, but it's similar to building any service-oriented architecture. You get the advantage of reducing complexity by breaking a problem into smaller parts, but the additional overhead of managing more separate projects. Deciding where to dice things up and how is the hardest part, probably, but those decisions tend to get easier as your projects progress. New services (nodes, if you prefer) tend to suggest themselves. Performance implications also come into play -- do your different components need to communicate in a manner that would be major bottlenecks over IPC or across network lines? Maybe those modules should run in the same process.
I still think this is valuable advice: Don't build a large application. Build lots of small ones, instead.
Node makes that pretty easy.
|Re: [nodejs] Re: The Future of Programming in Node.js||Brian Lalor||8/15/13 4:13 PM|
On Aug 15, 2013, at 6:39 PM, Eric Elliott <dil...@gmail.com> wrote:I'll agree with that. I'm building an application that's been reduced to a number of small pieces, connected via zeromq. I'd really like to see zmq get more love in the node community; it's a great tool.
|Re: The Future of Programming in Node.js||Lucio M. Tato||8/20/13 7:14 PM|
I've recently created something with the same intentions (say goodbye to the callback hell), but simpler and based on Fibers.
What if... Fibers and wait.for where part of node core?
then you can deprecate almost half the functions at: http://nodejs.org/api/fs.html (clue: the Sync versions)
On Tuesday, August 13, 2013 6:25:06 PM UTC-3, Michaël Rouges wrote: