The Future of Programming in Node.js

35,296 views
Skip to first unread message

Isaac Schlueter

unread,
Aug 13, 2013, 1:57:44 PM8/13/13
to nodejs
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.

Isaac Schlueter

unread,
Aug 13, 2013, 1:58:37 PM8/13/13
to nodejs
To clarify one point:

>>>
Streams are more consistent, faster, and 100% backwards compatible as
of 0.10.
>>>

What I mean is, v0.12 is 100% backwards compatible to v0.10.

Bert Belder

unread,
Aug 13, 2013, 3:15:40 PM8/13/13
to nod...@googlegroups.com, i...@izs.me


Agree that not breaking node apps and modules is a good thing. However, as long as node is relevant, we shouldn´t stop innovating.

I mean,

* 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.

- Bert

Radford Smith

unread,
Aug 13, 2013, 5:24:17 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
On Tuesday, August 13, 2013 10:57:44 AM UTC-7, Isaac Schlueter wrote:

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.

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?

Michaël Rouges

unread,
Aug 13, 2013, 5:25:06 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
See my topic, about the yielded style programming... and say goodbye to the callback hell. ;)

Isaac Schlueter

unread,
Aug 13, 2013, 5:29:07 PM8/13/13
to Bert Belder, nodejs
On Tue, Aug 13, 2013 at 12:15 PM, Bert Belder <bertb...@gmail.com> wrote:
> * 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.

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 :)


> * Error handling sucks. There's gigantic room for improvement here.

Yes, I expect that we'll see interesting things by exposing the
continuation-tracking mechanisms and making Domains less baked-in.


> * What happened to the original dream that node would run in a network of
> nodes, which would together make up your app?

Lots of people are doing this now. (Walmart, stackvm, Joyent, and the
npm website all come to mind.)


> So me and StrongLoop intend to keep working on improving it. It may be
> called node or it may not.

Currently that is called "StrongLoop Node Distribution". This is a
paradigmatic example of what "userland" is for.


On Tue, Aug 13, 2013 at 2:24 PM, Radford Smith <rads...@gmail.com> 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?

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
streams2.

Eldar

unread,
Aug 13, 2013, 5:50:05 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
>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 написал:

Nathan Fritz

unread,
Aug 13, 2013, 6:01:54 PM8/13/13
to nod...@googlegroups.com, i...@izs.me

Forking is not an option
There are not so much insane people

These two points are in conflict with each other. Either there's critical mass for forking or there is not.

Mark Hahn

unread,
Aug 13, 2013, 6:01:30 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
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.

--
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@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+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Mikeal Rogers

unread,
Aug 13, 2013, 6:07:42 PM8/13/13
to nod...@googlegroups.com
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.

-Mikeal

Bruno Jouhier

unread,
Aug 13, 2013, 6:17:40 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
What matters most to me at this stage is:

* Robustness
* Robustness
* Robustness
* Robustness
* Robustness
* Performance
* Performance
* Performance
* Performance
* Backward compatibilty
* Backward compatibility
* Backward compatibility
* New platforms (AIX would be cool but we can do without).

JavaScript will remain compatible with what it is today and will just get better.
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!

Bruno

Rouan van der Ende

unread,
Aug 13, 2013, 6:29:12 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
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?

Bruno Jouhier

unread,
Aug 13, 2013, 6:40:37 PM8/13/13
to nod...@googlegroups.com, i...@izs.me

Not true.  When someone (or even a few) say it sucks and no one agrees then he is usually wrong.

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

Nuno Job

unread,
Aug 13, 2013, 6:42:37 PM8/13/13
to nod...@googlegroups.com, Isaac Schlueter
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.

Nuno


Mark Hahn

unread,
Aug 13, 2013, 6:42:53 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
Sure. Always follow the majority rule! 

I wasn't saying anything about what action to take.  I was just stating a statistical fact.

--

Rick Waldron

unread,
Aug 13, 2013, 7:00:39 PM8/13/13
to nod...@googlegroups.com, i...@izs.me


On Tuesday, August 13, 2013, Mark Hahn wrote:
Sure. Always follow the majority rule! 

I wasn't saying anything about what action to take.  I was just stating a statistical fact.

I'd be interested in seeing the data your referencing.

Rick 

Mark Hahn

unread,
Aug 13, 2013, 7:27:18 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
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.

Stephen Belanger

unread,
Aug 13, 2013, 7:46:34 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
I've heard people complaining about things in node sucking pretty much since day 1, but then complaints are usually louder than compliments.

// ravi

unread,
Aug 13, 2013, 9:15:44 PM8/13/13
to nod...@googlegroups.com
On Aug 13, 2013, at 6:07 PM, Mikeal Rogers <mikeal...@gmail.com> wrote:
>
> 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.
> <snip happens>
>
> 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.


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.

—ravi


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.


> 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.
>
> -Mikeal
>
> On Aug 13, 2013, at 2:50PM, Eldar <elda...@gmail.com> wrote:
>
>> 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.
>
>

Arunoda Susiripala

unread,
Aug 13, 2013, 9:50:14 PM8/13/13
to nod...@googlegroups.com
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.

Andrew Kelley

unread,
Aug 13, 2013, 11:14:56 PM8/13/13
to nod...@googlegroups.com, i...@izs.me
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.

Isaac Schlueter

unread,
Aug 14, 2013, 12:44:14 AM8/14/13
to Nuno Job, nodejs
On Tue, Aug 13, 2013 at 3:42 PM, Nuno Job <nunojo...@gmail.com> wrote:
> 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.

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
faster.

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 :)

John Kennedy

unread,
Aug 14, 2013, 12:45:50 AM8/14/13
to nod...@googlegroups.com, i...@izs.me
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.

Trevor Norris

unread,
Aug 14, 2013, 2:33:07 AM8/14/13
to nod...@googlegroups.com, i...@izs.me
On Tuesday, August 13, 2013 3:29:12 PM UTC-7, Rouan van der Ende wrote:
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?

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.

Vladimir Varankin

unread,
Aug 14, 2013, 2:35:11 AM8/14/13
to nod...@googlegroups.com, i...@izs.me
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?

Trevor Norris

unread,
Aug 14, 2013, 3:00:36 AM8/14/13
to nod...@googlegroups.com, i...@izs.me
On Tuesday, August 13, 2013 11:35:11 PM UTC-7, Vladimir Varankin wrote:
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.

The new Buffer implementation is done. Has been since April for master, but it'll never reach v0.10.

Fedor Indutny

unread,
Aug 14, 2013, 4:56:50 AM8/14/13
to nod...@googlegroups.com, Isaac Schlueter
Yikes!

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 ;)

Cheers,
Fedor.


--

Floby

unread,
Aug 14, 2013, 5:25:13 AM8/14/13
to nod...@googlegroups.com, i...@izs.me
Hello, I'm the silent minority and I heartily endorse this event and/or product.

Bert Belder

unread,
Aug 14, 2013, 6:52:05 AM8/14/13
to nod...@googlegroups.com, Bert Belder, i...@izs.me

On Wednesday, August 14, 2013 10:56:50 AM UTC+2, Fedor Indutny wrote:
> Yikes!
> 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 ;)

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.

On Tuesday, August 13, 2013 11:29:07 PM UTC+2, Isaac Schlueter 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, 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.)

> > * Error handling sucks. There's gigantic room for improvement here. 
> Yes, I expect that we'll see interesting things by exposing the 
> continuation-tracking mechanisms and making Domains less baked-in. 

Hopefully :)
I'll hold my breath (proverbially) until the conference season starts again.

> > * What happened to the original dream that node would run in a network of 
> > nodes, which would together make up your app? 
> Lots of people are doing this now.  (Walmart, stackvm, Joyent, and the 
> npm website all come to mind.) 

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.

> > So me and StrongLoop intend to keep working on improving it. It may be 
> > called node or it may not. 
> Currently that is called "StrongLoop Node Distribution".  This is a 
> paradigmatic example of what "userland" is for. 

Alright :)
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.

- Bert

Isaac Schlueter

unread,
Aug 14, 2013, 11:54:29 AM8/14/13
to Bert Belder, nodejs
> 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.

Oh, 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.

Arunoda Susiripala

unread,
Aug 14, 2013, 12:11:41 PM8/14/13
to nod...@googlegroups.com, Bert Belder
Hi Issacs, 

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.



--
--
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 nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@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+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Chris G

unread,
Aug 15, 2013, 8:11:19 AM8/15/13
to nod...@googlegroups.com, Bert Belder
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!

Eric Elliott

unread,
Aug 15, 2013, 6:39:43 PM8/15/13
to nod...@googlegroups.com, Bert Belder, i...@izs.me
> > * What happened to the original dream that node would run in a network of 
> > nodes, which would together make up your app? 
> Lots of people are doing this now.  (Walmart, stackvm, Joyent, and the 
> npm website all come to mind.) 

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.

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.

Brian Lalor

unread,
Aug 15, 2013, 7:13:31 PM8/15/13
to nod...@googlegroups.com, nod...@googlegroups.com, Bert Belder, i...@izs.me
On Aug 15, 2013, at 6:39 PM, Eric Elliott <dil...@gmail.com> wrote:

> I still think this is valuable advice: Don't build a large application. Build lots of small ones, instead.
>
> Node makes that pretty easy.

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.

Lucio M. Tato

unread,
Aug 20, 2013, 10:14:06 PM8/20/13
to nod...@googlegroups.com, i...@izs.me
I've recently created something with the same intentions (say goodbye to the callback hell), but simpler and based on Fibers.

https://github.com/luciotato/waitfor

Teaser...

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)

Example:

pure node.js:

var fs = require("fs");

fs.readFile('/etc/passwd', function (err, data) {
    if (err) throw err;
    console.log(data);
});

using wait.for:

var fs = require("fs"), wait=require('wait.for');
// in a fiber...
console.log(wait.for(fd.readfile,'/etc/passwd'));

On Tuesday, August 13, 2013 6:25:06 PM UTC-3, Michaël Rouges wrote:
See my topic, about the yielded style programming... and say goodbye to the callback hell. ;)
Reply all
Reply to author
Forward
0 new messages