TypeScript 2.5 is there! That's the headline of the tweet sending me to the TypeScript 2.5 announcment. To my surprise, the article described a new refactoring of Visual Studio Code. Did they choose the wrong title? Is this article really about TypeScript, or is it about an IDE?
As it turns out, refactoring is baked into the programming language. In former times, refactoring used to be what IDEs do. Nowadays, refactoring is a compiler feature. At least in the case of .NET languages and TypeScript.
Analyzing source code
Traditionally, IDEs analyze the source code. In the early days, they were limited to syntax highlighting. Actually, these days were not even that early. According to Wikipedia, the first editor using colors has been developed in 1985. It arrived at my personal desktop many years later. I'm not sure if it was in the late 90s or the early 2000s. I remember that I tried to tweak the highlighting algorithm of Borland's Java IDE in 2001. I quickly ran into performance problems. At the time, hardware wasn't fast enough to support sophisticated syntax highlighting.
Things have changed a lot. Nowadays, we expect our IDE to detect errors at real time. Code smells are marked with yellow squiggly lines. Errors are marked red. There's code completion, and it's even considering the context to bring the most popular choices to the top.
This can only be done with an IDE that's very familiar with the programming language. Basically, it has to implement a parser analyzing the code. Most IDEs, such as Eclipse, also implement a tool generating an abstract syntax tree (aka AST). In other words, the Eclipse editor implements its own compiler. Or rather, something that's stopping just short of being a compiler.
Using the compiler as a service
But that's rubbish. Mind you, every programming language has got a tool analyzing the source code and building an AST. I'm referring to the compiler. So why don't we use that compiler as a service analyzing the code?
That's the idea of using the compiler as a service.
The compiler used to be a block box consuming source code and emitting binaries. The idea is to add an API to it. This API can be used by your IDE to ask the compiler to analyze the code. This API includes syntax highlighting, compiler checks, and refactorings, just to name a few options.
Reality check
As far as I know, few compilers support the "as a service" concept. Basically, it's only the Microsoft compilers. But this may change soon. Modern IDEs are expected to support many programming languages. But there are only so many languages a team can support. From this point of view, delegating the hard task of analyzing the code to the compiler makes a lot of sense.
Wrapping it up
The language designers and the compiler builders know their programming language as nobody else does. Thus, they can support many IDE tasks like syntax highlighting, marking errors while typing, code completion, and refactoring better than everybody else. So it's a logical step to implement these features in the compiler and to expose them via a public API.
Of course, this also means that every IDE offers the same refactorings and code completions. I'm curious what IDE developers are going to make of it. I'm also curious if other programming languages, such as Java, are going to adopt the "compiler as a service" idea.
In any case, it's interesting to observe the evolution of what started as a simple command-line tool. Nowadays, it's a process running continuously running in the background, watching the file system, generating new code each time a source code file changes, and notifying the IDE of the changes.