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://node
On Aug 15, 2013, at 6:39 PM, Eric Elliott 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, c
> > * 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 c
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
w
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. B
> 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'v
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 rea
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 t
Hello, I'm the silent minority and I heartily endorse this event and/or
product.
On Tuesday, 13 August 2013 19:57:44 UTC+2, Isaac Schlueter wrote:
>
> 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
> pl
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.
On Wed, Aug 14, 2013 at 11:00 AM, Trevor Norris wrote:
> On Tuesday, August 13, 2013 11:35:11 PM UTC-7, Vladimir Var
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.
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
f
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 an
On Tue, Aug 13, 2013 at 3:42 PM, Nuno Job 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
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 amazi
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 t
On Aug 13, 2013, at 6:07 PM, Mikeal Rogers 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 o
> Sure. Always follow the majority rule!
I wasn't saying anything about what action to take. I was just stating a
statistical fact.
On Tue, Aug 13, 2013 at 3:40 PM, Bruno Jouhier wrote:
>
> Not true. When someone (or even a few) say it sucks and no one agrees
>> then he is usually wrong.
>>
>
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 foun
> 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
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?
On Tuesday, 13 August 2013 19:57:
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).
J
>
>
> *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.
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-
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 li
> 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.
On Tue, Aug 13, 2013 at 2:50 PM, Eldar wrote:
> >This is not a democracy. However, there's plenty of room for
> >everyone's opi
>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 complete
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
> callin
On Tue, Aug 13, 2013 at 12:15 PM, Bert Belder 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 breakin
See my topic, about the yielded style programming... and say goodbye to the
callback hell. ;)
--
--
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
Grou
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
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.
On Tue, Aug 13, 2013 at 10:57 AM, Isaac Schlueter wrote:
> There's been a lot of debates, theories, and requests about Node'
31 matches
Mail list logo
