Huge News!Announcing our $40M Series B led by Abstract Ventures.Learn More →
asap-browser
Advanced tools
asap-browser - npm Package Compare versions
Comparing version 2.0.3 to 2.0.4
| { | ||
| "name": "asap-browser", | ||
| "version": "2.0.3", | ||
| "version": "2.0.4", | ||
| "description": "High-priority task queue for Node.js and browsers", | ||
@@ -52,3 +52,3 @@ "keywords": [ | ||
| }, | ||
| "readme": "# ASAP-Browser\n\n**This is a fork of [ASAP](https://github.com/kriskowal/asap) modified to only\nuse the Browser version. This is to work around [Browserify issue #1119](https://github.com/substack/node-browserify/issues/1119).**\n\n[](https://travis-ci.org/kriskowal/asap)\n\nPromise and asynchronous observer libraries, as well as hand-rolled callback\nprograms and libraries, often need a mechanism to postpone the execution of a\ncallback until the next available event.\n(See [Designing API’s for Asynchrony][Zalgo].)\nThe `asap` function executes a task **as soon as possible** but not before it\nreturns, waiting only for the completion of the current event and previously\nscheduled tasks.\n\n```javascript\nasap(function () {\n // ...\n});\n```\n\n[Zalgo]: http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony\n\nThis CommonJS package provides an `asap` module that exports a function that\nexecutes a task function *as soon as possible*.\n\nASAP strives to schedule events to occur before yielding for IO, reflow,\nor redrawing.\nEach event receives an independent stack, with only platform code in parent\nframes and the events run in the order they are scheduled.\n\nASAP provides a fast event queue that will execute tasks until it is\nempty before yielding to the JavaScript engine's underlying event-loop.\nWhen a task gets added to a previously empty event queue, ASAP schedules a flush\nevent, preferring for that event to occur before the JavaScript engine has an\nopportunity to perform IO tasks or rendering, thus making the first task and\nsubsequent tasks semantically indistinguishable.\nASAP uses a variety of techniques to preserve this invariant on different\nversions of browsers and Node.js.\n\nBy design, ASAP prevents input events from being handled until the task\nqueue is empty.\nIf the process is busy enough, this may cause incoming connection requests to be\ndropped, and may cause existing connections to inform the sender to reduce the\ntransmission rate or stall.\nASAP allows this on the theory that, if there is enough work to do, there is no\nsense in looking for trouble.\nAs a consequence, ASAP can interfere with smooth animation.\nIf your task should be tied to the rendering loop, consider using\n`requestAnimationFrame` instead.\nA long sequence of tasks can also effect the long running script dialog.\nIf this is a problem, you may be able to use ASAP’s cousin `setImmediate` to\nbreak long processes into shorter intervals and periodically allow the browser\nto breathe.\n`setImmediate` will yield for IO, reflow, and repaint events.\nIt also returns a handler and can be canceled.\nFor a `setImmediate` shim, consider [YuzuJS setImmediate][setImmediate].\n\n[setImmediate]: https://github.com/YuzuJS/setImmediate\n\nTake care.\nASAP can sustain infinite recursive calls without warning.\nIt will not halt from a stack overflow, and it will not consume unbounded\nmemory.\nThis is behaviorally equivalent to an infinite loop.\nJust as with infinite loops, you can monitor a Node.js process for this behavior\nwith a heart-beat signal.\nAs with infinite loops, a very small amount of caution goes a long way to\navoiding problems.\n\n```javascript\nfunction loop() {\n asap(loop);\n}\nloop();\n```\n\nIn browsers, if a task throws an exception, it will not interrupt the flushing\nof high-priority tasks.\nThe exception will be postponed to a later, low-priority event to avoid\nslow-downs.\nIn Node.js, if a task throws an exception, ASAP will resume flushing only if—and\nonly after—the error is handled by `domain.on(\"error\")` or\n`process.on(\"uncaughtException\")`.\n\n## Raw ASAP\n\nChecking for exceptions comes at a cost.\nThe package also provides an `asap/raw` module that exports the underlying\nimplementation which is faster but stalls if a task throws an exception.\nThis internal version of the ASAP function does not check for errors.\nIf a task does throw an error, it will stall the event queue unless you manually\ncall `rawAsap.requestFlush()` before throwing the error, or any time after.\n\nIn Node.js, `asap/raw` also runs all tasks outside any domain.\nIf you need a task to be bound to your domain, you will have to do it manually.\n\n```js\nif (process.domain) {\n task = process.domain.bind(task);\n}\nrawAsap(task);\n```\n\n## Tasks\n\nA task may be any object that implements `call()`.\nA function will suffice, but closures tend not to be reusable and can cause\ngarbage collector churn.\nBoth `asap` and `rawAsap` accept task objects to give you the option of\nrecycling task objects or using higher callable object abstractions.\nSee the `asap` source for an illustration.\n\n\n## Compatibility\n\nASAP is tested on Node.js v0.10 and in a broad spectrum of web browsers.\nThe following charts capture the browser test results for the most recent\nrelease.\nThe first chart shows test results for ASAP running in the main window context.\nThe second chart shows test results for ASAP running in a web worker context.\nTest results are inconclusive (grey) on browsers that do not support web\nworkers.\nThese data are captured automatically by [Continuous\nIntegration][].\n\n[Continuous Integration]: https://github.com/kriskowal/asap/blob/master/CONTRIBUTING.md\n\n\n\n\n\n## Caveats\n\nWhen a task is added to an empty event queue, it is not always possible to\nguarantee that the task queue will begin flushing immediately after the current\nevent.\nHowever, once the task queue begins flushing, it will not yield until the queue\nis empty, even if the queue grows while executing tasks.\n\nThe following browsers allow the use of [DOM mutation observers][] to access\nthe HTML [microtask queue][], and thus begin flushing ASAP's task queue\nimmediately at the end of the current event loop turn, before any rendering or\nIO:\n\n[microtask queue]: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#microtask-queue\n[DOM mutation observers]: http://dom.spec.whatwg.org/#mutation-observers\n\n- Android 4–4.3\n- Chrome 26–34\n- Firefox 14–29\n- Internet Explorer 11\n- iPad Safari 6–7.1\n- iPhone Safari 7–7.1\n- Safari 6–7\n\nIn the absense of mutation observers, there are a few browsers, and situations\nlike web workers in some of the above browsers, where [message channels][]\nwould be a useful way to avoid falling back to timers.\nMessage channels give direct access to the HTML [task queue][], so the ASAP\ntask queue would flush after any already queued rendering and IO tasks, but\nwithout having the minimum delay imposed by timers.\nHowever, among these browsers, Internet Explorer 10 and Safari do not reliably\ndispatch messages, so they are not worth the trouble to implement.\n\n[message channels]: http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#message-channels\n[task queue]: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task\n\n- Internet Explorer 10\n- Safair 5.0-1\n- Opera 11-12\n\nIn the absense of mutation observers, these browsers and the following browsers\nall fall back to using `setTimeout` and `setInterval` to ensure that a `flush`\noccurs.\nThe implementation uses both and cancels whatever handler loses the race, since\n`setTimeout` tends to occasionally skip tasks in unisolated circumstances.\nTimers generally delay the flushing of ASAP's task queue for four milliseconds.\n\n- Firefox 3–13\n- Internet Explorer 6–10\n- iPad Safari 4.3\n- Lynx 2.8.7\n\n\n## Heritage\n\nASAP has been factored out of the [Q][] asynchronous promise library.\nIt originally had a naïve implementation in terms of `setTimeout`, but\n[Malte Ubl][NonBlocking] provided an insight that `postMessage` might be\nuseful for creating a high-priority, no-delay event dispatch hack.\nSince then, Internet Explorer proposed and implemented `setImmediate`.\nRobert Katić began contributing to Q by measuring the performance of\nthe internal implementation of `asap`, paying particular attention to\nerror recovery.\nDomenic, Robert, and Kris Kowal collectively settled on the current strategy of\nunrolling the high-priority event queue internally regardless of what strategy\nwe used to dispatch the potentially lower-priority flush event.\nDomenic went on to make ASAP cooperate with Node.js domains.\n\n[Q]: https://github.com/kriskowal/q\n[NonBlocking]: http://www.nonblocking.io/2011/06/windownexttick.html\n\nFor further reading, Nicholas Zakas provided a thorough article on [The\nCase for setImmediate][NCZ].\n\n[NCZ]: http://www.nczonline.net/blog/2013/07/09/the-case-for-setimmediate/\n\nEmber’s RSVP promise implementation later [adopted][RSVP ASAP] the name ASAP but\nfurther developed the implentation.\nParticularly, The `MessagePort` implementation was abandoned due to interaction\n[problems with Mobile Internet Explorer][IE Problems] in favor of an\nimplementation backed on the newer and more reliable DOM `MutationObserver`\ninterface.\nThese changes were back-ported into this library.\n\n[IE Problems]: https://github.com/cujojs/when/issues/197\n[RSVP ASAP]: https://github.com/tildeio/rsvp.js/blob/cddf7232546a9cf858524b75cde6f9edf72620a7/lib/rsvp/asap.js\n\nIn addition, ASAP factored into `asap` and `asap/raw`, such that `asap` remained\nexception-safe, but `asap/raw` provided a tight kernel that could be used for\ntasks that guaranteed that they would not throw exceptions.\nThis core is useful for promise implementations that capture thrown errors in\nrejected promises and do not need a second safety net.\nAt the same time, the exception handling in `asap` was factored into separate\nimplementations for Node.js and browsers, using the the [Browserify][Browser\nConfig] `browser` property in `package.json` to instruct browser module loaders\nand bundlers, including [Browserify][], [Mr][], and [Mop][], to use the\nbrowser-only implementation.\n\n[Browser Config]: https://gist.github.com/defunctzombie/4339901\n[Browserify]: https://github.com/substack/node-browserify\n[Mr]: https://github.com/montagejs/mr\n[Mop]: https://github.com/montagejs/mop\n\n## License\n\nCopyright 2009-2014 by Contributors\nMIT License (enclosed)\n", | ||
| "readme": "# ASAP-Browser\n\n**This was a fork of [ASAP](https://github.com/kriskowal/asap) modified to only\nuse the Browser version. This was to work around [Browserify issue \n#1119](https://github.com/substack/node-browserify/issues/1119), but \nthat issue has been fixed upstream, so there's no longer a need for \nthis module. Please switch back to ASAP. This fork will not be \nmaintained.**\n\n[](https://travis-ci.org/kriskowal/asap)\n\nPromise and asynchronous observer libraries, as well as hand-rolled callback\nprograms and libraries, often need a mechanism to postpone the execution of a\ncallback until the next available event.\n(See [Designing API’s for Asynchrony][Zalgo].)\nThe `asap` function executes a task **as soon as possible** but not before it\nreturns, waiting only for the completion of the current event and previously\nscheduled tasks.\n\n```javascript\nasap(function () {\n // ...\n});\n```\n\n[Zalgo]: http://blog.izs.me/post/59142742143/designing-apis-for-asynchrony\n\nThis CommonJS package provides an `asap` module that exports a function that\nexecutes a task function *as soon as possible*.\n\nASAP strives to schedule events to occur before yielding for IO, reflow,\nor redrawing.\nEach event receives an independent stack, with only platform code in parent\nframes and the events run in the order they are scheduled.\n\nASAP provides a fast event queue that will execute tasks until it is\nempty before yielding to the JavaScript engine's underlying event-loop.\nWhen a task gets added to a previously empty event queue, ASAP schedules a flush\nevent, preferring for that event to occur before the JavaScript engine has an\nopportunity to perform IO tasks or rendering, thus making the first task and\nsubsequent tasks semantically indistinguishable.\nASAP uses a variety of techniques to preserve this invariant on different\nversions of browsers and Node.js.\n\nBy design, ASAP prevents input events from being handled until the task\nqueue is empty.\nIf the process is busy enough, this may cause incoming connection requests to be\ndropped, and may cause existing connections to inform the sender to reduce the\ntransmission rate or stall.\nASAP allows this on the theory that, if there is enough work to do, there is no\nsense in looking for trouble.\nAs a consequence, ASAP can interfere with smooth animation.\nIf your task should be tied to the rendering loop, consider using\n`requestAnimationFrame` instead.\nA long sequence of tasks can also effect the long running script dialog.\nIf this is a problem, you may be able to use ASAP’s cousin `setImmediate` to\nbreak long processes into shorter intervals and periodically allow the browser\nto breathe.\n`setImmediate` will yield for IO, reflow, and repaint events.\nIt also returns a handler and can be canceled.\nFor a `setImmediate` shim, consider [YuzuJS setImmediate][setImmediate].\n\n[setImmediate]: https://github.com/YuzuJS/setImmediate\n\nTake care.\nASAP can sustain infinite recursive calls without warning.\nIt will not halt from a stack overflow, and it will not consume unbounded\nmemory.\nThis is behaviorally equivalent to an infinite loop.\nJust as with infinite loops, you can monitor a Node.js process for this behavior\nwith a heart-beat signal.\nAs with infinite loops, a very small amount of caution goes a long way to\navoiding problems.\n\n```javascript\nfunction loop() {\n asap(loop);\n}\nloop();\n```\n\nIn browsers, if a task throws an exception, it will not interrupt the flushing\nof high-priority tasks.\nThe exception will be postponed to a later, low-priority event to avoid\nslow-downs.\nIn Node.js, if a task throws an exception, ASAP will resume flushing only if—and\nonly after—the error is handled by `domain.on(\"error\")` or\n`process.on(\"uncaughtException\")`.\n\n## Raw ASAP\n\nChecking for exceptions comes at a cost.\nThe package also provides an `asap/raw` module that exports the underlying\nimplementation which is faster but stalls if a task throws an exception.\nThis internal version of the ASAP function does not check for errors.\nIf a task does throw an error, it will stall the event queue unless you manually\ncall `rawAsap.requestFlush()` before throwing the error, or any time after.\n\nIn Node.js, `asap/raw` also runs all tasks outside any domain.\nIf you need a task to be bound to your domain, you will have to do it manually.\n\n```js\nif (process.domain) {\n task = process.domain.bind(task);\n}\nrawAsap(task);\n```\n\n## Tasks\n\nA task may be any object that implements `call()`.\nA function will suffice, but closures tend not to be reusable and can cause\ngarbage collector churn.\nBoth `asap` and `rawAsap` accept task objects to give you the option of\nrecycling task objects or using higher callable object abstractions.\nSee the `asap` source for an illustration.\n\n\n## Compatibility\n\nASAP is tested on Node.js v0.10 and in a broad spectrum of web browsers.\nThe following charts capture the browser test results for the most recent\nrelease.\nThe first chart shows test results for ASAP running in the main window context.\nThe second chart shows test results for ASAP running in a web worker context.\nTest results are inconclusive (grey) on browsers that do not support web\nworkers.\nThese data are captured automatically by [Continuous\nIntegration][].\n\n[Continuous Integration]: https://github.com/kriskowal/asap/blob/master/CONTRIBUTING.md\n\n\n\n\n\n## Caveats\n\nWhen a task is added to an empty event queue, it is not always possible to\nguarantee that the task queue will begin flushing immediately after the current\nevent.\nHowever, once the task queue begins flushing, it will not yield until the queue\nis empty, even if the queue grows while executing tasks.\n\nThe following browsers allow the use of [DOM mutation observers][] to access\nthe HTML [microtask queue][], and thus begin flushing ASAP's task queue\nimmediately at the end of the current event loop turn, before any rendering or\nIO:\n\n[microtask queue]: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#microtask-queue\n[DOM mutation observers]: http://dom.spec.whatwg.org/#mutation-observers\n\n- Android 4–4.3\n- Chrome 26–34\n- Firefox 14–29\n- Internet Explorer 11\n- iPad Safari 6–7.1\n- iPhone Safari 7–7.1\n- Safari 6–7\n\nIn the absense of mutation observers, there are a few browsers, and situations\nlike web workers in some of the above browsers, where [message channels][]\nwould be a useful way to avoid falling back to timers.\nMessage channels give direct access to the HTML [task queue][], so the ASAP\ntask queue would flush after any already queued rendering and IO tasks, but\nwithout having the minimum delay imposed by timers.\nHowever, among these browsers, Internet Explorer 10 and Safari do not reliably\ndispatch messages, so they are not worth the trouble to implement.\n\n[message channels]: http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html#message-channels\n[task queue]: http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#concept-task\n\n- Internet Explorer 10\n- Safair 5.0-1\n- Opera 11-12\n\nIn the absense of mutation observers, these browsers and the following browsers\nall fall back to using `setTimeout` and `setInterval` to ensure that a `flush`\noccurs.\nThe implementation uses both and cancels whatever handler loses the race, since\n`setTimeout` tends to occasionally skip tasks in unisolated circumstances.\nTimers generally delay the flushing of ASAP's task queue for four milliseconds.\n\n- Firefox 3–13\n- Internet Explorer 6–10\n- iPad Safari 4.3\n- Lynx 2.8.7\n\n\n## Heritage\n\nASAP has been factored out of the [Q][] asynchronous promise library.\nIt originally had a naïve implementation in terms of `setTimeout`, but\n[Malte Ubl][NonBlocking] provided an insight that `postMessage` might be\nuseful for creating a high-priority, no-delay event dispatch hack.\nSince then, Internet Explorer proposed and implemented `setImmediate`.\nRobert Katić began contributing to Q by measuring the performance of\nthe internal implementation of `asap`, paying particular attention to\nerror recovery.\nDomenic, Robert, and Kris Kowal collectively settled on the current strategy of\nunrolling the high-priority event queue internally regardless of what strategy\nwe used to dispatch the potentially lower-priority flush event.\nDomenic went on to make ASAP cooperate with Node.js domains.\n\n[Q]: https://github.com/kriskowal/q\n[NonBlocking]: http://www.nonblocking.io/2011/06/windownexttick.html\n\nFor further reading, Nicholas Zakas provided a thorough article on [The\nCase for setImmediate][NCZ].\n\n[NCZ]: http://www.nczonline.net/blog/2013/07/09/the-case-for-setimmediate/\n\nEmber’s RSVP promise implementation later [adopted][RSVP ASAP] the name ASAP but\nfurther developed the implentation.\nParticularly, The `MessagePort` implementation was abandoned due to interaction\n[problems with Mobile Internet Explorer][IE Problems] in favor of an\nimplementation backed on the newer and more reliable DOM `MutationObserver`\ninterface.\nThese changes were back-ported into this library.\n\n[IE Problems]: https://github.com/cujojs/when/issues/197\n[RSVP ASAP]: https://github.com/tildeio/rsvp.js/blob/cddf7232546a9cf858524b75cde6f9edf72620a7/lib/rsvp/asap.js\n\nIn addition, ASAP factored into `asap` and `asap/raw`, such that `asap` remained\nexception-safe, but `asap/raw` provided a tight kernel that could be used for\ntasks that guaranteed that they would not throw exceptions.\nThis core is useful for promise implementations that capture thrown errors in\nrejected promises and do not need a second safety net.\nAt the same time, the exception handling in `asap` was factored into separate\nimplementations for Node.js and browsers, using the the [Browserify][Browser\nConfig] `browser` property in `package.json` to instruct browser module loaders\nand bundlers, including [Browserify][], [Mr][], and [Mop][], to use the\nbrowser-only implementation.\n\n[Browser Config]: https://gist.github.com/defunctzombie/4339901\n[Browserify]: https://github.com/substack/node-browserify\n[Mr]: https://github.com/montagejs/mr\n[Mop]: https://github.com/montagejs/mop\n\n## License\n\nCopyright 2009-2014 by Contributors\nMIT License (enclosed)\n", | ||
| "readmeFilename": "README.md", | ||
@@ -55,0 +55,0 @@ "bugs": { |
New alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Fixed alerts
License Policy Violation
LicenseThis package is not allowed per your license policy. Review the package's license to ensure compliance.
Found 1 instance in 1 package
Improved metrics
- Total package byte prevSize
- increased by0.35%
44791
No dependency changes