Anders Hejlsberg

And then we have an optional stage at the end called our emitter.

And normally the emitter infrastructure in a compiler is also quite big because that's where you go from intermediate representation to machine code.

or bytecode.

Now, in our case, we just erase types, if you will.

Well, we kind of do two things in our compiler, actually.

Early on, it was very much about A, erasing the types, but B, also down-leveling your code.

So we would take newer ECMAScript features that weren't yet supported by the runtimes, for example, classes, and then we would down-level them to constructor functions and whatever.

And so we would rewrite the code.

And that was a very popular feature early on.

Now,

Pretty much every browser is evergreen and, you know, like ECMAScript features are caught up.

And so that's not as important anymore.

So our emitter is effectively, you know, a thing that just erases type annotations and spits out the JavaScript code that can run unannotated and also can spit out declaration files, which are summaries of your modules and so forth.

But those are sort of the stages.

Now, the thing that's interesting about the compiler though, is that it's built in a manner that, where it can function in a highly interactive mode, which is what the IDE uses.

Normally, you know, command line compilers, they just run through these stages and, you know, the output is just whatever gets emitted or some error messages, right?

But in an IDE, you know, the compiler is a service and what we do in that service is

We basically take a program that is perpetually broken because you're typing.

And yet we try to syntactically or semantically analyze it.

And because we need to know when you press dot here, what could come next?