JavaScript is everywhere. Once relegated to an Internet fad, the malleable programming language has evolved along with the Web and now finds itself entrenched in modern browsers, complex Web applications, mobile development, server-side programming, and in emerging platforms like the Internet of Things.
Underlying that browser-centric user and developer shift, JavaScript has developed a robust ecosystem of third-party and open-source libraries, frameworks, tools, implementations and superset languages woven into the backbone upon which Web and mobile development is now built.
Over the past decade, starting with jQuery empowering Web developers with client-side scripting, every popular plug-in has filled another gap in the language and its capabilities.
According to Gartner analyst Danny Brian, a member of the Gartner for Technical Professionals group specializing in Web and mobile development, “JavaScript’s prominence is a byproduct of the browser being ubiquitous, whether that’s desktop, mobile or other platforms like native desktop applications using the browser wrapped up and deployed or built with HTML5, and the emerging IoT devices and peripherals that treat Node.js as the engine that powers them.”
Where JavaScript goes next
After more than 15 years without a major update, the international standards organization Ecma is finally set to release ECMAScript 6—a comprehensive update to standardized JavaScript—in June of this year. The 650-page final draft of ECMA-262 Edition 6 (ES6) was recently sent to the Ecma General Assembly so it could be finally approved and standardized at the June Ecma General Assembly meeting. ES6 is a foundational change to the language, featuring a revamped syntax of modules, classes and other advancements to enable the development of larger, more complex Web applications.
(Related: Milestone ECMAScript 6 on track for June standardization)
Mozilla research fellow and ECMAScript project editor Allen Wirfs-Brock said it will fall on browser providers, many of which are already in various stages of implementing ES6 features, to roll out the standard and optimize it across their JavaScript engines and developer tools.
“What ECMAScript does is provide the common foundation that JavaScript programmers in whatever environment or application can depend upon,” said Wirfs-Brock. “ECMAScript 6 is such a significant advance over previous versions of JavaScript, it’s what all programmers over the next couple years will expect to be there. So there’ll be a whole lot of pressure on the browsers, server-based systems and everyone who implements JavaScript to run fully performant ES6 as soon as possible.”
The tooling and browser evolution
The JavaScript ecosystem has made the language more accessible and easier to work with across the development spectrum, according to Gartner’s Brian.
Angular extends HTML syntax to JavaScript, while streamlining the coding process with data binding and dependency injection. CoffeeScript, TypeScript and the like bring in developers from other languages by dangling the syntactical carrot and compiling to JavaScript. Backbone, Ember and Grunt make Web application development run smoother and faster. Apache Cordova and Bootstrap open JavaScript’s mobile Web and app development possibilities. The emergence of HTML5 entwines JavaScript with the future of the markup language. And Node.js gives JavaScript the cross-platform runtime to conquer servers, embedded devices and more.
“We spent all these years trying to bring our favorite languages to the browser in the form of plug-ins, applets and cross-compilers, but JavaScript was already there, and now developers are taking to it via frameworks,” said Brian. “They see their friend building something cool with Angular or Ember or another framework, so they decide to learn it.
“It’s this appeal of being able to write a function or have an object in JavaScript and being able to literally cut and paste that to consoles running in the cloud and the browser. That’s a power we’ve wanted for a long time, though we didn’t necessarily expect to get it from JavaScript.”
Andrew Connell, an independent software development contractor who’s worked extensively in both server-side coding and Web development, said it all really started with jQuery. Once jQuery helped everyone get around the maddening process of writing cross-browser JavaScript, a maturing progression of frameworks helped advance the language. Now, with examples like Angular and Facebook’s React, the biggest tech companies on the block are investing heavily in JavaScript development tools.
“Back in the day, JavaScript was always just the glue that led us to make things somewhat interactive on the browser, but that was about the extent of it,” said Connell. “The fact that the language has been adopted in so many different ways, from Web to server to devices, clients and mobile, and the advent of all these different libraries and ecosystem around it—the better tooling and frameworks we’ve had over the past 5+ years—it’s become much more than just the glue that holds things together.”
A strong indicator of how JavaScript philosophies have changed is the partnership between Google and Microsoft to write Angular 2 in Microsoft’s superset TypeScript language. Google chose to scale back independent development of some of its own JavaScript tools, including the Dart programming language, and even rolling features of its AtScript language and runtime into the next version of TypeScript.
Brian sees the landmark Angular 2 collaboration as a healthy sign that the larger tech companies are working together to accelerate ECMAScript 6 adoption, and also as a strategic move for Google to push forward some its own Web component goals through working with TypeScript on Angular 2.
“Google understands that the browser continues to evolve, with ES6 and Web components changing what we need from a framework,” he said. “Angular 2 is a really interesting collaboration from the perspective of JavaScript, because although Microsoft and Google have not always got along, Microsoft has been very proactive in its [advocacy] of TypeScript and in building ES6 features into Internet Explorer. Google has a lot to gain from involving Microsoft and TypeScript’s strong following in that discussion.”
Runtimes
Though JavaScript has advanced far beyond simple browser interactivity, that concept of the language as glue is still applicable, particularly in JavaScript runtimes such as Google’s V8 engine, io.js and Node.js. These runtimes give developers the ability to essentially build desktop applications running in JavaScript, leveraging one language and one skill set to wrap the language into the future of servers, embedded devices and the Internet of Things as a truly cross-platform language.
“Node.js has really become foundational to a lot of other products and different platforms,” said Brian. “That’s true of JavaScript and V8 in general. Clients never want to find themselves in a runtime dead-end, and the health of an ecosystem is a great indicator of a runtime’s longevity.”
The prospect of the io.js fork ultimately rejoining the main Node.js distribution as part of the Node.js Foundation indicates to Brian a higher level of investment across the development community in the runtime, and by extension the browsers it lives in.
As Connell put it, the biggest factor holding Web development in the past has been legacy versions of browsers, exemplified by the half-dozen lingering versions of a browser like Internet Explorer. With Chrome and Firefox moving to a continuous, “evergreen” update cadence, users and developers don’t have to worry about their browsers being current. With Spartan (Microsoft Edge), Microsoft is now moving to the evergreen browser update model as well.
In terms of browser maturity, Brian believed the market has evolved to a point where major browsers are largely on the same page when it comes to standards and ultimate goals for what they want the browser to be. It’s a concept borrowed from open source he refers to as “co-opetition.”
“We’re all agreed on standards. We’re all shooting for a similar end goal,” said Brian. “Where the actual competition takes place is in more of the optimization. How quickly can browsers adopt these technologies? If we only had one browser today, our confidence would be very low in that thing running 10 years from now on all those devices we can’t predict today. But because I can take that same JavaScript code and run it on a single-board computer, run it on my desktop, run it on a native mobile app on my phone, run it in the cloud, that’s what gives JavaScript staying power.
“So long as we have Internet Explorer competing with Chrome competing with Safari competing with Firefox and Opera—even though many of those will share code between them—the landscape will continue to shift, and that’s a good thing for JavaScript developers.
“This is exactly what developers want,” said Brian. “We want all these options available that are still running the same portable applications. The more the merrier.”
JavaScript’s complex relationship with the enterprise
Enterprise application development is where JavaScript’s uptake has been slowest, and it finally turned the corner over the last several years. Connell echoed the general feelings of many traditional enterprise developers, explaining that even now a significant population still looks at JavaScript as “not real development.”
Overall perceptions are warming, though, as server-side developers have begun to see JavaScript and the frameworks that come with it as another option in their toolbox.
Marc Anderson, cofounder and president of Sympraxis Consulting and the developer of SPServices (a jQuery library for SharePoint), explained that early in enterprise development, many programmers found themselves unable to meet traditional project requirements using JavaScript. Rather than asking which framework a developer should use, he said they should’ve been asking what language or framework matched their business requirements.
“Everybody dislikes something about any language,” he said. “I’ve used dozens and they all have their quirks, so when people say they don’t like JavaScript for one reason or another, it’s usually about the technical implementation of the language itself. One of the reasons JavaScript had a bad reputation for a while is this elitism around using a compiled language: the idea that scripting is somehow inferior or less of a programming language.”
One of the enterprise areas in which JavaScript took the longest to catch on was in the Microsoft space. Until the release of TypeScript, Microsoft never offered any kind of meaningful JavaScript developer tool.
“[JavaScript has] been in the browser since the mid-1990s, and it gives you this immediacy of working with the end user that you can’t get in a compiled language,” said Anderson. “We can be much more agile and pay a lot more attention to the user experience with JavaScript when we’re closer to the glass. Right where the user is, we’re running our code.”
According to Anderson, Microsoft developers were comfortable writing C# and .NET on the server, and they looked at the browser as a brave new world. Tools like TypeScript make the language feel more natural to C# developers, giving them a compiler-like feel even though it’s not a compiler, per se. He mentioned JavaScript code quality tools such as JSLint and JSHint, passing code through them for static analysis to give enterprise developers a higher comfort level.
“TypeScript takes what they write and puts it through a syntax checker, applying a bunch of rules to JavaScript to make them more comfortable writing it,” said Anderson. “There’s this way of writing JavaScript now that’s more comfortable for people from a compiled language background. A lot of server-side coders are coming to the party now.”
Gartner’s Brian said that while frameworks and superset languages like TypeScript have been integral to JavaScript’s popularity, he worried about the culture around developers specializing in a particular library or framework becoming a crutch for development teams going forward.
“You see a lot of résumés nowadays where a developer titles him or herself an Angular developer or an Ext JS developer, etc.,” he said. “They tend to think in fairly limited terms of what the framework provides for them. That’s the risk of any big framework or superscript: You’re at the mercy of the tool. That’s fine, as long as you have a high degree of confidence in the maintenance and development of that tool. The bigger the cross-compiler and the more complex the framework, the more abstraction it’s giving you. It’s not just about targeting the open-source runtime, which is the browser. It’s about choosing tools in your workflow that’ll be around for a long time.”
ECMAScript 6 and the Web’s next frontier
Many developers are already making use of ES6 features available in different Chrome builds, Internet Explorer and other browsers where class support is almost fully implemented. Brian sees ECMAScript 6 standardization as less about developers using the features than about the importance of a clear picture of JavaScript going forward.
“Up until now, you’ve had projects like TypeScript and Traceur and ES6 polyfills shooting for a specification that’s not yet baked,” he said. “Having that baked now gives everybody a sense of where the browsers will go, and therefore dev teams can have a lot more confidence starting to use things like TypeScript. That lingering question mark is gone, and when it comes to these Web standards, you can’t be sure of anything until you get that John Hancock at the bottom of the page.”
Mozilla’s Wirfs-Brock said we won’t know for four or five years until ECMAScript 6 is broadly used if it’s achieved all its technical goals, but the effect of galvanizing the Web development community is already apparent.
“There’s already fairly wide use of ES6 features in terms of transpilers and other tools that compile ES6 down to ECMAScript 5 code to run on browsers,” he said. “Clearly the things in ES6 that have the biggest impact on complex applications are the module support and the classes in the language. The most important point on both of those is having one standard way to organize at both the modular component and the program abstraction level, applicable to all JavaScript environments and libraries.”
Wirfs-Brock explained that much energy over the past decade has gone into creating libraries that invent new class models or modularity. ES6 streamlines all that. The TC-39 committee is the working group within Ecma dedicated maintaining the ECMAScript standard, and one of its primary goals, according to Wirfs-Brock, was to consider language design features that offered something unique—something a library couldn’t do.
The popular libraries and frameworks around JavaScript have had a significant impact on how the ECMAScript 6 standard has come together and evolved throughout its open development process. This past December and January, Wirfs-Brock said early-adoption browser implementers provided feedback on sub-classing features interacting with objects, leading to a last-minute redesign of how the ES6 sub-classing mechanism works with built-in DOM libraries.
Yet while the standard is designed to ultimately replace some of the language’s add-ons, Wirfs-Brock said there will always be a place for developers writing new libraries and improving the language on their own, and described the existing ecosystem as simply “massive.”
“Libraries are good. We want people writing libraries,” he said. “If what you need is, say, a new data structure or a family of algorithms, a library is a way to do that.
“Even two years ago, I might’ve said [the third-party ecosystem] is primarily in the browser, with a little server-side and other uses. This year I wouldn’t say that. You have the whole server-side community with Node.js and io.js, lots of pickup in embedded systems and robotics—it’s really all over the place.”
The ES6 specification itself gained final draft approval at the latest TC-39 meeting this past March in Paris ahead of the June Ecma general assembly. Once officially standardized, Wirfs-Brock said pressure will be on browsers to implement, and then on developers to use the language and its features in ways the committee never imagined.
“Browsers won’t wake up with ES6 today,” said Wirfs-Brock. “It’s an incremental process with very deep semantics at the deepest level of engines. At a language design level, we made things easier on developers by making the engine implementers work harder. We’ll also start to see the ES6 features, many of which are already in browsers, slowly benchmarking and optimizing over time. There’ll be pressure not only to get features implemented, but also equal pressure on browsers to up performance. An implementation is only guessing at what it should optimize, and that’s where browser competition is good. No browser (or by extension developer) will use the language in exactly the same way.”
Even more than the classes, modules and litany of other features introduced in ES6, Wirfs-Brock sees the larger legacy of the standard as establishing a new baseline for future updates and releases. Rather than a massive update every five or 10 years, the TC-39 committee plans a yearly release cycle with ECMAScript 7 arriving sometime in 2016 with cleanup and bug fixes.
“ES6 is a big spec with a big effort,” said Wirfs-Brock. “Out of the 650 pages, about 550 of them are pseudo-code algorithms; essentially a piece of software. We’re definitely taking more of a train model to see which new features are added from year to year going forward.”
On the horizon for ES7 are several features in active development, including enhanced asynchronous programming support, single instruction, multiple data (SIMD) support, high-performance computing and hosting other languages, along with further enhancements to classes.
For Wirfs-Brock’s part, the standardization of ECMAScript 6 represents the culmination of more than a decade of work, and a radical culture change in both how JavaScript is used and how it is perceived.
“People don’t realize how significant this is,” he said. “Every once in a while, a piece of technology is situated in the right place at the right time, and it ends up taking over the world. Ten years ago I saw JavaScript poised to be in that position. What we had before was really what Brendan Eich came up with over 10 days in May of 1995. This is a new foundation for what may be the most important programming language of the next several decades, and ES6 is probably the foundation of JavaScript for the next 10 or 15 years.”
Breaking down the JavaScript ecosystem
Travis Smith, a senior consultant at technology integration and management firm iVison, ran down some of the most popular and useful JavaScript frameworks, libraries, superset languages and runtimes currently populating the ecosystem.
Visual libraries
jQuery: A cross-platform library that simplifies HTML scripting, animations, event handling and AJAX development on the client-side. “Developers need to be keenly aware of mobile devices and how much data we’re sending across as far as JavaScript overhead. So instead of jQuery, use jQuery Mobile,” said Smith. The cross-platform client-side scripting library is still the most popular JavaScript library used today.
Bootstrap: “Typically used in HTML/CSS, Bootstrap also has a JavaScript layout that’s beneficial in giving a consistent look, feel and ease of writing HTML,” said Smith. “As a JavaScript developer, most of us tend to be either front- or back-end people, and rarely do you have one that crosses over both sides with UX and functionality. Bootstrap’s triggers and plug-ins make sure it all works together.”
Moment.js: A library for parsing, validating, manipulating and displaying dates in JavaScript.
Data libraries
D3.js: “A phenomenal library for data and data visualization,” according to Smith. D3 performs data-based document manipulations using HTML, SVG and CSS aligned with Web standards.
Datajs: “A really good one for data manipulation, and more for application development around Big Data,” Smith said. Datajs is a cross-browser library that leverages JSON, OData and HTML5-enabled browser features.
Breeze JS: “This one is a favorite to use within SharePoint. The great thing about Breeze is it works with Angular, which can be a standalone app or integrated inside of SharePoint,” said Smith. Breeze manages data natively on JavaScript clients, and is compatible with HTTP and JSON.
App pattern frameworks
Angular: “Angular depends on how much complexity you want to use,” said Smith. “It gives you a lot more granular control. Angular does extremely well with calling and manipulating data from the browser. The cool thing about Angular is its Material Design CSS framework. It pushes the envelope for flat design. That partnership between Google and Microsoft, however ironic, shows a much more collaborative and open-source commitment.”
Backbone.js: “Now a core part of WordPress, Backbone tends to be a little bit lighter on the front end. It’s also very good for DOM manipulation,” said Smith. Backbone uses key-value binding and custom event models to structure JavaScript-heavy Web applications connected to a RESTful JSON interface.
Ember.js: “Ember has a really good HTMLBars [previously known as Handlebars.js] template engine,” Smith said. Ember’s architecture is based on the model-view-controller, and is best designed for creating scalable single-page applications using a rich object model and two-way data binding.
Knockout.js: A Model View ViewModel library for creating desktop-like JavaScript and HTML UIs, using declarative bindings, templates and automatic UI refresh.
Scripting tools
Grunt: “I use Grunt for all my builds, automation and modification,” said Smith. “It really streamlines workflows so you don’t have to think about them. Previously you had to copy/paste files onto one and use all kinds of third-party tools. But now you can use server-side JavaScript to make it all happen.”
Node.js: “I’m always nervous about a Node server going down, but now Azure takes care of that with its high-availability IaaS availability for Node,” said Smith. “The biggest thing I use Node for is real-time data. Not the AJAX haul, but real-time in the sense of Big Data being updated on the server and Node updating the front-end data visualization immediately.”
Underscore: JavaScript’s “utility-belt,” it is a library with utility functions to simplify functional programming without extending built-in objects.
Lightning.js: An asynchronous embed code for third-party JavaScript to deliver third-party code safely without blocking window.onload.
Supersets and assorted libraries
TypeScript and CoffeeScript: “Every developer should be familiar with TypeScript and CoffeeScript,” Smith said. TypeScript adds optional static typing and class-based object-oriented programming, while CoffeeScript transcompiles to JavaScript with added syntax inspired by other languages such as Haskell, Python and Ruby.
Dart: Google’s Dart programming language is a class-based language with C-style syntax for complex Web application development, which recently pivoted its strategy with the goal of compiling to JavaScript.
The list of languages that compile to JavaScript is a mile long, but a useful summary list is available on GitHub.
Phantom.js: A scripted headless WebKit and JavaScript API that “can do a lot of things,” said Smith. “It can browse, scan, and crawl sites posing as a WebKit or a browser. It’s one of those lesser-used libraries, but a subset of developers loves to play with it. Phantom is good for unit testing, good to couple with Jasmine [a behavior-driven JavaScript framework], good for screen captures and to check servers running Node.”
PDF.js: Built with HTML5 and used for parsing and rendering PDFs, “It’s a library from Mozilla that pushes the boundaries of what browsers should be able to do with PDFs,” said Smith.
