Welcome

Welcome to CMS n Web. Learn & Study completely Free Articles\Training about Web Designing\Development and CMS.

Search This Web

Showing posts with label ES6. Show all posts
Showing posts with label ES6. Show all posts

Monday, January 13, 2014

Toward Modern Web Apps with ECMAScript 6 and Comparison with ES5

by August 13, 2013 | Ariya Hidayat

ECMAScript, the official name for the language we all know as JavaScript, has enjoyed tremendous success over the last couple of years. With convergent standard support, performance boosts from modern JavaScript engines, as well as its foray into the server-side stack, ECMAScript has gained significant traction and redefined the scope of HTML5 applications. The final requirement for world domination is the modernization of its syntax and run-time, which is coming in ECMAScript 6 and is the subject of this post.
To understand the language progress within ECMAScript 6, first we need to understand how it is developed. The official ECMAScript specification, also known as ECMA-262, is defined by a standard body called Ecma International. The TC39 group within ECMA is responsible for formalizing the language specification (TC stands for Technical Committee). Every browser vendor, as well as other interested parties, has one or more representative members in this committee. Those members are tasked with championing features and additions to the next version of the language. From time to time, TC39 members meet to review the recent progress and to finalize the formal specification. Often, ideas are also discussed with the public in the es-discuss mailing-list.
The ECMAScript 6 specification is still in the draft stage. There have been many draft revisions so far, with the latest one coming out as recently as July 15th. Keep in mind that the concepts and the examples illustrated in this article follow the latest specification draft and its related discussions at the time of writing, but there is still always a possibility that some syntax or function name may change in the near future before the finalization of the specification.

“I Can See Clearly Now”

It is often said that “Code is written once but read many times”. In fact, many of us who spend countless hours in the code review process realize how important it is to have clear and unambiguous code. In addition, crystal clear syntax makes it easy for a new team member to understand the code and to avoid common pitfalls.
A common mystery for a novice is the following construct:
 
// ES 5
function inc(x, y) {
  y = y || 1;
  return x + y;
}
 
The use of the second argument, y, can be confusing. Its value includes a logical OR with the constant 1, so that if y is undefined (or, more precisely, when y is falsy), it has the value of the constant 1. For example, if the function is called with only one argument, such as inc(4), the return value is 5 (which is 4 plus the default value of 1 for y). Such a seemingly clever hack is buggy (passing y as 0 produces the wrong outcome), error-prone (what happens if bitwise OR is accidently used instead of logical OR), and totally meaningless to those who are not familiar with the technique. There are other variants which solve these issues, but the problem remains the same: it is still a run-time workaround.
ECMAScript 6 solves this issue by having a built-in feature for the default parameter value, allowing the previous construct to be rewritten in the following way, which should make a lot of sense to those familiar with other programming languages:
 
// ES 6
function inc(x, y = 1) { return x += y; }
 
Another common pitfall for beginners is the fact that variables have function scope instead of block scope. If someone is already used to other “curly-brace” programming languages, this scope difference can come as a shock. In addition to that, variable hoisting confuses the situation even further: a variable may exist in a scope although it has not been initialized.
Take a look at the following example where the variable N within the conditional body shadows the outer N. Since N is function-scoped, declaring a new N within the body of the if statement does not have any effect; it is still the same N and thus the original value is overwritten.
 
// ES 5
function doSomething() {
  var N = 5;
  if (someCondition) {
     var N = 10;
     doSomethingElse(N);
  }
  console.log(N); // 10
}
 
This is a rather trivial example and hence the problem can be spotted immediately. But in a large code block which uses several closures, such a sloppy name conflict may lead to obscure bugs.
ECMAScript 6 introduces the concept of lexical block scope, where a variable or a function is enclosed within the closest curly braces. The problem in the above example can be solved elegantly using the new let keyword.