HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
kriskowal
q
JavaScript2010–2016
kriskowal / q · Archived

q

A promise library for JavaScript

44Distinct people
51Mentions
0Explicit recommenders
15KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

A promise library for JavaScript

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, 5:04:57 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 year51 dated mentions

Observed mentions: 2010-09-16 15:45:55 UTC to 2016-10-16 22:21:59 UTC.

051015202010-01-01 00:00:00 UTC to 2011-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20102011-01-01 00:00:00 UTC to 2012-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2012-01-01 00:00:00 UTC to 2013-01-01 00:00:00 UTC (exclusive): 14 mentions; 2 submissions, 12 comments2013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 22 mentions; 0 submissions, 22 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 9 mentions; 0 submissions, 9 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2016

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
20102010-01-01 00:00:00 UTC2011-01-01 00:00:00 UTC101
20112011-01-01 00:00:00 UTC2012-01-01 00:00:00 UTC101
20122012-01-01 00:00:00 UTC2013-01-01 00:00:00 UTC14212
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC22022
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC909
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC303
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101

From the project README

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

Read the project’s introduction
Note Please consider using JavaScript promises instead of Q. Native promises are faster, have better tooling support and are the future. When work on Q began, promises were an academic novelty in JavaScript, unlikely to be adopted much less popular, though obviously full of…promise. Callbacks dominated the landscape. Q aimed to introduce a technology to JavaScript that had been proven and vetted in languages like E and C♯. With four years of incubation, evangelism, education, and feedback, promises became part of the language. Every modern browser contains a built-in Promise implementation. Being able to influence the internet and working on a library used by millions of codebases was an exciting and humbling experience. Q isn't going anywhere. The code is still here and bugs will be fixed but further development has been unnecessary for many years. We encourage you to read the code and the explainers to glimpse into the history of the internet. Q If a function cannot return a value or throw an exception without blocking, it can return a promise instead. A promise is an object that represents the return value or the thrown exception that the function may eventually provide. A promise can also be used as a proxy for a remote object to overcome latency. On the first pass, promises can mitigate the “Pyramid of Doom”: the situation where code marches to the right faster than it marches forward. step1(function (value1) { step2(value1, function(value2) { step3(value2, function(value3) { step4(value3, function(value4) { // Do something with value4 }); }); }); }); With a promise library, you can flatten the pyramid. Q.fcall(promisedStep1) .then(promisedStep2) .then(promisedStep3) .then(promisedStep4) .then(function (value4) { // Do something with value4 }) .catch(function (error) { // Handle any error from all above steps }) .done(); With this approach, you also get implicit error propagation, just like try, catch, and finally. An error in promisedStep1 will flow all the way to the catch function, where it’s caught and handled. (Here promisedStepN is a version of stepN that returns a promise.) The callback approach is called an “inversion of control”. A function that accepts a callback instead of a return value is saying, “Don’t call me, I’ll call you.”. Promises un-invert the inversion, cleanly separating the input arguments from control flow arguments. This simplifies the use and creation of API’s, particularly variadic, rest and spread arguments. Getting Started The Q module can be loaded as: A <script> tag (creating a Q global variable): ~2.5 KB minified and gzipped. A Node.js and CommonJS module, available in npm as the q package An AMD module A component as microjs/q Using bower as q#^1.4.1 Using NuGet as Q Q can exchange promises with jQuery, Dojo, When.js, WinJS, and more. Resources Our wiki contains a number of useful resources, including: A method-by-method Q API reference. A growing examples gallery, showing how Q can be used to make everything better. From XHR to database access to accessing the Flickr API, Q is there for you. There are many libraries that produce and consume Q promises for everything from file system/database access or RPC to templating. For a list of some of the more popular ones, see Libraries. If you want materials that introduce the promise concept generally, and the below tutorial isn't doing it for you, check out our collection of presentations, blog posts, and podcasts. A guide for those coming from jQuery's $.Deferred. We'd also love to have you join the Q-Continuum mailing list. Tutorial Promises have a then method, which you can use to get the eventual return value (fulfillment) or thrown exception (rejection). promiseMeSomething() .then(function (value) { }, function (reason) { }); If promiseMeSomething returns a promise that gets fulfilled later with a return value, the first function (the fulfillment handler) will be called with the value. However, if the promiseMeSomething function gets rejected later by a thrown exception, the second function (the rejection handler) will be called with the exception. Note that resolution of a promise is always asynchronous: that is, the fulfillment or rejection handler will always be called in the next turn of the event loop (i.e. process.nextTick in Node). This gives you a nice guarantee when mentally tracing the flow of your code, namely that then will always return before either handler is executed. In this tutorial, we begin with how to consume and work with promises. We'll talk about how to create them, and thus create functions like promiseMeSomething that return promises, below. Propagation The then method returns a promise, which in this example, I’m assigning to outputPromise. var outputPromise = getInputPromise() .then(function (input) { }, function (reason) { }); The outputPromise variable becomes a new promise for the return value of either handler. Since a function can only either return a value or throw an exception, only one handler will ever be called and it will be responsible for resolving outputPromise. If you return a value in a handler, outputPromise will get fulfilled. If you throw an exception in a handler, outputPromise will get rejected. If you return a promise in a handler, outputPromise will “become” that promise. Being able to become a new promise is useful for managing delays, combining results, or recovering from errors. If the getInputPromise() promise gets rejected and you omit the rejection handler, the error will go to outputPromise: var outputPromise = getInputPromise() .then(function (value) { }); If the input promise gets fulfilled and you omit the fulfillment handler, the value will go to outputPromise: var outputPromise = getInputPromise() .then(null, function (error) { }); Q promises provide a fail shorthand for then when you are only interested in handling the error: var output
Read the full README on GitHub

What Hacker News says

51 sources
>If using threads means the language is asynchronous to you, Goroutines are not threads. It's named after a "coroutine," which is an async function (like a generator) where you can pause execution of a task (to wait for IO, for instance) and then resume it at a later time. Coroutines give you implicit async/await style programming, without having to use extra keywords. The language Lua supports coroutines natively, for instance, including explicit yields to use them as generators, if you need. Goroutines give you coroutines with a bonus: Actual thread hopping (and multiple channels of communication possible, so you can effectively have more than one "yield" channel). If you have 400,000 Goroutines running on 4 CPUs, your Goroutines can task switch between those 4 CPUs using 4 OS threads (or 8, or whatever number you determine is best for
Read the rest
your app) as their IO events queue up. It is async, and each Goroutine has around 10k of RAM overhead, not counting data you're storing yourself (it varies by architecture, but that's a reasonable estimate; I've seen between 6k and 16k on different architectures). Go is better async than JavaScript, because a Goroutine started on one thread can get processed on another, so a few thread-hogs won't block a task. A single Goroutine could cycle between all your worker threads, in fact, though I think it tends to stick with a single worker thread ("thread affinity"). It's probably the most asynchronous you can get in a language (only the Erlang VM/Elixir is in the same class of language, as far as I know). Do you think PHP could handle 400,000 concurrent WebSocket connections on one server? Go can. How much RAM would you need to handle 400,000 CPU threads? Maybe 64Gb instead of ~8Gb in Go? Wouldn't CPU switching alone be starving most of the threads and redlining the CPU at that point? In my experience you start seeing serious slowdown around 5,000 threads. I'd guess you'd need 50x as many servers to handle that many connections on PHP. Maybe 100x. You need to support a million users? Is it better to have 3 servers or 300? > The things you complained about in another language were fixed/removed years ago but you say it's still just as bad. PHP is architecturally single-thread-per-request. Full stop. Even PHP 7 and HHVM. That simply doesn't scale as well as async, as I described above. The complaints I made were why I bailed on it years ago. I'm sure PHP has gotten a lot better than it was when I used it, but given that it still misses the mark architecturally, I have zero motivation to give it a second chance. But given that NodeJS has far surpassed it in community support (as well as by many performance measures -- HHVM is quite fast at raw processing speed now, though not as high throughput because of the lack of true async), why is PHP still relevant except to continue to maintain existing code bases? (I've worked with several of those as well -- Joomla and Drupal in particular -- and neither was something I'd consider worth using, having looked at their internals and terrible performance. Joomla was a complete disaster; Drupal only slightly better.) >Every failure or less than great situation in your favoured languages has just been fixed in the last few years. Your point? Even if they all were only better as of yesterday, they're still better. Or are you defending your choice of a few years ago? And actually, Promises have been available using polyfills for years. The proposal was made at least six years ago; I can't find the exact date, but I found a reference added to the CommonJS wiki in 2010 [1]. The Q library dates back to 2010 as well. [2] I concede that there may have been a period of time where PHP was better than JavaScript, by the criteria I'm using today, because PHP did improve a lot after I first encountered it, while JavaScript only more recently developed its compelling advantages. It looks like Node was released in 2009? In 2009 I was using OpenResty (Nginx+Lua) to do my (small amount of) server work, which can still be more performant than both Node and PHP. But NodeJS has shot past in terms of community support, which is critical, TypeScript is awesome, sharing code on client and server is awesome, isomorphic rendering is awesome, and performance is good enough (compared to Lua) that NodeJS just wins for me, big time. Except when I need the extra speed, and for that I use Go. Go is a brand new language, relatively speaking. So of course they're still making major improvements. Performance has already surpassed HHVM, even for raw compute tasks. It's a better fundamental architecture, giving it an edge, and performance will likely improve still more, though they're already hitting diminishing returns: Some of the worst case performance they see now may get 2x-4x faster, but typical app performance is probably only 10-20% short of optimal. I mean, they're already beating C++ on the server. How much better can they go? Use whatever language you want; if your background and/or current job is PHP, so be it. It's not as bad as it was 10 years ago, for certain. Just don't expect anyone to pick it up based on its merits. There are too many other, stronger options available today. [1] http://wiki.commonjs.org/wiki/Promises/A [2] https://github.com/kriskowal/q/graphs/contributors
In PHP 7 deployment at Dailymotion
"Asynchronous event-driven programming is at the heart of Node.js, however it is also the root cause of Callback Hell." I'd argue the root cause is... callbacks. Asynchronous programming can be done elegantly, in a synchronous style using "async/await", originally (?) in C# [1], likely to be added to the next version of JavaScript [2], also in Dart [2], Hack [4], and Python 3.5 [5]. It can also be emulated in languages with coroutines/generators [6][7][8] (which in turn can be implemented by a fairly simple transpiler [9][10]) This: function foo(a, callback) { bar(a, function(err, b) { if (err) { callback(err) } else { baz(b, function(err, c) { if (err) { callback(err) } else { // some more stuff callback(null, d)
Read the rest
In Node.js: Cluster vs. Async
It's honestly not as much of an issue as it's often made out to be. There are a ton of ways to manage asynchronous code out there including but not limited to all the various promise libraries such as when.js(https://github.com/cujojs/when), q (https://github.com/kriskowal/q), and bluebird (https://github.com/petkaantonov/bluebird). Not to mention the Async library (https://github.com/caolan/async) which is full of tools to help manage it. As for blocking, it's something you deal with. Realistically speaking if you're doing CPU intensive tasks then Node is definitely the wrong solution. However, if you're doing tasks that are IO oriented then Node is fantastic.
In Yahoo Mail moving to React
It's actually a very little function I wrote, based on `tee` Unix shell command: http://unixhelp.ed.ac.uk/CGI/man-cgi?tee It looks like this: tee = (func, val) --> func(val); val which could be equivalently written as: tee = (func) -> (val) -> func(val); val In other words it's an identity function which additionally executes some other function for side-effects. In the shell the `tee` command always writes to the file, while my version can execute any side-effect, but I think my version is just a generalization of the standard Unix command and so I named it like this. I'm sure this function has its own, formal name, with the word "monad" or "combinator" (maybe K combinator?) in it, but I wasn't patient enough to research it :) `thenResolve` is a standard method on a promise object implemented by the Q library (https://github.co
Read the rest
m/kriskowal/q/wiki/API-Reference#promisethe...) I used, it's equivalent to .then () -> accum In other words, `thenResolve` appends a success callback which discards previous value and always returns another value. Once again, take a look at the full source at http://klibert.pl/walkfiles.html - I'm going to update it with a full explanation of what's going on, but even right now it's only 90 lines with including comments, and should be a good example of main LS strengths. I'm probably going to write another example which makes use of even more (and more advanced) LS features when I'm done with explaining this one.
In Pun: A small library to enable pattern matching in JavaScript and CoffeeScript
The comparison page highlights that Zone.js is better than promises because of long stack traces [1], but most promise implementations already have that [2]. I'm confused, that seems to be the only comparison to promises. Edit: Conceptually it seems the same as promises. The main difference seems to be that they've added hooks [3] into the pipeline, and they duck punch the core API to intercept errors. Bluebird has solved this without duck punching using `Promise.promisifyAll(require("fs"))` [4]. I would love to see a write up on Zone.js's forks, because the article could of trivially been rewriten to use promises. [1] http://strongloop.com/strongblog/comparing-node-js-promises-... [2] https://github.com/kriskowal/q#long-stack-traces [3] https://github.com/btford/zone.js/#zonefork [4] https://github.com/petkaantonov/bluebird
In Zones – Robust error handling and flow control for Node.js
Your example illustrates the problem nicely. The code above is impossible to parse without knowing that "future" is a special value. Note that after you assign `a = future` you have no idea that a is special. Separate the code into three modules: the first contains lines 1 and 2, the second contains line 3 and the third contains lines 4 and 5. Now, looking at the second module you have no idea if the execution blocks on `console.log(a,b);` or not. More importantly, even if all the code is written as nicely as the example above you still cannot reason about this like you could about every other goddamn language out there. You can't pick arbitrary lines of code from the listing and execute them in that order, and if you try to figure out how it works (even if it's written without deadlocks) you will break your brain. Instead, let's somethin
Read the rest
g like $q [1], or even just the smaller/simpler AngularJS implementation of it [2]. While requiring callbacks, it's still very workable and does simplify things. Adding chained callbacks is very nice: var resp = $.get('/my/url'); showLoadingScreen(); resp.then(function(data) { return JSON.parse(data); } resp.then(function(data) { alert('data.username = ' + data.username); } resp.catch(function(err) { alert('Error: ' + err); }) resp.finally(function() { hideLoadingScreen(); }) [1] https://github.com/kriskowal/q/wiki/API-Reference [2] https://docs.angularjs.org/api/ng/service/$q
In Better JavaScript Promises
Because technologies like Q [1] and streams [2] provide a very abstractions around doing long-running tasks asynchronously, which jives better with node's entire philosophy. Combine that with the fact that running multiple processes is a perfectly viable way to do actual long-running tasks and node provides abstractions around that out of the box, and it really starts to look like fibers and webworkers in node are patchy hold-overs for technologists who haven't fully changed into thinking about things in "the node way." [1] https://github.com/kriskowal/q [2] https://github.com/substack/stream-handbook
In Why does it seem like threading and fibers in Node have been abandoned?

Showing the 15 most recent of 51 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.