Dustin's Pages

Thursday, December 31, 2015

This post is my personal and opinionated assessment of some of the most significant developers related to software development in 2015. My previous years' assessment are available for 2014, 2013, 2012, 2011, 2010, 2009, 2008, and 2007. As with these previous years' assessments, this assessment of 2015's major developments in software development are obviously biased, opinionated, and limited to my perspective.

Web developers have been working for years to move toward emulation of desktop applications in a web browser (and now on mobile devices). One could argue that the push to single-page applications (SPA) really started in earnest with the adoption of the principles that were termed Ajax clear back in 2005. In the post Native Web Apps, Henrik Joreteg articulates why he thinks the term "native web apps" (as coined by Adam Brault) is a better term for these types of web applications that are now built on "native web technologies" HTML, CSS, and JavaScript.

7. Developing Economics of Open Source

The open source software movement has been successful for many years. However, in recent years and particularly in 2015, we seem to continue to adapt to new realities of open source that we learn as open source becomes increasingly pervasive. In 2015, Pivotal dumped Groovy because it is not considered significant to their future and Groovy is now under the umbrella of the Apache Software Foundation. I found it insightful that the author of Igaro App (a JavaScript Single Page Application framework) has responded to a request to release Igaro App via Smart Open Source with this seeming truism: "The market is saturated, it doesn't matter how good your framework is, gaining traction is extremely difficult. Charging would make it impossible." Although Andrew Charnley is specifically speaking of JavaScript frameworks, I think this observation is true of many new open source software projects.

The aforementioned Smart Open Source Movement is described as "an effort to stop the greed of corporations who use open source codes and make billions out of it while contributing nothing back to the community." The assertion is that "software developers and programmers" are ("unintentionally") "contributing to that greed of the corporate world." The Smart Open Source License attempts to allow software to which it applies to only be used "free of charge" by "any person ... [or] company NOT listed under NYSE, NASDAQ, DJIA, LSE, DAX, Shanghai Stock Exchange, Tokyo Stock Exchange, Hong Kong Stock Exchange and/or any company listed under Forbes 2000 Global list." Although I understand the motivation of this movement, I see several obstacles to it being adopted and being successful. There are concepts in the license that are completely orthogonal to the concepts of "free speech" espoused by the Free Software Foundation. It also seems difficult to apply which companies are not allowed to use the software. Is the "end user" (client) company or companies not allowed to use the software or is it the development firm that is not allowed to use the software? For example, would a NYSE-listed company not be allowed to develop a product with the framework even if all their customers were not listed on any of the exchanges? Finally, most open source contributors are at least partially motivated by recognition and the pride of seeing their work used by as many people as possible.

Despite the fact that certain languages fit better in certain circumstances and despite the fact that no language works best in all situations, developers cannot help but appreciate being able to use a single programming language they know well in very varied environments. Although polygot programming offers several benefits, there are potentially significant costs associated with all affected developers needing to learn to read, write, and maintain multiple languages. This is one of the explanations for many Java developers preferring to use Java throughout an enterprise application from client ("thick client" with Swing/JavaFX, Google Web Toolkit, Vaadin, DukeScript, JSweet, JavaServer Faces, etc.) through back-end (application server/Spring and JPA implementation).

JavaScript has long been considered a client technology but the success of Node.js on the server has shown that many JavaScript developers would prefer to use a language they are already familiar with on the server rather than having to learn a new language, even when the language that is new to them exists, is mature, and fits the context well.

I believe there are advantages associated with using new languages and learning from them and their different approaches, but I can also see that the cost to an enterprise can be great if a large number of programmers are required to learn and use a wide number of languages. Therefore, it's not surprising that the enthusiasm for polygot programming seems to have reached a peak and is settling some now.

4. DevOps
The DevOps concept continued to be a much discussed topic in software development in 2015. I really like the post "How I Learned To Tune Out The DevOps Buzz: Don't believe everything you hear" because blog author Chad Schorr (a self-described "DevOps evangelist") articulates some of the concerns I've had regarding devops in practice: too much ambiguity and too many vendor-driven (self-serving) presentations on the concept. Also, my experience has proven that it's often prudent to be skeptical of anything that its evangelists argue has all positives with no costs or downsides.

In many ways, DevOps seems to be going through the same lifecycle as Agile. The question is whether DevOps will enjoy the long-term relevance that Agile has had despite suffering from some of the same issues DevOps now faces. DevOps is likely to have positive long-term repercussions on how we write and deploy software, but I also anticipate that its rapid rise in adoption will be accompanied by a rapid rise in negative or disappointing experiences with it. In the end, the idea of development and operations being aligned more closely seems like an obviously positive thing, but we will probably realize that what works for one organization doesn't always work the same for another organization and will have to learn how to implement DevOps differently in different cases. We definitely still need to get past what Mirco Hering articulates: the Dunning-Kruger effect currently frequently associated with DevOps.

It is next to impossible to bring up the front page of a general software development site such as DZone without seeing multiple blog and article titles mentioning Docker. In the article What is Docker and why is it so darn popular?, Steven J. Vaughan-Nichols writes that Docker "is hotter than hot because it makes it possible to get far more apps running on the same old servers and it also makes it very easy to package and ship programs." It's easy to explain the popularity of Docker, especially during the current emphasis on devops, given its numerous deployment-related benefits.

Clear back in January of 2015, Doug Dineley asked a good question, "But have we ever seen anything like Docker?"

2. Microservices

The topic of microservices continues to dominate online software development blogs and articles in 2015. Microservices, defined by James Lewis and Martin Fowler as "an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms," are touted for several benefits including ability to modularize services for different teams to implement, ability to use different technologies in different services, and the ability to make pieces of functionality less dependent on each other for deployment and execution. However, microservices, like all architectural styles, involve trade-offs and have costs. One of the most popular discussion points related to microservices is discussing how they differ from Service-Oriented Architecture (SOA). This is not all that surprising given that both architectural styles do share several characteristics and both SOA and microservices have enjoyed significant hype in the industry.

There are always more noteworthy developments in software development than can be captured in a top ten list. This "honorable mention" section highlights other major developments that occurred in 2015 but just missed my top ten list.

As mentioned earlier in my discussion on economics of open source, GitHub has already essentially strong-armed the Codehaus and Google Code public repositories out of existence by sheer rapid rise in its popularity and use by developers. Code is not the only thing being made available on GitHub; books, design documents, and various other documents and artifacts are also being "open sourced" on GitHub. There is even a software developer recruiting post titled "How to: Use GitHub to Find Super-Talented Developers" and Yegor Bugayenko has gone as far as stating, "...if your GitHub profile is not full of projects and commits, your "value" as a software developer is low..." (see the blog post for full context).

Emil Protalinski has written that "Google confirms next Android version will use Oracle’s open-source OpenJDK for Java APIs." Protalinski adds, "Google is replacing its implementation of the Java application programming interfaces (APIs) in Android with OpenJDK, the open source version of Oracle’s Java Development Kit (JDK). ... Google confirmed to VentureBeat that Android N will rely on an OpenJDK implementation, rather Android’s own implementation of the Java APIs."

Mitch Pronschinske also cited the breaking news and has written, "Google has already contributed to the OpenJDK in the past, and they plan to make more contributions in the future as they transition fully to OpenJDK within Android. The effect of this change on the Java community could be significant, since many more developers will be familiar with Android’s libraries. The OpenJDK is much more familiar to the wider Java community than Google’s Harmony-based libraries."

The "TIOBE Index for January 2016" (www.tiobe.com) page's "January Headline" is "Java is TIOBE's Programming Language of 2015!" The Tiobe Index for January 2016 goes onto state, "Java is currently number one in the enterprise back-end market and number one in the still growing mobile application development market (Android). Moreover, Java has become a language that integrates modern language features such as lambda expressions and streams. The future looks bright for Java." This isn't too shabby for a "dead language".

It was announced in 2015 that "Scala.js is no longer experimental" as of version 0.6.0. Sébastien Doeraene also writes, "In the same way that Scala is fully interoperable with Java, Scala.js is fully interoperable with JavaScript. Scala.js can interoperate with JavaScript either in a statically or dynamically-typed way." As of this writing, Scala.js's most current version is 0.6.5 and it is "fully EcmaScript5 compatible."

With the web browser being a ubiquitous deployment environment common to desktops, laptops, and mobile devices, it's not too surprising that competition in the browser space appears to be heating up again. Jack Wallen has written in "Mozilla jettisons everything but the browser" that "Mozilla has officially announced it will cease work on Firefox OS and wants to split off Thunderbird so they can focus on one thing and one thing only. Firefox." Microsoft released Microsoft Edge as a replacement for the much maligned Internet Explorer with Windows 10 installations. The Vivaldi browser, created by developers associated with Opera, looks promising and is currently in beta.

Browsers compete on a wide variety of features and characteristics including performance, security, supported media types, and supported platforms. It will be interesting to see how renewed competition continues to help browsers move forward in all of these areas. Speaking of browsers and security, even with browsers locking down plugins (NPAPI) and favoring native HTML5, security issues still persist with plugins.

A choice of a favorite web browser is obviously a matter of taste and is subject to what a given person finds most important in a web browser. With all this stated, I found Mark Hachman's summary of how "five modern browsers" (Chrome, Opera, Firefox, Edge, and Internet Explorer) were compared to be interesting.

JSON API

JavaScript Object Notation (JSON) in an increasingly popular choice for data format used by JavaScript-based and REST-based applications. Organizations that expose their APIs via REST need to provide clients with a mechanism for understanding how to read and act upon the URIs provided with an HATEOAS approach. JSON API is one approach for "building APIs in JSON" that provides conventions that can be used when constructing JSON-based responses. In mid-2015, Dan Gebhardt announced, "After two years, four release candidates, hundreds of pull requests and issues, and countless hours of discussion, the JSON API specification has finally reached 1.0" (JSON API 1.0).

2015 was another year full of major developments in software development and this post covers some of these major events at a very high level. Although I am publishing this post on the final day of 2015, I may add some other items, details, or links as I think of them or run across them in the next several days or even weeks to form a more complete picture of the major events in software development in 2015. 2015 was another great year for software developers and, if we're not careful, the availability of programming languages, tools, frameworks, and documentation of successful practices could lead us to developing our own cases of the software developer version "affluenza."

Wednesday, December 23, 2015

While reading the blog post 5 Tips for Reducing Your Java Garbage Collection Overhead, I was reminded of the existence of a small Java collection library called Trove that "provides high speed regular and primitive collections for Java." I am especially interested in the ability to apply Trove to allow for collections of primitives rather than requiring elements in collections to be full-fledged reference objects. I look at Trove in greater detail in this post.

The JDK's standard collections respect generics and require object references for their elements and do not allow for storing of primitives in the collections. Even code that appears to be placing primitives in the standard JDK collections is actually placing object references in the collection via autoboxing. The advantage of this generics approach is the ability to have the same classes and methods work on objects of many different types. The cost is the need to store full reference objects even when leaner primitives could be stored.

The Trove library has an LPGL license and is relatively small (well under 10 MB) as shown in the next screen snapshot of the Downloads page:

The small download contains more than just the necessary library in JAR format. It also contains documentation and source. The library JAR itself (trove-3.1a1.jar in this case) is around 2.5 MB in size.

One of the reasons that Trove is easy to use is that it largely mimics the JDK collections' interfaces in its own collections' APIs. The next code listing demonstrates how adding values to a List implementation is essentially the same API calls whether using a JDK 7 List (ArrayList in this case) or the Trove-provided TDoubleArrayList.

The above code listing also demonstrates how easy it is with the Trove implementation of an array list to access the maximum, minimum, and sum of the collection of doubles. One of the advantage of these collections written to a specific primitive data type (double in this case) is that methods that apply specifically to that data type can be provided in the implementation. While it might not make a lot of sense for a collection of String or a collection of an arbitrary object return maximum, minimum, and sums, the meaning of these methods is obvious for a collection devoted to doubles such as TDoubleArrayList. The above listing does indicate how the same can be accomplished with JDK 8 using streams.

One subtle difference that may not be obvious (due to autoboxing) when looking at the code listing above is that the JDK implementation ArrayList stores reference Double objects while the Trove TDoubleArrayList implementation stores primitive doubles. Trove supplies implementations of lists, sets, and maps for various numeric types such as bytes, characters, shorts, integers, longs, floats, and doubles.

One of the interesting data structures/collections provided by Trove is the TDoubleArrayStack. Backed by the just-demonstrated TDoubleArrayList, the TDoubleArrayStack does not expose add methods in its API for adding elements. Rather, its methods reflect semantics one would expect in a last-in-first-out (LIFO) stack implementation: push(double) to add, pop() to access and remove the mostly recently added entry, and peek() to see the most recently added entry without removing it. Application of this stack implementation is shown in the next code listing. There are stack implementations for other numeric data types as well.

Although not shown here, Trove also supports first-in-first-out (FIFO) queue structures for Java's primitive types in its gnu.trove.queue package. Classes in this package provide methods adhering to queue semantics: offer, poll, and peek.

The java.util.Collections class provides much useful functionality when working with JDK collections. Trove provides a subset of java.util.Collections's functionality for working with Trove-based collections in its own class called gnu.trove.TCollections. Specifically, at the time of this writing, the TCollections class provides support for synchronized and unmodified Trove collections. The next code listing demonstrates using TCollections and also demonstrates using a Trove collection oriented toward a data type other than double (int in this case) and to a different data structure type (linked list).

When one wishes to iterate over a Trove-based collection, one can access it via a traditional iterator as shown in the next code listing. Although the collection and associated iterator work on long values in this example, Trove provides similar collections and iterators for Java's other primitive data types.

An alternate approach for iterating a Trove collection is to use a Procedure. This is demonstrated in the following two code listings. The first listing demonstrates a custom long-oriented Procedure and the second listing demonstrates applying that custom Procedure to iteration on a TLongLinkedList via its forEach method.

Trove's Java packages are organized generally by data structure type with all primitive type specific implementations for a given data structure type in the same package. For example, packages are named like gnu.trove.list, gnu.trove.set, and so on.

Because each Trove collection is specific to a particular primitive data type, each collection does not require a generic parameter and has none of the issues related to generics (such as erasure). This approach also allows each collection to support methods specific to the data type that is stored in that collection. For example, collections of numeric types can provide sum methods while collections specific to character types can provide grep methods.

Conclusion

In many common uses, the JDK-provided collections will perform sufficiently well and storing the object references may not be an issue. However, there are cases where the ability to use Trove collections and particularly to store primitives rather than object references may provide necessary advantage. The advantage of storing primitives rather than their equivalent object references in collections becomes more obvious as the collection gets larger.

Friday, December 18, 2015

As has become an annual tradition, Packt Publishing has all of its e-books and e-videos on sale for $5 (USD) each, presumably for a limited time.

Packt-affiliated Udemy.com is hosting a similar promotion and offering their online courses for $15 each (which can be a significant savings over the list price of each). As the image below shows, this sale on Udemy courses ends at 11:59 pm (PST) on Christmas Eve (December 24, 2015).

The Preface of Learning Underscore.js discusses JavaScript's recent surge in popularity and the role of Underscore.js in that rising popularity. The author states, "For a JavaScript developer, Underscore is the JavaScript-based library that can be used to create code that runs everywhere or as a foundation for adopting a functional programming style."

The "What this book covers" section of the Preface provides brief summaries of each of the book's seven chapters. The "Who this book is for" section states that the book is for "developers with fundamental JavaScript knowledge who want to use modern JavaScript libraries to advance their programming skills." You can find the full content of these two sections of the Preface in the author's blog post Announcing my upcoming book "Learning Underscore.js".

The Preface also has a section "What you need for this book" that a Node.js installation and text editor or IDE supporting JavaScript are the necessary tools for working with the book's examples.

Chapter 1: Getting Started with Underscore.js

The initial chapter of Learning Underscore.js "introduces you to Underscore and explains the main problems addressed by this library together with a quick introduction to functional programming." The chapter also opens by stating it is assumed that the reader knows "JavaScript programming fundamentals and how to create basic web pages using HTML, CSS, and jQuery." The chapter states that it is Underscore 1.8.3 covered in this book and that Underscore "provides an extensive
set of functions that simplify and enhance handling of JavaScript objects, arrays, and functions ... by providing missing functional programming features to JavaScript."

Chapter 1 explains Underscore's original rise to prominence based on its "support for some of the functionality introduced by ECMAScript 5" that "made it a useful library for web applications targeting older browsers ... and for developers that wanted to write code that was based on ES5 without worrying about browser support." The section goes onto explain that this is not Underscore's primary use anymore and that a library such as es5-shim is better suited for that. The chapter uses this discussion to point out, "All of this book's examples assume that they are executed against a JavaScript version that is ES5 compliant."

The first chapter features a section called "Getting started with Underscore by example" that uses examples to introduce Underscore's features, capabilities, and advantages over straight ECMAScript 5 (JavaScript). The first examples contrast implementing "find" capability with forEach calls versus using Underscore's find. The Underscore global object and its default name reference (_) are introduced in the context of these first two examples.

Other examples in Chapter 1 illustrate Underscore's support for functionscountBy, pairs, each, map, and reduce. Because these last few Underscore functions are functional in nature, it's a natural fit or this section of the first chapter to provide brief background on "functional programming style."

The section of Chapter 1 called "Useful patterns and practices for JavaScript applications targeting ECMAScript 5" introduces "some JavaScript patterns and practices" that are "essential when writing ES5 code, but you don't need them when writing ES6 code using classes and modules." Topics in this section include dealing with JavaScript's hoisting and the "difficult problem" of global scope with immediately-invoked function expression and revealing module pattern. The chapter also introduces JavaScript's strict mode.

The final major section of the first chapter, "Setting up a development workflow for exploring Underscore," introduces several key components of a "development workflow that is popular with JavaScript developers." These include discussion of installing Node.js with Node Package Manager (npm) on Windows, Linux, and Mac OS X. This section also describes managing dependencies with Bower, choosing a JavaScript editor (such as WebStorm, Cloud9, Node.js Tools or Visual Studio, Sublime Text, and Atom), and testing with Jasmine.

Chapter 2: Using Underscore.js with Collections

The second chapter of Learning Underscore.js revisits the "key Underscore functions" each, map, and reduce introduced in the first chapter. Concepts such as "JavaScript reflection like techniques" and duck typing are discussed in this context.

The first chapter had introduced an example of an aggregate function (reduce) and of a transformation function (map). The second chapter defines the difference between these two types of functions, delves more deeply into how to apply both of these types of functions, and introduces new Underscore functions of each type. The newly introduced aggregation functions are max, min and the newly introduced transformation functions are sortBy, groupBy, and indexBy.

The third chapter's section "Objects" opens with the sentence, "Underscore has a series of dedicated functions targeting objects, which extends the features provided for collections." Functions covered (code listings and explanations) in this section include keys, allKeys, values, invert, pairs, contains, pick, omit, extend, clone, has, property, propertyOf, matcher, isEqual, and isMatch. This section also looks at "assertion functions" for "object validation," "determining object types," for String objects, and for Number objects.

The first three chapters of Learning Underscore.js provided an "overview of most of the Underscore features" and the fourth chapter looks at using Underscore in object-oriented and functional paradigms. The chapter states, "JavaScript is a dynamic multi-paradigm programming language that can be used with an imperative, object-oriented, or functional programming style." The chapter provides an overview of the object-oriented paradigm as it pertains to ECMAScript 5 and ECMAScript 6 versions of JavaScript before looking at "Using Underscore with the object-oriented programming paradigm." The stated objective of this section is to demonstrate that "the Underscore object-related functions [can help] us build a class implementation that should feel familiar to developers coming from a class-based OOP language."

Chapter 4 also looks at "the functional programming paradigm," looks at what it takes to migrate from an object-oriented paradigm to a functional-oriented paradigm in JavaScript, and then looks at "functional programming with Underscore.js." The chapter explains that Underscore provides "built-in support" for the "method-chaining concept" with the chain, map, and tap functions.

Chapter 5: Using Underscore.js in the Browser, on the Server, and with the Database

The fifth chapter's discussion of using Underscore in the browser looks at using Bootstrap as a "frontend design framework" and the looks at how applying Underscore templates enables creation of "a better solution." Chapter 5's look at JavaScript on the server provides more information on using Node.js before describing how to "[convert] JavaScript code to Node.js modules."

The "Using Underscore with MongoDB" section of the fifth chapter introduces that "popular document database" and provides a high-level overview of MongoDB conceptually and compares and contrasts this NoSQL implementation with relational databases. The section looks at how MongoDB makes use of JavaScript and describes how to install MongoDB on Windows, Ubuntu Linux. and Mac OS X. This section also explains how to configure and run MongoDB and then provides an example of using the MongoDB JavaScript API and the MongoDB JavaScript shell. There are several pages explaining and demonstrating application of the "MongoDB Node.js driver."

Chapter 5 also has a section called "Using Underscore with PostgreSQL" that introduces PostgreSQL's support for "JavaScript as a procedural language through the PL/v8 project." This section describes how to install and configure PostgreSQL, how to install PostgreSQL on the same three operating systems as shown earlier for MongoDB, and "using psql with basic database commands." The section also looks at PostgreSQL data types before delving into details regarding PostgreSQL's jsonb type.

Being a fan of the PostgreSQL database, I particularly enjoyed this section on using JavaScript with PostgreSQL and especially liked the section on "using PostgreSQL with plv8." This section first shows use of JavaScript to write PostgreSQL stored functions and then shows how to use Underscore with those implementations.

Chapter 6: Related Underscore.js Libraries and ECMAScript Standards

The focus of Chapter 6 of Learning Underscore.js is on libraries that are "alternative and complementary" to Underscore.js and on Underscore.js's "relationship with JavaScript standards and how to write the ECMAScript 2015 (ES6) code." The chapter explains that the alternative and complementary libraries can be desirable because Underscore itself is relatively small.

Underscore-contrib is introduced in this sixth chapter. The chapter explains the relationship of Underscore to Underscore-contrib and provides "an overview of Underscore-contrib functionality." It covers select functions from the sub-libraries provided by Underscore-contrib, discusses installing Underscore-contrib, and provides a couple of examples of applying Underscore-contrib.

The lodash library is also introduced in Chapter 6 as a JavaScript library originally forked from Underscore that focuses "on better performance, improved consistency across browsers, and enhanced code readability." This section outlines how lodash varied originally from Underscore and eventually became incompatible with Underscore. The section also provides an "overview of lodash functionality" that compares and contrasts some of Lodash's functions with similar ones in Underscore.

It surprised me a bit that a book about Underscore and with "Underscore" in the title mentioned ways in which lodash might be considered superior to Underscore. There is even a section in Chapter 6 on "migrating a project from Underscore to lodash", a reference to a Wiki page on migrating from Underscore to lodash, and a reference to another Packt Publishing title Lo-Dash Essentials.

Chapter 6 of Learning Underscore.js talks about Underscore's relationship to ECMAScript/JavaScript standards. The section begins with background details: "Up until Underscore 1.6, there was a strong correlation between the library and some of the native JavaScript functions available in ES5. Starting with Underscore 1.7, this link was broken and the library introduced implementations that performed better than the native JavaScript equivalents." The section goes onto look at ECMAScript 5.1 (ES5) functions that are similar to Underscore functions and lists some of the advantages of the Underscore versions of these functions.

The section "ECMAScript 2015 (ES6)" describes advantages offered by ES6 and describes features of ES6. This section references the ECMAScript 6 Compatibility Table and explains how transpilers can be used to "convert code from ... upcoming ECMAScript specifications ... into code that is compatible with older specifications." Babel is introduced as a transpiler for converting ES6 code to ES5 code and examples of using Babel from a web browser, from the command-line, and in conjunction with Node.js are provided. Several examples are provided of using Babel to use ES6 functionality.

Chapter 7: Underscore.js Build Automation and Code Reusability

The final chapter of Learning Underscore.js begins by looking at installing Gulp and using Gulp for deployments. The chapter also includes a section "Reusing code based on Underscore between client and server" that covers use of CommonJS, Browserify, Jasmine, and Gulp to enable using code on client and server. The final section of the chapter and of the book illustrates using babelify to add "ECMAScript 2015 (ES6) support to Browserify."

I liked that Learning Underscore.js liberally referenced online materials for more details on many of the topics it introduced. Some of these articles and resources are excellent and I was glad to have them pointed out.

I liked the book's coverage of running JavaScript in different contexts such as browser, server, and database. The book helped show that it's possible to do this, but also demonstrated that doing so is still not trivial and does require additional effort to achieve a full degree of cross-platform compatibility.

Learning Underscore.js includes numerous code listings. Even in the PDF copy of the book that Packt Publishing provided for my review, the code listings are black font on white background with no color syntax and no line numbers. However, each chapter references where the code can be downloaded to be used in the reader's favorite IDE or editor. These references include Cloud9 links.

Conclusion

Learning Underscore.js provides a thorough introduction to Underscore.js that includes explanation of why it's popular among JavaScript developers and some of the functionality it makes available above and beyond current JavaScript implementations. The book points out different approaches that can be used to start taking greater advantage of ES6 features today.