Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
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
are promises are native and spawn additional threads like ajax?
there are lots of libraries like q , deferred are there. are they all wrappers for native JavaScript promise API?
If a browser vendor does not implement native asynchronous promises , how these libraries can spawn thread?
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
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.
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.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
Improve this question
I watched an interview with Ryan Dahl (the author of Node.JS) in which he regretted that he made the decision not to include Promises in Node.JS - and that this fact was among his motivations for including Promises in Deno, which conceptually seems a lot like Node.JS. However, from what I can see, Node.JS does include Promises, and I cannot see why it would not, since it is based on V8. Am I missing something?
Ryan Dahl was speaking of a period long before promises became part of the ECMAScript specification. He talked about this in this presentation "10 Things I Regret About Node.js" (at 5:40), with this slide:
Regret: Not sticking with Promises
I added promises to Node in June 2009, but foolishly removed them in February 2010.
Promises are the necessary abstraction for async/await.
It's possible that unified usage of promises in Node would have sped the delivery of the eventual standardization and async/await.
Today Node's many async API's are aging badly due to this.
This was a time when Node was in its first year (when version numbers started with 0), and although the concept of promises was long known, it was not yet included in the ECMAScript standard. It was only with ECMAScript 2015, that promises got included, and since Node version 4 in 2015, Node has had this native promise support.
If Node had not abandoned promises in 2010, many modules would have used it, and we would not have ended up with so many async modules which are either obsolete or needed awkward tailoring (with backwards compatibility) to make them work with promises.
A bit of research and/or more consistent interview watching will give you the answer.
Dahl said that he did introduce the promises to Node in 2009 but later in fabruary 2010 he foolishly removed them. Here is the link with timecode:
https://www.youtube.com/watch?v=M3BM9TB-8yA&t=309s
Later in 2012 Dahl made a step away from Node which means that subsequent updates were no longer associated with him.
Surely Node.JS nowadays has promises but it's not straight Ryan's merit.
That's it nothing more, nothing less.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I m working on a Node.js library project that exposes asynchronous APIs to the user. I haven't worked in javascript for long, but it seems that several years ago, callbacks were used to handle asynchronous results/errors. Then promises were introduced in ES6 and async-await in ES8 (which is just more convenient way to use promises).
My question is what would a typical user of the API currently expect? I noticed an idiom in several projects where both promises and callbacks are supported, in the way that a function takes a callback as a last argument and if it is not provided, returns a Promise.
I'm wondering if this idiom should be followed in current projects or should callbacks be removed all together? Would anybody still use callbacks?
I noticed that async-await is becoming the dominant style but Node.js API itself is still callback-based (in fact the APIs usually return an event emitter, not a promise, so that user can register events on the return value).
So I'm just looking for general input from Node.js community about which direction to take.
Thanks.
Edit:
Thank you for the answers. I was asked to clarify couple of things about the project in case there are more recommendations:
(1) The API is intended to be used to access a specific product
(2) All of the calls involve network communication, basically request/response.
We definitely intend to support promises (such that each request gives user a promise that can be fulfilled or rejected), the only question is whether callbacks should still be supported as well.
Perhaps I can rephrase the questions as to be less opinion based:
1) For Node.js libraries released recently (after async-await became supported in the language) and having requirements similar to above, what is the predominant style? Could you please point me to any examples?
2) Could there be any scenario in which application would prefer handling the asynchronous result/error via callback instead of a promise?
Thanks.
A Range Of Possibilities
If your library requires a synchronous relationship with the client program then you might want to use callbacks (Programs that are I/O dependent). Otherwise, if your API has long and inconsistent response times you definitely want to be able to handle promises so you are not bottle necking applications that can't wait on every request (Routing webtraffic, etc.).
Conclusion
In my personal opinion, what makes Node.js great is the asynchronous nature of promises that let you write programs that are flexible. At the end of the day, people are going to be using your library for a diverse range of purposes and the more options you can give your users the better. Good luck!
How big is your intended user base?
If it’s small - ie contained within an easily defined group and modern tech stack, play the dictator and choose just one style.
If it’s large and has to run on many, possibly legacy platforms, consider just offering callbacks, or offer multiple flavours.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 4 years ago.
Improve this question
As we know, Java have join method in multi-threading, I want to achieve the same in NodeJs. Is these any equivalent to join method of java in NodeJs?
Below is my requirement:
I have 3 methods(m1(),m2(),m3()) which calculates huge data and returns a number. Then i have one Sum() method which adds all three numbers returned by these three(m1(),m2(),m3()) methods. As these three methods are taking approx. 10 min each to calculate the data, my sum() method have to wait for approx. 30 mins to start executing. So i want to execute these three(m1(),m2(),m3()) methods parallelly. But my condition here is, The Sum method should start execute only when all three methods complete their execution and add the data returned by three methods.
Node.js does not have the concept of multi-threading, since JavaScript by default runs single-threaded. Hence you don't have something such as join. Instead, you need to get to know concepts such as the event loop, callbacks, promises & co.
(Yes, to be true, Node.js meanwhile has the concept of worker threads, which allow multi-threading, but this is still experimental.)
All Node JS applications uses “Single Threaded Event Loop Model” architecture to handle multiple concurrent clients.
NodeJs operate asynchronously and uses the Event-loop mechanism to function.
And join method in JAVA allows one thread to wait until another thread completes its execution. So this can be achieved in Javascript using Promises or Async/Await.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Maybe I missed something in Ryan Dahl interview here https://www.youtube.com/watch?v=SAc0vQCC6UQ
but historically he was very and still is fond of Ruby. Why couldn't he use Ruby to build the same concept as Node instead of Javascript ? I don't know much about Ruby but doesn't Ruby support all Javascript features like functional programming, closures etc. ?
My question is technical please give as much internal details about Javascript vs Ruby Interpreter as possible.
In the interview he said the problem was in Ruby Interpreter without really explaining. Why wouldn't it be also in Javascript?
Very short answer: Nothing.
Slightly longer answer: There is nothing technically preventing the implementation of a non-blocking evented asynchronous I/O library for Ruby. In fact, there are several such libraries, some existed before Node.JS, some were inspired by it. E.g. EventMachine, Cool.IO, Celluloid::IO.
Long answer: Ruby has a standard library. A very rich one. In particular, Ruby has a very rich I/O library: IO, File, fileutils, net/ftp, net/http, net/imap, net/pop, net/smtp, net/telnet, resolv, socket, webrick and others. All of them are blocking. None of them are evented. All of them are synchronous.
ECMAScript, OTOH, has a very poor standard library. When Node.JS started, it was practically non-existent. Now, in ECMAScript 2015, there is a little bit, but it's all data structures, no I/O. Even ES2015 does not have a single I/O function.
This allowed Ryan Dahl to start completely from scratch. Since every tiny little bit of I/O library had to be newly written anyway, it could be written from the ground up to be asynchronous, non-blocking, evented.
And, since the DOM API is mostly evented, ECMAScript programmers were already used to programming in this style!
Whereas in Ruby, one would not only have to throw away all existing I/O library code, you'd also have to retrain all programmers!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I was reading an MDN article, and it states that almost always async is a better approach than making synchronous calls from the browser to your back end. It then goes on to say "In rare cases, the use of a synchronous method is preferable to an asynchronous one." I was wondering what are some use-cases when we would prefer making synchronous requests ?
Synchronous AJAX requests completely block the UI (the same way that, for example, a native alert box does). The JavaScript concurrency model is based on leveraging asynchronous operations. I can't think of a single use-case where a synchronous request would have benefits over an async one.
As far as stylistic concerns, like "waterfalls" of callbacks, etc., these can all be managed fairly easily through different means. For example, various Promise libraries, or native ES6 features like "coroutines" (generators that deal with Promises) or even just native ES6 promises.
I think if you're running into a situation where you feel the need to call a synchronous request, then you need to step back and re-think the architecture of your application (not talking about you specifically, but just in general).
In Javascript the rule is async first! Only in case that is not possible go for synchronous !!