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.
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 3 years ago.
Improve this question
Given that V8 execution of ES6 code is slower on some operations, compared to ES5.
According to this: http://incaseofstairs.com/six-speed/
Can anyone point to an article/paper/post where tests were performed in order to find out if such performance difference will impact in the normal operation of an API developed with node.js?
Should I use ES6 or greater to build a node.js API, considering it is slower to ES5?
That's a false premise right off the bat, as demonstrated by the chart you linked to.
No, this is not "premature optimization"
Yes, it is. Choice of language dialect is much more about ease of development, compatibility with libraries, and reliability. There is nothing in common implementations of ES6 that are "slower" across the board. You haven't even built your application yet, and you're worried about something that is unlikely to make a significant impact at all.
If you find that there some particular code that could be optimized, Node.js allows you to implement native binaries where you can optimize all you want.
I know some may wonder, if the API is going to get millions of hits, but again, I'm more interested in the correct pattern to use.
Use ES6.
In the back-end, we're talking about hundreds or thousands of clients, and that performance hit will be compounded.
And yet, you don't even know what the pain points are in your application because you haven't built it yet. For most applications, it's going to come down to I/O.
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 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 6 years ago.
Improve this question
I'm new in JS, and I even do not know a lot about it, there are different version of it and I'm really confused, ECMA-262, ES 5, ES 6 ... and V8
And I know there are some new features added in newer versions, like defining class by class keyword.
I looked at bunch of libraries at GitHub, most of famous libraries are using keywords like import or let that is not supporting by current browsers which many people are using, but they are still using those keywords (which means ES 5 or ES 6)
And almost all of those libraries have a version for browsers.
What is the current version of JavaScript we mostly use?
How those libraries, convert their codes which has been written in ES 6 to the version that is supported by current browsers? (Most of those libraries have a version for browsers named library.min.js)
Why do they use those keywords when most of browsers are not supporting them?
Mostly we use javascript in common browser using ES 5 or ECMA-262 (Now is 2016)
They use Babel https://babeljs.io/ to run the next standard JS in ES 6 or ECMAScript 2015
#nnnnnn: Now in 2016 every browser supports ES5. The only common browsers that don't handle at least all the main features of ES6 are IE<11. And note that V8 is not a version of JS, it's a JS engine. Note that there are a number of libraries on GitHub intended for use in server-side JS, and if you're running server-side JS you have control over which version of JS you can use.
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 8 years ago.
Improve this question
Since JavaScript is becoming more and more popular I'm wondering who are the people who get to decide what the language looks like, and why do we have ECMAScript instead of JavaScript? The ECMA sites look very outdated...are these the people in charge of the future of the web that drives all the groovy stuff like V8, and NodeJs?
I love JavaScript and I love NodeJs...but there seems to be some controversy on what's going into the newest script languages. I guess that can't be avoided. I'm just excited about the future of JavaScript and hope we are in good hands.
http://www.ecma-international.org/default.htm
http://www.ecmascript.org/
JavaScript is a trademark owned by Oracle. The language is standardized by the ecma, (previously the European Computer Manufacturers Association).
Netscape submitted the language to them in 1996, to promote a single standardized client-side language (at the time, MS had a similar language called JScript), and the goal was to avoid browser specific implementations (like we have with CSS now). The ecma simply maintains the default sets of expectations, not any individual implementations.
No individual is responsible for all the development in ECMAscript. V8, Node, jQuery, WebRTC, etc. are all incredibly valuable projects supported or maintained by disparate (sometimes collaborating) groups.
Additionally, each browser implements ECMAscript differently, so "what goes into the new language" is not under any one individual or organization's control.
Just because there's a standard, doesn't mean everyone, or anyone will follow it. Trust me, you should see my code. :)