Is Typescript a language or a linter?

As a longtime TypeScript developer, I often get annoyed when people refer to TypeScript as its own programming language. I believe this characterization can be misleading, so I wanted to write this post explaining why I view TypeScript more as a linting tool than a standalone language.

Why I View TypeScript More as a Linter Than a Language

The motivation stems from my daily usage of TypeScript and where I see its real value arising for me as a developer. While it technically compiles to JavaScript, the vast majority of what I leverage is the linting and type checking that catches errors and enforces best practices in my code. This linting behavior is what dominates my TypeScript experience.

Since the TypeScript code itself is not runnable, and the output JavaScript is incidental, I wanted to put forth the argument that the core of TypeScript is this linting capability. The post comes from my desire to clarify this nuance and why TypeScript feels more like a linter through the lens of a practicing full stack developer actually writing TypeScript daily. I hope it provides food for thought around how we categorize and describe this important tool.

I tend to think of it more as a linter for JavaScript rather than a full-fledged programming language. Here's why from my experience:

TypeScript Code Isn't Directly Executable

First off, TypeScript code itself is not executable. It has to be compiled down to plain JavaScript before it can actually run. Pure TypeScript cannot be executed on its own. This is quite different from traditional programming languages that can be interpreted or compiled directly into executable code.

The Core Value Comes From Type Checking

The main value of TypeScript comes from its static type checking and error catching as you write code. It's constantly analyzing your types and usage in the background, giving you real-time feedback and catching bugs early. This provides a lot of the same benefits as a linter like ESLint.

In fact, there's significant overlap in the types of issues that TypeScript and ESLint will identify - unused imports, missing declarations, mistyped variables, etc. The type checking is just another form of linting.

The Output JavaScript is Secondary

When I'm actually writing TypeScript on a daily basis, most of what I'm experiencing is this linting behavior rather than any features specific to TypeScript as a language itself. The compiler outputs JavaScript that I don't really interact with.

But the linting makes my code more robust, helps enforce best practices, and catches a whole class of errors before they occur. The red squiggly lines have become invaluable.

Why I Prefer "Linter" Characterization

So while TypeScript straddles the line between a language and a linting tool, as a developer working in TypeScript every day, it feels much more like the latter. The type checking is what provides the real value. The output JavaScript is secondary.

You could maybe argue that half of TypeScript is a language while the other half is a linter. But during development, the linting experience and feedback loop dominates. This is why I tend to think of TypeScript more as just a smart linter for JavaScript than a full language in its own right.