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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 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

37 sources
You should do some measurement before calling it an improvement. If you read the ECMAScript standard[1] or this blog post from V8[2] about the inner workings of the `await` keyword, you would know even if you `await` a non-Promise value, it would still create a new Promise and put the suspended routine onto the microtask queue. So the change you made won't make a difference. Besides, there is a JavaScript language feature that can give you finer control on routine suspension and resumption, decoupled from any of the microtask or macrotask queue. It's called the generator function. There are some good coroutine libraries based on generator functions, e.g. co.js[3] and redux-saga[4]. You can easily make something similar that can resume the suspended routine according to your scheduling policy that prioritize main thread rendering. [1]: htt
Read the rest
In Main-Thread-Scheduling
This isn't an issue if you're using promises. You can use try/catch from within async functions and it works exactly as you'd expect. A few years before async functions were available you could also achieve the same thing with generators. In fact, the original release of koa used co [0] under the hood. I'll note my response is written with koa middleware in mind. I haven't kept up much with express, although I think it should be possible to achieve the same thing since they also support async functions. With koa you can add a middleware that wraps all downstream middleware in a try/catch: app.use(async (ctx, next) => { try { await next() } catch (error) { // handle errors } }) [0] https://github.com/tj/co
In Node.js Logging Made Right
This is essentially how modern JavaScript works, in particular with the addition of async/await syntax [1] (which was originally from C#, I think), but it's been possible with libraries like task.js, co, and Bluebird [2] since generator functions were available (either natively or via transpiling). The main difference is in JavaScript the event loop is automatic and hidden, and asynchronous IO is the default, so it's a bit harder to shoot yourself in the foot. 1. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... 2. https://github.com/mozilla/task.js https://github.com/tj/co http://bluebirdjs.com/docs/api/promise.coroutine.html
In The magic of asyncio explained
> Playing the "what color is your function" game or "will it block" is no fun. This was quite painful with.js Node 1-2yrs back when Promises and coroutines started picking up steam [such as https://github.com/tj/co]. It was always a shot in the dark. Has this situation changed now? (basically is the stdlib all async friendly now?)
In Why I’m Learning Perl 6
You have a number of ways of keeping a handle on async code now. 1. Native ES6 promises will cover most of your basic needs. See https://developer.mozilla.org/en/docs/Web/JavaScript/Referen.... In fact, unless you have very specific needs not covered by native promises, you shouldn't drop a third party library into your project. 2. For more advanced operations on promises, use Bluebird. See http://bluebirdjs.com and http://bluebirdjs.com/docs/api-reference.html. It has a ton of features built on top of native ES6 promises. If you're using an older version of Node, it also acts as a polyfill. It can also make it easy to work with libraries that only expose a callback-based interface. So yeah, Bluebird is the shit. 3. co is a generator-based control flow library that can make your async code look more like synchronous code. It's pretty coo
Read the rest
l, but I haven't personally used it in a project, nor do I know of anyone else who uses it. It builds on top of promises and generators, and isn't very hard to understand under the hood. See https://github.com/tj/co. I wouldn't recommend it, but it might be something to play with because ... 4. ... async/await is coming to JavaScript! At a very high level, this pair of keywords is syntax sugar for what co already does as a library. This is the final stage in the evolution of taming callback hell in JavaScript, and it builds on top of everything that has come before (promises and generators). Here's a tutorial: https://blog.risingstack.com/async-await-node-js-7-nightly/
In Node v7.5.0 Released
I very much like this model, but I wonder how necessary it is when we have IcedCoffeescript [1], ES6 generators + co [2], and ES7 async/await [3] as viable ways of managing async control flow within mostly synchronous-looking code, all as dialects of languages that have strong adoption. I actually think generators + co is a really strong model. Async/await gives you a slight bit of sugar, but I've realized that if you stick with generators, you can wrap your generators to allow you to `yield` more than just promises, effectively giving you something like (untyped) scoped continuations [4]. [1] https://maxtaco.github.io/coffee-script/ [2] https://github.com/tj/co [3] http://masnun.com/2015/11/11/using-es7-asyncawait-today-with... [4] http://blog.paralleluniverse.co/2015/08/07/scoped-continuati...
In Pogoscript – a compile-to-JS language that emphasises concurrency, readability
Does this offer any benefits over building coroutine functions with generators? The "co" library (and probably some others) do this. https://github.com/tj/co It seems mostly like a syntactical difference to me - with coroutines you "yield" instead of "await." You can still wrap things nicely in try{} catch{} blocks. But the readme for co does mention that it's a stepping stone towards async/await. I like that ES7 will allow us to write this style of function without including an additional library, but apart from that, is there a big gap in functionality between the different approaches?
In Taming the asynchronous beast with ES7

Showing the 15 most recent of 37 sources. Enable JavaScript to search and browse every indexed mention.

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.