JavaScript’s time in the limelight is definitely at hand. The language is moving forward at a good pace, Node and npm have standardized a lot of the busywork, and the web continues to grow every day. As cross-platform languages go, JavaScript is the new Java.

That doesn’t mean everything is all right for JavaScript developers just yet, however. While the language climbed from No. 8 to No. 7 on the TIOBE Index for January 2017, it’s still a language that can give traditional enterprise developers problems.

JavaScript is a dynamic, untyped language. As a result, building extremely large projects can be tough due to the lack of end-to-end support for modern IDE capabilities, like safe refactoring.

(Related: Open source keeps growing, but not without pains)

That’s where TypeScript comes in. Created by Microsoft in 2011, TypeScript is a type-safe superset of JavaScript that transcompiles into JavaScript. As a result, IDEs like Visual Studio Code can offer much better support for large teams developing a single project.

Burke Holland, director of developer relations at Progress, said that the type-safety and IDE support behind TypeScript has made it a compelling language for enterprise software developers.

“TypeScript allows developers to get the tooling they need to build what is otherwise impossible to build in JavaScript: really large web applications,” he said. “TypeScript effectively takes the quirkiness of JavaScript out of the equation. It provides all the proper constructs they need to build large enterprise applications. No Java or C# developer was going to throw out a decade of knowledge to write JavaScript. Now, with TypeScript, all the things we learned about programming can be applied to JavaScript.”

TypeScript’s popularity
The appeal of TypeScript to enterprise developers was certainly helped by the decision at Google to build Angular 2.0 with TypeScript. Since that time, however, it’s no longer the only JavaScript framework that can handle type safety.

TypeScript can add type-safety after the fact through the inclusion of a file that behaves like a header, which describes all the types contained inside an application or framework. Today, the DefinitelyTyped repository on GitHub contains thousands of these files for use with the thousands of JavaScript frameworks and libraries that exist in the wild, effectively making them type-safe and TypeScript-compatible.

On that aforementioned TIOBE Index, TypeScript has not even cracked the Top 100 list of programming languages yet, but TIOBE’s editors noted the language was rising fast, moving from No. 167 to No. 137 in a single year’s time.

Does that mean 2017 could be the breakout year for TypeScript? Anders Hejlsberg, technical fellow at Microsoft, certainly hopes so. He’s been working on the language since its inception. He said that TypeScript solves a problem that enterprise developers have had since the JavaScript revolution began.

“Now we’re seeing people writing even million-line applications in JavaScript,” said Hejlsberg. “That’s very hard in a language that lacks the constructs you need to build large applications. There were no modules, nor was there a static type system to help guide your programming effort. We’ve known for decades now that the magic sauce that really powers the productivity of those fantastic IDEs we use today is static typing, and the ability for the IDE to reason about the programs you’re writing, and offer consistency, statement completion, safe refactorings, finding all references,” and other amenities.

“We have a lot of experience with type systems. We were even seeing people do crazy things, like write their JavaScript apps in Java or C#, then using transpilers,” said Hejlsberg. “Google wrote large applications in GWT, and there was a similar project in C# (Script#), which Microsoft had even used internally.

“Honestly, you’re never going to be the best of breed in one ecosystem by jury rigging another ecosystem to target it. Our feeling was that there was something we could do here to allow us to fix the things missing in JavaScript, but do it in a way that was completely synergistic with the existing ecosystem.”

Onto the enterprise
TypeScript has been gathering a following in enterprise circles. But it’s not just the type-safety that draws them in, said Hejlsberg. Another great aspect of TypeScript is that Microsoft is pushing the bleeding edge of ECMAScript features into the platform, long before those features are available across browsers.

“The ECMAScript committee has made a lot of progress in ECMAScript 2015,” said Hejlsberg. “It adds things people want, like modules, classes, lambdas and destructuring. It’s a very ambitious and big rewrite of the language, but it takes a while for new revisions of ECMAScript to reach the ecosystem. People are still using old Android phones with old browsers, for example. What you need is the ability to transpile, to give you the illusion you’re using the new JavaScript, but then turns it into ECMAScript 2 or 3 so it runs everywhere.”

And that’s exactly what the TypeScript team has enabled. The language is already ECMAScript 2015 feature complete, so much so that the team is cherry-picking features from ECMAScript 2017, said Hejlsberg.

For the rest of the TypeScript community, 2017 should be a year of growth. Hejlsberg said that the project has been growing as major events occur, such as Microsoft moving the project from CodePlex to GitHub, or when Angular 2.0 was released last year.

That doesn’t mean the work he and the TypeScript team at Microsoft are doing is limited to their language, however. He said one of the major goals for the Visual Studio Code team is to support as much of the TypeScript feature set in the IDE as possible for standard JavaScript code.

“If you have plain JavaScript, we can still do quite a lot. It used to be that static typing was a switch. It was either off or on. What’s happened with TypeScript is that we’ve sort of turned that switch into a dial. The more type info you give us, the more help we can give you,” said Hejlsberg.

The Language Server Protocol
Last year, the Language Server Protocol was announced as a collaboration among Microsoft, Codenvy and MuleSoft. This open-source protocol was built to uncouple the IDE from the language it supports. As a result, developers can now implement language supports like syntax completion, code highlighting, compilation, and refactoring in a language server instead of in any specific IDE.

Developers can use the LSP to build their own language server. When done, that language is then supported in any IDE that supports LSP. Currently, those languages are Visual Studio Code, Eclipse Che, Eclipse IDE, and even emacs. Other supported languages include Go, Groovy, Rust, Scala, Python, Haxe, PHP, OCaml, C, C++, and more.

PJ Meyer, senior product marketing manager at Microsoft, said that the Language Server Protocol has a few goals behind it. “One is to help democratize the sorts of benefits accessible by some of these systems to not just our development tools, but to any development tools,” he said,

“That’s important to help foster and continue the community, but I think also anyone writing a language server, or who wants to help contribute to the community, they can do it in a common way that will make it light up in as many tools as possible.”

The end goal is to “decrease the amount of work a developer has to do to make a project light up in their tool,” said Meyer.