HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tj
co
JavaScript2013–2024
tj / co

co

The ultimate generator based flow-control goodness for nodejs (supports thunks, promises, etc)

33Distinct people
37Mentions
0Explicit recommenders
11.8KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The ultimate generator based flow-control goodness for nodejs (supports thunks, promises, etc)

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year37 dated mentions

Observed mentions: 2013-06-06 15:14:50 UTC to 2024-01-05 18:56:36 UTC.

0510152013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 7 mentions; 2 submissions, 5 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 14 mentions; 0 submissions, 14 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC725
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC14014
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC808
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC202
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC000
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
co Generator based control flow goodness for nodejs and the browser, using promises, letting you write non-blocking code in a nice-ish way. Co v4 co@4.0.0 has been released, which now relies on promises. It is a stepping stone towards the async/await proposal. The primary API change is how co() is invoked. Before, co returned a "thunk", which you then called with a callback and optional arguments. Now, co() returns a promise. co(function* () { var result = yield Promise.resolve(true); return result; }).then(function (value) { console.log(value); }, function (err) { console.error(err.stack); }); If you want to convert a co-generator-function into a regular function that returns a promise, you now use co.wrap(fn*). var fn = co.wrap(function* (val) { return yield Promise.resolve(val); }); fn(true).then(function (val) { }); Platform Compatibility co@4+ requires a Promise implementation. For versions of node < 0.11 and for many older browsers, you should/must include your own Promise polyfill. When using node 0.10.x and lower or browsers without generator support, you must use gnode and/or regenerator. When using node 0.11.x, you must use the --harmony-generators flag or just --harmony to get access to generators. Node v4+ is supported out of the box, you can use co without flags or polyfills. Installation $ npm install co Associated libraries Any library that returns promises work well with co. mz - wrap all of node's code libraries as promises. View the wiki for more libraries. Examples var co = require('co'); co(function *(){ // yield any promise var result = yield Promise.resolve(true); }).catch(onerror); co(function *(){ // resolve multiple promises in parallel var a = Promise.resolve(1); var b = Promise.resolve(2); var c = Promise.resolve(3); var res = yield [a, b, c]; console.log(res); // => [1, 2, 3] }).catch(onerror); // errors can be try/catched co(function *(){ try { yield Promise.reject(new Error('boom')); } catch (err) { console.error(err.message); // "boom" } }).catch(onerror); function onerror(err) { // log any uncaught errors // co will not throw any errors you do not handle!!! // HANDLE ALL YOUR ERRORS!!! console.error(err.stack); } Yieldables The yieldable objects currently supported are: promises thunks (functions) array (parallel execution) objects (parallel execution) generators (delegation) generator functions (delegation) Nested yieldable objects are supported, meaning you can nest promises within objects within arrays, and so on! Promises Read more on promises! Thunks Thunks are functions that only have a single argument, a callback. Thunk support only remains for backwards compatibility and may be removed in future versions of co. Arrays yielding an array will resolve all the yieldables in parallel. co(function* () { var res = yield [ Promise.resolve(1), Promise.resolve(2), Promise.resolve(3), ]; console.log(res); // => [1, 2, 3] }).catch(onerror); Objects Just like arrays, objects resolve all yieldables in parallel. co(function* () { var res = yield { 1: Promise.resolve(1), 2: Promise.resolve(2), }; console.log(res); // => { 1: 1, 2: 2 } }).catch(onerror); Generators and Generator Functions Any generator or generator function you can pass into co can be yielded as well. This should generally be avoided as we should be moving towards spec-compliant Promises instead. API co(fn*).then( val => ) Returns a promise that resolves a generator, generator function, or any function that returns a generator. co(function* () { return yield Promise.resolve(true); }).then(function (val) { console.log(val); }, function (err) { console.error(err.stack); }); var fn = co.wrap(fn*) Convert a generator into a regular function that returns a Promise. var fn = co.wrap(function* (val) { return yield Promise.resolve(val); }); fn(true).then(function (val) { }); License MIT
Read the full README on GitHub

What Hacker News says

14 sources
Okay. But Promises already provide asynchronous try/catch blocks, and you could have used those as the basis of your API (and as first-class objects that get returned), rather than inventing a new API and set of objects. > I believe that flow control in the future will be done with generators; check out https://github.com/visionmedia/co for example. Generators and promises are both types of flow control that will be used in the future: they're both in the ES6 standard. In fact, visionmedia/co already supports promises.
In Zones – Robust error handling and flow control for Node.js
I'm sorry if it wasn't clear enough from the blog, but the attempt here is not to write a flow control library that solves the callback hell problem like promises does. You should think of it more as an asynchronous try-catch block, where resources created in the "try" block are automaticially cleaned up. I believe that flow control in the future will be done with generators; check out https://github.com/visionmedia/co for example.
In Zones – Robust error handling and flow control for Node.js
Another upcoming method to avoid callback hell that is my personal favorite is harmony generators and yield. Reminds me so much of C# async. Two great libraries can handle it today on beta versions of node [1,2]. I have only used suspend. See this gist for comparison https://gist.github.com/codystebbins/a2c354d25ce28879bfe1. With generators try/catch can be used, avoiding a lot of the redundant error handling. Crabdude's library can avoid the overhead of try/catch [3]. And if developers want static typing, they should check out TypeScript. Works great with node. [1] https://github.com/jmar777/suspend [2] https://github.com/visionmedia/co [3] https://github.com/CrabDude/trycatch
In Why Node.js is becoming the go-to technology in the Enterprise
This is tangential to the discussion, here, but if you want to make 3 simultaneous async requests, it's super easy with promises. Here's an example using bluebird (https://github.com/petkaantonov/bluebird): Promise.all([async1, async2, async3]).then(function(results) { console.log('async1:', results[0]); console.log('async2:', results[1]); console.log('async3:', results[2]); }); or: Promise.all([async1, async2, async3]).spread(function(res1, res2, res3) { console.log('async1:', res1); console.log('async2:', res2); console.log('async3:', res3); }); With the co library (https://github.com/visionmedia/co), it'd look like this: co(function*() { var results = yield [async1, async2, async3]; console.log('async1:', results[0]); console.log('async2:', results[1]); console.log('async3:', results[
Read the rest
2]); })(); Until ES6 is available everywhere, the existing promises libraries are so mature and easy-to-use that I don't really see a problem with them. Bluebird will even promisify an entire module for you with `promisifyAll`, so mixing it with callback-based modules is typically trivial. I think that even though it relies on the use of third-party libraries like co, the generators solution is much easier to reason about than the proposed solution here. I can't find the source, unfortunately, but I remember reading somewhere that generators were actually designed with this use case in mind, so the claim that using them for async "requires hacking a language feature that was designed for an entirely different use-case" is false, if I'm remembering correctly.
In Better JavaScript Promises
> Unfortunately, using yield based solution will require third party libraries, which means increased payload and incompatibilities among frameworks. Check out co (https://github.com/visionmedia/co/blob/master/index.js). For all its features it's tiny. Increased payload and incompatibility is a blanket statement; that could apply to any library or framework. > And I am also quite disappointed that the solution to one of JavaScripts biggest flaws requires hacking a language feature that was designed for an entirely different use-case, which will surely bring lots of confusion. There should be a really high bar for adding keywords to a language. If something can be solved with features we already have, we needn't add another. ES6 generators solves the callback problem for now. There are of course other (perhaps more flexible) solutions, lik
Read the rest
e Scala's futures and for-comprehensions [1], or F# computation expressions [2]. But generators are simpler and they work well enough. [1] http://docs.scala-lang.org/overviews/core/futures.html [2] http://fsharpforfunandprofit.com/series/computation-expressi...
In Better JavaScript Promises
> Seems you have misunderstood how it works. https://github.com/visionmedia/co/blob/master/index.js No. > Typically in apps using 'co', functions will return generators, not promises. Promises were probably added because of all the existing code out there. Again, generators in and of themselves don't do anything (for async code). Something needs to be generated/yielded, and that thing is the reification of an asynchronous operation. Such as a promise[0]. Generators and promises fulfil different roles, generators are used as imperative "sugar" for chaining promises. The generators you yield will ultimately resolve into a series of async operations (promises or "thunks"), yielding a generator is convenience (not very useful convenience either, since `yield*` exists the ability to yield generators just complexifies the driver) [0] and in the
Read the rest
case of co a "thunk"[1], because node
In An open question (rant) about Node.js
Seems you have misunderstood how it works. https://github.com/visionmedia/co/blob/master/index.js Typically in apps using 'co', functions will return generators, not promises. Promises were probably added because of all the existing code out there. Here is a file from my ongoing project, should explain how generators are being used. See getPosts() or addPost() https://github.com/jeswin/fora/blob/master/server/src/models... [Edit: Just read your earlier (Gr.GP) comment. Might want to avoid the unnecessary snark, especially when there's a chance you might be wrong.]
In An open question (rant) about Node.js
There is no performance reason to make developers hand-code in the continuation-passing style. node certainly recognizes this. However, there is no need to do anything here since JS is taking care of this with ES6. Even if you don't want to use ES6, there are now multiple ways to compile it down to ES5. Hence the slowly rising mindshare of Promises Promises are declining, and honestly doesn't really solve the problem in most cases. A couple of years from now, you won't see promises on the server. You should see tjholowaychuk/visionmedia's co[1]; that's how JS is going to look like in future. In terms of expressiveness, there isn't much to choose between dynamic languages. While it took some getting used to, programming JS wasn't that different from writing Python. However, JS/node is succeeding because this is the first time ever that we
Read the rest
have a language/platform that is truly write-once, run-anywhere. A significant advantage in favor of node. [1] https://github.com/visionmedia/co
In An open question (rant) about Node.js

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.