Image by MiraCosic via Pixabay

When it comes to change, TypeScript’s team plays the long game, building up better experience over time, said Daniel Rosenwasser, senior product manager over TypeScript at Microsoft. The open source standard, a superset of JavaScript, is frequently used as the foundation for frameworks.

In this Q&A with The New Stack, Rosenwasser shared TypeScript’s most significant developments in 2023 and provided a preview of what developers can expect to see in the coming year.

Q: What do you think was the most significant change in 2023 for TypeScript?

Rosenwasser: It is hard to pick just one thing — we’re always trying to make things better in big and small ways. But 2023 was pretty huge for us. We’re really proud of how lean and fast we made TypeScript while bringing in quality-of-life checking improvements, long-awaited features, ECMAScript features, some of which we championed in TC39, and delighters in the editing experience in Visual Studio and VS Code.

I’ve got to call out decorators as one of the most significant changes. Previously, TypeScript implemented an old design of decorators, but 5.0 brought the new standardized behavior to developers. In 5.2, we implemented a related feature called decorator metadata. Decorators are powerful building blocks that can add metadata and modify the behavior of classes, methods, properties and parameters. Framework authors define their own decorators that any other developer can use.

We also championed and implemented the “using” of declarations and explicit resource management. “Using” declarations lets you declare variables that are automatically disposed of when they go out of scope, ensuring resources are released even when an exception occurs.

I’m also a big fan of the improvements we’ve made in the editing experience. We’re now providing more completions that scaffold out entire regions of code, we have linked cursors in JSX tags, we’ve shipped helpful new refactorings for inlining variables, and we’ve made our inlay hints richer so you can jump to different parts of your code from them. Those are investments in both authoring and exploring code.

Finally, it’s hard to ignore the most recent developments around AI. TypeChat is an experimental new library a few of us have been involved in to bridge the gap between the “loose” or “imprecise” world of AI, with the very precise world of traditional software. That bridge is built on types, and working on TypeScript has given us a useful perspective here. So while we’re also working on support for Python and .NET, we hope TypeChat can make AI more accessible for TypeScript developers.

Q. What’s your number one goal or priority for TypeScript headed into 2024?

Rosenwasser: This past year we got a few big wins on performance in TypeScript. Part of this came from large-scale refactorings that allowed us to leverage modern build tooling. Some of it came from finding smart ways to avoid doing work in the type-checker. We really want to keep pushing on speed, and we’re hoping that with the work we’ve put into performance testing infrastructure, we can dive deep and make TypeScript faster.

The key elements TypeScript is focused on — making typed JavaScript more expressive, championing and supporting new ECMAScript features and powerful editor improvements — are still going to be there and moving forward.

Q. What will be the most significant change developers can expect to see with TypeScript in the coming year?

Rosenwasser: So much of what we do with TypeScript is about playing the long game, building up a better and better experience over time. That said, there’s one thing I’m excited for when it comes to big codebases at scale. We’ve been collaborating with teams at Bloomberg and Google to prove out a mode where TypeScript projects can be type-checked completely independently of each other, even when you’ve got a bottleneck in your dependency graph. The concept is called isolated declaration emit.

For some background, TypeScript has these things called “declaration files.” They’re like header files, and they’re useful for describing untyped JavaScript code but they’re also a lighter-weight way to summarize a TypeScript file that’s already been type-checked. Declaration files are usually way smaller to read and process, and so when you check and build a project, TypeScript can create declaration files for each of your inputs.

The problem is that TypeScript does a good bit of type inference, which means that generating these declaration files requires type-checking them. But when you want to check one project against its dependencies, you have to perform a full build and type-check on the dependencies. So the idea with isolated declaration emit is that each “public” part of your module’s API needs to have a type annotation. When that guarantee is in place, it means that TypeScript doesn’t have to do any type-checking to generate outputs. An orchestrator can generate declaration files across all your projects in parallel. That unlocks all sorts of tools to generate declaration files, even the ultra-fast compilers and bundlers that developers have been using and loving.

We’ve spoken with developers on esbuild and Vite and others, and they’re interested in seeing how this could work. For a few months now we’ve been working with folks at Bloomberg and Google where they’re really trying to test this to the extreme, and so far we’re bullish on the results!

Q. Is there anything that developers should prepare for? How?

Rosenwasser: As we’ve gotten new users, we’ve heard the challenges of learning TypeScript. That has pushed us to rethink the balance between simplifying things and preserving compatibility.

With TypeScript 5.0, we think we found a good balance to start shedding flags that don’t really have a future with modern JavaScript tooling. With 5.0, TypeScript started issuing deprecation warnings for some rarely-used options that haven’t been that relevant for years. If you’ve already upgraded to TypeScript 5.0, using these options issues an error unless you use the --ignoreDeprecations flag.

By TypeScript 5.5, users won’t be able to suppress those errors. Since TypeScript 5.0 has come out, we haven’t heard complaints about these deprecations, which is reassuring. It means that most developers won’t run into any issues here.

Q: What do developers want most that they might get? Is there anything that developers want but will have to wait another year?

Rosenwasser: We have heard developers want to run TypeScript with no friction — no build step if possible. We’ve put a bunch of work to achieve that with the type annotations proposal, but making that land is going to be a very big step. Luckily, we’re seeing incredible work from compilers that can build projects as fast as you can blink, and runtimes that run TypeScript natively. The truth is that TypeScript is already a breeze to run in a few places, so the question is: Where isn’t it? Could it be easier to run TypeScript in Node? In a REPL [read–eval–print loop]? We’d love to find some of the smaller steps that make running TypeScript feel transparent.

Of course, TypeScript is also built in the open. We’re always looking for community feedback on what developers are missing from the TypeScript experience and what they’d like more of.

Loraine Lawson is a veteran technology reporter who has covered technology issues from data integration to security for 25 years. Before joining The New Stack, she served as the editor of the banking technology site Bank Automation News. She has...

Read more from Loraine Lawson