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.
The tooling and browser evolution
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.
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.”
“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.”
“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
“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.
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.
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.
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.
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.”
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.
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.”
Supersets and assorted libraries
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.