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.