ALL COUNTRIES:
December 2, 2019 @ 6:17 AM By Meenati Biswal
The last couple of years have been an exciting time for JavaScript programmers. The TC-39 committee that oversees the ECMAScript standard has added many new features, some of which are syntactic sugar, but several of which have propelled us into a whole new era of JavaScript programming. By itself, the async/await feature promises us a way out of what’s called Callback Hell, or the situation we find ourselves in when nesting callbacks within callbacks. It’s such an important feature that it should necessitate a broad rethinking of the prevailing callback-oriented paradigm in Node.js and the rest of the JavaScript ecosystem.
Refer back a few pages to this:
This was an important insight into Ryan Dahl’s part and is what propelled Node.js’s popularity. Certain actions take a long time to run, such as database queries, and should not be treated the same as operations that quickly retrieve data from memory. Because of the nature of the JavaScript language, Node.js had to express this asynchronous coding construct unnaturally. The results do not appear at the next line of code but instead, appear within this callback function. Further, errors have to be handled unnaturally, inside that callback function.Â
The convention in Node.js is that the first parameter to a callback function is an error indicator, and the subsequent parameters are the results. This is a useful convention that you’ll find all across the Node.js landscape. However, it complicates working with results and errors because of both land in an inconvenient location — that callback function. The natural place for errors and results to land is on the subsequent line(s) of code. NodeJS Online TrainingÂ
We descend further into callback hell with each layer of callback function nesting. The seventh layer of callback nesting is more complex than the sixth layer of callback nesting. Why? If nothing else, it’s that the special considerations for error handling become ever more complex as callbacks are nested more deeply.
Instead, ES2017 async functions return us to this very natural expression of programming intent. Results and errors land in the correct location while preserving the excellent event-driven asynchronous programming model that made Node.js great. We’ll see later in the book how this works.
The TC-39 committee added many more new features to JavaScript, such as:
You may see the new JavaScript described as ES6 or ES2017. What’s the preferred name to describe the version of JavaScript that is being used?
ES1 through ES5 marked various phases of JavaScript’s development. ES5 was released in 2009 and is widely implemented in modern browsers. Starting with ES6, the TC-39 committee decided to change the naming convention because of their intention to add new language features every year. Therefore, the language version name now includes the year, hence ES2015 was released in 2015, ES2016 was released in 2016, and ES2017 was released in 2017.
The pink elephant in the room is that, because of how JavaScript is delivered to the world, we cannot just start using the latest ES2017 features. In frontend JavaScript, we are limited by the fact that old browsers are still in use. Internet Explorer version 6 has fortunately been almost completely retired, but there are still plenty of old browsers installed on older computers that are still serving a valid role for their owners. Old browsers mean old JavaScript implementations, and if we want our code to work, we need it to be compatible with old browsers.
Using code rewriting tools such as Babel, some of the new features can be retrofitted to function on some of the older browsers. Frontend JavaScript programmers can adopt (some of) the new features at the cost of a more complex build toolchain, and the risk of bugs introduced by the code rewriting process. Some may wish to do that, while others will prefer to wait a while.
The Node.js world doesn’t have this problem. Node.js has rapidly adopted ES2015/2016/2017 features as quickly as they were implemented in the V8 engine. With Node.js 8, we can now use async functions as a native feature, and most of the ES2015/2016 features became available with Node.js version 6. The new module format is now supported in Node.js version 10.
In other words, while frontend JavaScript programmers can argue that they must wait a couple of years before adopting ES2015/2016/2017 features, Node.js programmers do not need to wait. We can simply use the new features without needing any code rewriting tools.
About the author:
OnlineITGuru has become a platform for both developers and College students to enhance their skills in the IT World. Onlineitguru.com has made a special effort to impart knowledge to the people even though one –one session in odd days. The major motto of the Onlineitguru.com is to impart the knowledge successfully at the learner convenient time across the globe. Â