ES2015 added a ton of useful new features, and among them is the Symbol type. Symbol lets us avoid property name collisions in a way where we can almost implement private properties in JavaScript objects.

The Internet relies on domain names as a more user-friendly humane address mechanism than IP addresses. That means we must often write code checking if a URL is "within" domain A or domain B, and to act accordingly. You might think a regular expression is the way to go, but it has failings because while a URL looks like a text string it's actually a data structure. A domain name comparison has to recognize that it's dealing with a data structure, and to compare correctly. Otherwise a URL with domain name "loveamazon.com" might match the regular expression /amazon.com$/i and do the wrong thing.

ES6 modules are a cool new feature coming with Node.js 10.x, and a pre-release version available is avaible in 9.x. ES6 modules implement most of what we can do with Node.js's traditional CommonJS modules. One feature missing is the ability to dynamically select the module to load. The ES6 import statement only takes a static string. A new feature, landing in Node.js 9.7.x, adds an import() function offering a new way to load modules.

The most important feature may be that import() can be used in a CommonJS module to import an ES6 module.

I've happily used the async module for Node.js for years to simplify asynchronous operations over arrays. This is a difficulty in the Node.js paradigm, since the "normal" way to process an array is with a simple for loop. But if the operation is asynchronous the for loop has no way of knowing when to iterate to the next item, or even when processing is finished. Instead the async.eachSeries function does the trick, because your code tells async.eachSeries when to go to the next item, when there's an error, and it knows when the last item is processed, etc. It's been great.

With Promises and async functions, errors are automatically caught and are turned into a Promise rejection. What happens if nothing inspects the rejected Promise? Turns out that, currently, Node.js detects the unhandled Promise rejection and it prints a warning. In the warning, it says the behavior of catching unhandled Promise rejections is deprecated and will be returned, and instead the application will crash. Therefore it's worth our while to figure out what to do with unhandled Promise rejections.

ES2015 added a ton of useful new features, and with ES2016/2017/2018 we're getting a whole new language with a list of exciting new capabilities. One of them is the new Class defintion syntax that brings Class definitions closer to what's done in other languages. Unfortunately the new Class syntax does not provide a robust implementation hiding mechanism. Hiding the implementation is important in object oriented programming, if only to have the freedom to change the implementation at any time.

JavaScript is an extremely popular programming language deserving of a bigger role than browser-based programming. Fortunately we can use JavaScript outside web browsers, because of several non-browser JavaScript implementations. The most popular, Node.js, is not the only choice for running JavaScript outside the web browser.

ES6 modules are a nifty new way to write modules. In Node.js, our traditional CommonJS modules had several injected variables one of which, __dirname, was incredibly useful. None of those variables exist in ES6 modules. The Node.js team is working on replacements that work in ES6 module contexts, and a new feature has been added in Node.js 10.0.0-pre giving us a way forward to implement the __dirname variable in ES6 modules.

I'm reading a blog post about what Node.js is, and there's a glaring question "why in the world would anyone want to run JavaScript outside of a browser, let alone the server?" As the author of a book about Node.js it's a question I've thought about quite a bit, especially coming as I do from the Java SE team at Sun where the work of that team was highly focused on server side software (hey, it's Java) to the detriment of the client side of Java. The question comes from a belief cemented into place by 15+ years of JavaScript in the browser that it's a browser only language. However, JavaScript has a long history on server-side and is a rather cool language, and Node.js is an excellent base for developing web applications.

Traditionally the server side of web applications has been written in PHP, Perl, Python, Java, C/C++, etc. Javascript traditionally was implemented only in web browsers, and hence Javascript programming has been almost completely focused on the client end of web application development. It's arguably better to have the same programming language on both client and server sides of web application development, maybe. Several attempts have been made to implement javascript for server side web application development. A new javascript stack, Node.JS, is getting a lot of attention.

Traditionally the server side of web applications has been written in PHP, Perl, Python, Java, C/C++, etc. Javascript traditionally was implemented only in web browsers, and hence Javascript programming has been almost completely focused on the client end of web application development. It's arguably better to have the same programming language on both client and server sides of web application development, maybe. Several attempts have been made to implement javascript for server side web application development. A new javascript stack, Node.JS, is getting a lot of attention.

Recently the primary supporter of Node.js, Joyent, posted a video webinar about "Node.js overview for Carriers". Eric Burns talked about a broad range of services offered by Joyent, features of Node.js, spinning it all around the needs of mobile device carriers. That is, the phone companies who provide mobile device services and run the cell phone networks, not those individuals who carry around mobile devices.

ES6 modules are a nifty new way to write modules. They're rather similar to the CommonJS module format traditionally used by Node.js, but there are significant differences. When ES6 module support was first added to Node.js, it was an experimental feature with significant limitations. One limitation was whether you could use ES6 modules from CJS modules, and there was a 3rd party package to fill that gap. Today, ES6 modules are a first class feature in Node.js, and ES6 modules can be used from CJS without any add-on support.

Node.js v 4.0.0 was just released. This is a long-awaited release representing the healing of the schism in the Node.js community created when the io.js project forked Node.js. That had been done over a disagreement about the policies and maintainership of Node.js. Joyent had been in control of the project (because Ryan Dahl had been employed by Joyent) and not all in the community liked the decisions made by Joyent. They instead forked the project to create io.js, and implemented a bunch of useful ideas for example to adopt the latest-and-greatest version of the V8 JavaScript engine in order to get all the modern ES6 goodies.

Asynchronous coding is one of those powerful tools that can bite, if you're not careful. Passing around anonymous so-called "callback" functions is easy, and we do it all the time in JavaScript. Asynchronous callback functions are called, when needed, as needed, sometime in the future. The key result is that code execution is out-of-order with the order-of-appearance in the code.

Fast advances in the JavaScript language mean the new features are not evenly distributed. Fortunately the JavaScript language is flexible enough that in many cases new features can be retrofitted by using a polyfill among other techniques. One of those techniques is Babel, a so-called Transpiler that can convert code using new features into equivalent code using old features, so that a programmer can code with the new features and still deploy to older JavaScript implementations.