0

Its hard to make good understanding with JavaScript promises. Even i did lot of googling not clear with it. Its great to show me the right way on promises.

My questions are

  1. are promises are native and spawn additional threads like ajax?
  2. there are lots of libraries like q , deferred are there. are they all wrappers for native JavaScript promise API?
  3. If a browser vendor does not implement native asynchronous promises , how these libraries can spawn thread?
Vignesh
  • 496
  • 1
  • 4
  • 13

1 Answers1

2
  1. are promises are native and spawn additional threads like ajax?

JavaScript is single threaded so ajax doesn't spawn additional threads and neither do promises. The code executes once the system that's running your code, calls the callback/handler code.

If you want to do actual multi-threading in JS, check out Service Workers

  1. there are lots of libraries like q , deferred are there. are they all wrappers for native JavaScript promise API?

Very broad question, but considering Promises are pretty much widely available now, chances are most libraries use them. Some, like BlueBird, do not use them and actually outperform native promises.

  1. If a browser vendor does not implement native asynchronous promises, how these libraries can spawn thread?

There are no threads spawn and these libraries (in the simplest most general manner) used to wrap standard XHR request and make it a thenable and give it other API structure to resemble promises.

This article helped me the most when I started with Promises.

Community
  • 1
  • 1
nem035
  • 34,790
  • 6
  • 87
  • 99
  • "used to wrap standard xhr request" - really *any* callback based api – xdumaine Dec 09 '15 at 14:45
  • @xdumaine you are absolutely right. However its a very general question of how all libraries implement promises so I gave a general answer... – nem035 Dec 09 '15 at 14:46
  • @nem _"they should all do so"_ Could create own promise object by following specifications – guest271314 Dec 09 '15 at 14:56
  • @guest271314 well of course but using native code is pretty much always the better option than implementing your own. – nem035 Dec 09 '15 at 14:57
  • @nem _"but using native code is pretty much always the better option than implementing your own"_ jQuery, as an example, would not be in existence if this were taken literally by its authors ? – guest271314 Dec 09 '15 at 14:59
  • That's also true. The biggest reason its still out there is because of legacy code and backward-s maintainability (of course not the **only** reason). Most recent versions of browsers nowadays allow you to do a bunch of stuff jquery does, yet faster (i.e native code). For example, check out [this](https://github.com/oneuijs/You-Dont-Need-jQuery) and [this](http://youmightnotneedjquery.com/). – nem035 Dec 09 '15 at 15:03
  • 1
    @nem jQuery was only used as an example http://needsmorejquery.com/ :) http://stackoverflow.com/questions/23772801/basic-javascript-promise-implementation-attempt/ , https://promisesaplus.com/ , http://stackoverflow.com/questions/30036/javascript-and-threads – guest271314 Dec 09 '15 at 15:05
  • Well, basically all JS libraries out there are just compensating for browser limitations and incompatibility, both of which are shrinking since browsers are becoming better, more efficient and standardized. Therefore the need for many libraries is also decreasing... Of course, frameworks like angular, react, ember are still very much needed for large apps but my answer was overall, not specific to individual library as it seemed :) – nem035 Dec 09 '15 at 15:08