TypeScript 7

https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/

720 301 14 days ago

devblogs.microsoft.com

the real story here is an incredible team that managed to simultaneously keep two separate codebases alive for the most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out).

huge congrats to the team!

looking forward to the Rust rewrite ;)

DonaldPShimoda• 14 days ago

Most complex, perhaps, but not "most advanced". I don't think there's necessarily a meaningful "correct" choice for that title, but surely one of the proof assistant languages would be a more likely candidate?

(I don't say this to be disparaging of TypeScript's type system, by any means — it's very interesting stuff!)

dimitropoulos6• 14 days ago

good points, let's get negated types and higher kinded types in there then you've got yourself a deal. maybe regex thrown in too for flavor

hoppp2• 14 days ago

I am not sure a rust rewrite would be meaningful.

Go is great because it's fast to code.It's easy to reimplement typescript in go 1:1 just by looking at the code.

Rust on the other hand would take a lot longer to develop.

Maybe rust is 20% faster than go but overall the increase from typescript with go is good enough.

Maybe rust would yield a 14 times speedup over the 11 times in vscode but go is already good enough to make a huge difference.

dimitropoulos6• 14 days ago

jokes aside, have you heard of the Jevons Paradox[1]? it feels like the "induced demand" effect to me with the whole "just one more lane" phenomenon you sometimes can see in roadways. when you increase the efficiency of a thing you thereby expand the set of things it can economically be used for, causing an overall increase in total consumption over time - not a decrease like you'd expect from just having made it much more efficient. "a smaller slice of a much bigger pie is still more pie" or something like that.

in TypeScript's case with the "pie" being compute time, things like HKTs (e.g. hotscript, hkt-toolbelt) that might not have made as much sense in the past suddenly become so much more feasible, but also are the very things that drag that hard-fought efficiency win back down into the mud. is it worth it? library authors will ultimately be the ones to decide the big chunks of that question by virtue of what they ship in their types.

[1] https://en.wikipedia.org/wiki/Jevons_paradox

nicoburns3• 14 days ago

The benefit to Rust rewrite would be integration with the rest of the JS tooling ecosystem which is increasingly written in Rust rather than performance.

It probably won't ever happen though.

It's easy to reimplement typescript in go 1:1 just by looking at the code.

That's also true of Rust if your codebase is written in a functional style. But apparently TSC had a lot of inheritance, which probably isn't a great fit for porting to Rust.

afdbcreid• 14 days ago

A Rust rewrite would have an easy way to expose an API, something they're still debating how to do and deferring to 7.1.

But the team has already choose. They explained their reasoning and IMO it makes sense: they didn't want a rewrite, they wanted a bug-for-bug file-by-file translation. With a borrow checker and no GC, Rust sometimes forces you to structure things differently (especially in a compiler that usually has a lot of circular structures), so it was not worth it.

tshaddox2• 14 days ago

most advanced type system known to mankind (yeahhh yeahh Hindley-Milner eat your heart out)

This TypeScript release is largely about performance. Isn't OCaml still at least twice as fast (and maybe even faster for incremental compilation on very large codebases)?

whilenot-dev• 14 days ago

I don't think GP was referring to transpilation speed when they wrote "most advanced type system known to mankind".

samuell• 14 days ago

Steve Francia (author of Hugo and a bunch of other top Go projects) wrote up some thoughts of Go's fit in the agentic era:

https://spf13.com/p/go-the-agentic-language/

mightyham• 14 days ago

in my experience, a change that stays local in Go ripples through lifetimes and trait bounds in Rust

imo extensive use of generics/trait bounds and explicit lifetimes in Rust is a huge code smell. Large projects should be making liberal use of trait objects and smart pointers to keep everything understandable and modular. Giving an agent a simple coding practice SOP for Rust should be enough to garuntee basically the same localized refactorability that Go has.

paxys• 14 days ago

They picked Go after meaningfully considering Rust (and others). I don't remember all the reasons for it but it was detailed in the original blog post.

Cthulhu_7• 14 days ago

There's the blog post (by Anders Hejlsberg, the author of Turbo Pascal, chief architect of Delphi, currently lead architect of C# and a core developer of TS; I'd say he knows his languages), but they also posted FAQs, here's some good reads:

The blog post: https://devblogs.microsoft.com/typescript/typescript-native-...

Why Go? https://github.com/microsoft/typescript-go/discussions/411

Why a port instead of a rewrite? https://github.com/microsoft/typescript-go/discussions/410

mejutoco2• 14 days ago

for the most advanced type system known to mankind

Honest question, what do you mean by this?

culi2• 14 days ago

It means they really like TypeScript and they hope to influence some juniors into investing themselves into it

dimitropoulos6• 14 days ago

I answered here https://news.ycombinator.com/item?id=48838629

giraffe_lady3• 14 days ago

Algorithm W is like undergrad level of sophistication. People who like HM more (and I am one) don't like it because it's "advanced" and to some extent exactly because it isn't. It's sound and fast and infers almost everything. TS seems to have one of those features now, so that's nice.

MiTypeScript2• 14 days ago

sub-1day-first-frame-of-DOOM LFGGGGGG

chamomeal• 13 days ago

I am also pretty stoked about the doom performance improvements lol

willchen• 14 days ago

really excited to see this release! i've been using TypeScript for several projects like https://github.com/dyad-sh/dyad which is >250k lines of TypeScript and the speed-up makes things like running typescript check as a pre-commit hook painless

thanks DanRosenwasser and team for building such an awesome tool for so many years!

terpimost• 14 days ago

Are there any plans about wasm version?

spankalee• 14 days ago

Yes, but no official builds yet that I know. This is a really important issue for online playgrounds and IDEs.

raddan2• 14 days ago

I am a little surprised that they rewrote the compiler in Go instead of just compiling the existing compiler to WASM. The linked announcement does not talk about a WASM alternative at all (rewriting a compiler is a risky move!). Does anybody know what the rationale was to do a full rewrite? The article really emphasizes speed, but not much else. Was it Go's concurrency affordances that made the switch worthwhile?

jakebailey2• 14 days ago

Hoping to start getting Wasm builds out soon; it's a little unclear what people want when they say "Wasm", because it could mean

- LSP monaco - the API in the browser - the CLI in Wasm for platforms we couldn't build

which muddies the water a bit, but I'm sure we can get it working

adamddev14• 14 days ago

Remember when people would argue about how types weren't worth the effort?

I love TypeScript, if nothing else for how it's been able to popularize types.

ajkjk7• 14 days ago

I don't think ... serious people... argued that.

That's a bit hyperbolic so I'm sure I'm wrong, but I have an ace: if you point me at very smart people who argued against types I'm gonna say that they weren't serious. I think it's not possible, if you have the relevant experience of working on both typed and untyped codebases of at least moderate complexity with at least one collaborator, to come away seriously believing that the untyped way is superior (unless you were forced to use a really bad typed language, I guess). And arguing that untyped languages are better without that experience is also not serious, in the sense that anyone can unseriously say anything if they don't care about being well-informed enough to be right.

samtheprogram• 14 days ago

....they did ...and... the camp still exists

ChadNauseam• 14 days ago

It's easy to say that now, but it used to be that all mainstream typed languages had absolutely terrible type systems that got in your way as much as they helped

hombre_fatal2• 14 days ago

I don't think ... serious people... argued that.

Static vs dynamic typing is no less ubiquitous in online forums over the decades than tabs vs spaces and vim vs emacs.

steve_adams_863• 14 days ago

I worked with people who would consider themselves serious, and are still in the industry and doing fine. A few have certainly gone on to be more prominent and get paid a lot more than I am—not that it's a perfect measure of seriousness.

In the early days they would often say things like "but we have prop types, why use TypeScript", "why not use JSDoc" (this made no sense at the time), or "it's an exercise in needless complexity". It was really tough to sell them on TypeScript for years.

I think there are developers who are very goal-oriented with a narrow perspective on getting from point A to point B, and their understanding of the process isn't particularly holistic, rigorous, or geared towards external or knock-on factors like maintainability, performance, bugs, etc. They deal with it when circumstances force them to, and no sooner. Defining types is a complete waste of time to someone like that.

These people thrive where teams are primarily expected to just ship things, and in my experience they often hate needing to think about things like types, tests, or code quality beyond running a linter.

So, they're serious people in one school of thought. They contribute meaningfully to projects. I think they're a large constituent of the new class of vibe coders who laugh at you if you look at the code. That's fine, they're doing their thing, and there are more than a few ways to get programs into people's hands. That way just isn't the way I like to.

horsawlarway2• 14 days ago

Look at some of the typing present in MS COM back in the IE5/6 days and we can discuss more. I can honestly tell you - I'll take untyped languages any day of the week over that clusterfuck.

Personally - I also think people really underestimate just how much the tooling around types has improved over the last 20 years.

If I'm having to try to look up the difference between iBrowserInterface6 and iBrowserInterface5 and iBrowserInterface4... (and yes - shit like this really did exist: https://learn.microsoft.com/en-us/windows/win32/api/shdeprec...)

And I have no tooling for autocomplete, and the docs are shoddy, and google is just coming on the scene...

People understandable want to throw their computer out the window.

Types are great. Some forms of them were not.

mrkeen• 14 days ago

They're still right here in sibling comments

claytongulick• 14 days ago

I've been writing code since the 80s, professionally since the mid 90s, in almost every major language, platform and operating system, from 8 bit microcontrollers to large scale web platforms.

So, not sure that counts as "serious" in your estimation, but I would definitely argue that dynamically typed languages are superior for a large class of problems.

Also, just a tip: it's usually better to be less sure of yourself, and seek to understand other's reasoning. It'll get you a lot farther than trying to convince everyone of how right you are.

If you're not sure why an experienced developer would hold an opinion different than yours, why not just ask?

chem83• 14 days ago

dhh is still not very fond of it. To each their own.

https://world.hey.com/dhh/turbo-8-is-dropping-typescript-701...

tiffanyh• 14 days ago

TypeScript just gets in the way of that for me. Not just because it requires an explicit compile step, but because it pollutes the code with type gymnastics that add ever so little joy to my development experience, and quite frequently considerable grief. Things that should be easy become hard, and things that are hard become `any`. No thanks!

That comment is expected by a Ruby enthusiast, which is arguably one of the most dynamic languages in existence.

IshKebab3• 14 days ago

I mean he's a Ruby developer. He has to delude himself that static typing is a waste of time.

kstrauser3• 14 days ago

I don't recall anyone disliking types. Lots of people disliked static typing, or more directly static, explicit typing. For instance, I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension.

There are some genuinely untyped languages, or more typically "stringly typed" ones. I hacked around on AREXX as a youth, where all values are strings, even when they look like numbers. Most of the Unix CLI tools like sed could be, uh, said, to be stringly typed. Most of the "discussions" about typing, though, involved Python and similar dynamically typed languages. I don't think I've ever heard someone claim that weakly typed or untyped languages were great for building large project. I've heard plenty of people claiming that Python couldn't be used to build large projects because it was dynamically typed, or "untyped" as they wrongly described it, which was confusing to those of us using it to build large projects.

sysguest• 14 days ago

I don't recall anyone disliking types
where people would say goofy things like they couldn't use Python because it's untyped. That's insane: Python is strongly typed. It's also dynamically typed, which is a different dimension.

hmm maybe you don't understand type-checking INSIDE IDE, NOT during runtime?

_flux2• 14 days ago

There's a school of thought that consider the term "types" reflect to the properties that exist in programs even before they are run, as in they are a property of the programs themselves, not their state at runtime. This thinking—which is also what type theory talks about—does consider Python untyped: reading a Python program along with its specification, you are not able to assign types to each expression.

But what Python does have is tagging: when you create an object you tag it, and then whenever you operate on those values, you check the tag and maybe raise an exception or not. This is happening at runtime.

Strongly typed and weakly typed do not seem to have good definitions. A good one I've read is that "strong typing describes the typing you like".

It is great though if people go to the same extent as you to define what they are talking about, as this reduces the chances of misunderstandings. But it should not be taken as fact that the definitions you have chosen are the universally accepted ones.

tgv2• 14 days ago

Puthon is so strongly typed it lets you assign a string to an integer variable, and or compare the two or add a float and an int. Or multiply an array by a number; something which gets overturned if you use numpy. Python's strong typing mostly boils down to some operator rejecting mixed types.

baq• 14 days ago

haven't seen this flamewar in a while. can't say I missed it. surprised people still argue about it, having written my first Python around 1.5.

for the record - I agree completely.

(glad people are over the unicode thing!)

tyingq• 14 days ago

Last I tried, there's still often (not always) fighting with typing, mypy, pyright because of the dynamic nature you mention. I think the complaints about it are sometimes misinterpreted as "disliking types".

nsonha• 14 days ago

static, explicit typing

the kind of types that helps you reason and read the code. As opposed to the type you mostly don't have to think about anyway, which is complete missing the point.

munchbunny• 14 days ago

I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped.

I'm not sure I would go that far, but I would definitely say that I remember many, many moments where a Python codebase hit critical mass and the amount of time I spent documenting and checking types exploded. It wasn't really about static, explicit typing, so much as "once my tools (IDE) are taken into account, how much time am I spending trying to reason about correctness?" Reasoning about types was the main contributor to that with Python before type annotations.

knocte2• 14 days ago

Python is strongly typed

Get the f*ck outta here.

IshKebab3• 14 days ago

I don't recall anyone disliking types. Lots of people disliked static typing

Come on, that was very clearly what he was talking about. No need to be this pedantic.

epolanski4• 14 days ago

I've been around many conversations over the years where people would say goofy things like they couldn't use Python because it's untyped.

I'm one of those, but what I mean is that there are no static types you (and the compiler) can reason about.

Moreover there's a difference between types as compiler bookkeeping, as in Fortran or C, and types as propositions about program behavior like in ML, which highly influenced modern type systems, including TypeScript, albeit Ocaml, F# and the Rust type system belong to the ML family.

bbg2401• 14 days ago

Remember when people would argue about how types weren't worth the effort?
if nothing else for how it's been able to popularize types.

This is such an odd, javascript dev take.

adamddev14• 14 days ago

I'm a Haskell and FP nerd as well. I just meant the argument and the popularity inside the JS/TS world, which is fairly significant. I think the world is a better place because of the widespread adoption of TS over JS.

wk_end• 14 days ago

It's maybe a bit of a startup-world, HN-blinkered assessment...but that's where we're talking, isn't it?

Even before JS became the language for everything, there was a good chunk of time - maybe between 2005 and 2015? - when Python and Ruby were dominant in this environment, and this dismissive attitude towards static typechecking was similarly dominant.

Of course in the enterprise space everyone was using Java, and in the systems space or game dev space everyone was using C++. But those worlds get a lot less airtime here.

Plus everyone on HN is a good little pg disciple, and Lisp is dynamically typed. If the One True Language doesn't need static typechecking (though SBCL offers some very helpful heuristics) surely it's not worth it. Right? Right?

austinthetaco5• 14 days ago

I still do argue that for JS. I have yet to see it worth the effort other than making things feel comfortable for former OOP devs coming from other languages.

edit: the downvote button HN is not for disagreeing with comments or unpopular opinions. please dont turn hn into reddit.

mamcx• 14 days ago

Yeah, I think was algebraic + pattern matching that break the ghetto. Suddenly types were far more useful without going crazy like Haskell!

P.D: Before, the exposure of types was from C++/Java, and special C++ is always a horrible exponent of anything except how make a overly complex language.

Once you see what good application of types look like, is far better sell!

lurkercodemnky2• 14 days ago

algebraic + pattern matching

Functional programmers keep hyping up ADTs like this but the normie programmer doesn't care about ADTs or immutability. What really brought back static types was Golang & typescript, both have local variable type inference, good IDE support & other tooling, and (at least superficially) lighter weight syntax than Java. Normies don't care about algebraic types, pattern matching, immutability, referencial trasparency, type classes. What matters is libraries and tooling.

nicoburns3• 14 days ago

Type systems just used to be bad. Anything that forces you to use a class hierarchy to represent an "OR" type (sum types) is painful to work with. Modern languages like TypeScript / Rust / Swift / Kotlin that have sum types are dramatically much nicer.

giraffe_lady3• 14 days ago

Algorithm W is 40 years old and HM has vastly better ergonomics than TS's types.

Why certain approaches didn't catch on until recently, or ever, is an interesting thing to think about but "we didn't know how" is not the story here.

dboreham2• 14 days ago

C also has sum types.

JoeyJoJoJr• 14 days ago

I have personally had three conversations (2 online, 1 in person) where the other person has said, almost verbatim, “I have never had a typing error in JavaScript”. Two of these people were people whose work I respected, so it could not understand how they could possibly hold that position.

antod• 14 days ago

It isn't wrong exactly. JS is famous for generally just trying to do something semi random instead of giving you a typing error.

That's the difference between "having a typing error" and "having an error due to typing".

well kinda

chuckadams• 14 days ago

"I have never had a typing error in Javascript" — [Object object]

dominicrose• 14 days ago

You can go a long way with just javascript, eslint and prettier if you work solo, but IME work is a low-trust environment which means that either you're a wolf and you do what you want or you have to use C# and enable nullable checks.

vlian2088• 14 days ago

people didn't argue against types, people argued against putting lipstick on a pig.

adamddev14• 14 days ago

Now I'm just waiting for DependentTypeScript :-)

zeroq4• 14 days ago

In 2004 we solved the types for JS with ECMAScript 4 (or ActionScript 2.0).

Unfortunately this was in the middle of browser wars, so no one cared about the standards and all of that work was lost like tears in rain.

Around that time I attended MS conference where they introduced IntelliSense and it was a forming experience for myself. You could do actual programming basically with <space>, <dot>, arrow keys and <enter>.

"x = " and there are only two variables in the scope with the same type so IDE will present them to you in a drop down and you can already think about the next line.

Fast forward to ~2015 when I'm working on Angular project. The whole idea feels like a caricature Chinese whispers of an OOP framework. Each component is divided into three files, all of them have to identify themselves using a magic string, and that string has to be manually entered into each file.

There are couple of type systems, like the one from Facebook, but no one is using them. And everyone claims that OOP and types are the thing of the past.

Part of that corelates to a joke I was making back in 2013, soon after Apple killed Flash and everyone started doing JS everywhere. Major companies where posting job offers for senior javascript devs asking for 5-7 years of experience. But someone who was doing JS for 7 years in 2012 has all his career focused around gluing together jquery plugins.

Anyway, I'm as well glad that we finally did a full circle and finally have some sanity in the industry...

koolba• 14 days ago

In 2004 we solved the types for JS with ECMAScript 4 (or ActionScript 2.0).
Unfortunately this was in the middle of browser wars, so no one cared about the standards and all of that work was lost like tears in rain.
Around that time I attended MS conference where they introduced IntelliSense and it was a forming experience for myself. You could do actual programming basically with <space>, <dot>, arrow keys and <enter>.

I think you’re off by at least 6-7 years. Visual Studio had autocomplete since at least version 6. And yes it was magical the first time you experienced it.

lobofta2• 14 days ago

God, do you remember that presentation Google gave when they introduced Angular 2.0? I think it was December 2015. It was sooo bad that in my eyes it killed Angular's momentum almost completely. I am surprised that it is still around actually. Can't find it anywhere though. Google must've censored it of the internet :)

Xixi2• 14 days ago

There's been a pendulum swing of sort during my career: static languages like C++/Java, then dynamic ones like Python/Ruby/JavaScript, and now back toward typed languages like TypeScript/Rust/Swift.

My read is that people were never really against types: they were against type systems that got in the way. Older ones often weren't expressive enough, so you ended up writing verbose patterns just to appease the compiler.

That's why dynamic languages gave startups a sizable velocity edge for a while. Modern type systems (with optionals, unions/sum types, inference, etc.) are completely different.

To paraphrase a comment I once read here on Hacker News: I'll take static typing with sum types over dynamic typing, but I'll take dynamic typing over static typing without sum types...

pjmlp5• 14 days ago

The irony is that I got introduced to the ML type system in 1996, but the industry takes its sweet time to adopt ideas.

lobofta2• 14 days ago

That is a very charitable read. I remember plenty of dumbasses who said: I don't need a type system, cause I know what I am doing and I don't create bugs.

Cthulhu_7• 14 days ago

It's important to remember that at no point was there a pendulum swing per se, that is, only few actually ported their Java code to Python for example.

The discussions and articles online seemed to infer that, but that's uh. media bias? Hype? Things written about and things you read online are not the full story, is all.

dboreham2• 14 days ago

You need to meet some people who argue that types are positively bad!

pjmlp5• 14 days ago

And how compiled languages were out of fashion, now everything is getting rewritten into them again, thankfully.

bjoli• 14 days ago

I would chose typescript over js, Python and perhaps ruby. but I would use Scheme over typescript. I would probably use f# or ocaml over Scheme for most projects.

it is not an either or.

techpression2• 13 days ago

I've seen TS hurt more than help in many cases, because people think types define the world, and then they get malformed JSON (or just a new structure) and their world crumbles.

Yes, it's a skill issue, but oh dear the amount of developers who have that issue.

Timon34• 13 days ago

How does TS make these situations worse? Seems to me that it helps a ton with identifying and fixing these issues. Either you can get away with just replacing the assertions with type guards, or you'll have to refactor some stuff (which is also much easier with types).

At worst, TS can only really be as bad as JS, no?

chroma_zone• 14 days ago

I'm glad the JSDoc type syntax is still getting some focus. It's my favorite way to use typescript in my own projects. Some of the syntax changes will be annoying to update but most of them seem to be for the better.

raddan2• 14 days ago

I'm glad that TypeScript uses JSDoc and not the hideous XML format [1] that Microsoft's other languages use.

[1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

seabrookmx• 14 days ago

I'm a big C# fan but XML docstrings definitely suck.

We also got stuck with XML-based project files somehow, despite .NET Core/.NET 5+ being a complete rewrite.

blurb2023• 14 days ago

finally it uses a normal language backend =)

stymaar3• 14 days ago

Performance improvements, yay !

It always surprises me how little complaints there have been on HN about tsc's performance. I do both TypeScript and Rust at work, and I've seen orders of magnitude more comments on the web about how “rustc is slow” than complaints about tsc's performance and it never stops to surprise me given than in practice the later have annoyed me consistently more than the former.

appplication• 14 days ago

As a TS dev, it’s probably because we already have such a high pain tolerance and low expectations.

MBCook• 14 days ago

I didn’t care. Because to me the performance was a cost I was more than willing to pay for giving me sanity in JS land. Knowing you were passing the right types, right number of arguments, etc. Just the quality of documentation you got from having types at all above the nothing we had before was huge.

I love they’ve made it a ton faster. But I never thought about giving it up due to compiler performance.

stymaar3• 14 days ago

But I never thought about giving it up due to compiler performance.

Exactly, no sound people should consider using another language because the CI takes 4 minutes to run instead of 12 seconds.

Yet on HN people complain about rust being “unusable because the compiler is too slow” in every other thread…

notnullorvoid2• 14 days ago

Performance of tsc wasn't an issue for small projects, and for larger projects it could be fixed by using incremental build option, and/or TS project references. Most either didn't care enough about the perf or were too lazy to set it up. TS7's perf boost will give people less of a reason to use these options.

dabinat• 14 days ago

I think Rust is noticeably slow for two reasons:

1. The default settings aren’t well optimized. So the pattern a lot of people fall into is: start a project and everything’s fast, then add more code and dependencies and everything gets super slow. Then you Google how to fix it, change some compile settings and restructure your project and it speeds up again. Rust requires knowledge and effort to keep compile times reasonable - it’s not set up that way by default.

2. Rust Analyzer / cargo check is inefficient and throws a lot of data away each time instead of caching it. So in a larger project you’re waiting on it to catch up. Waiting on Rust Analyzer to check my code is easily the largest amount of time wasted, more so than actually compiling it.

But it should be said that this is being worked on: https://rust-lang.github.io/rust-project-goals/2025h2/relink...

stymaar3• 14 days ago

My point is that rustc is still noticeably faster than tsc yet people complain about the former and nor about the later.

NetOpWibby• 14 days ago

The speed-up improvements are incredible, can't wait for this to rollout to Deno. Everything I build uses TypeScript so I'm excited to see just how quick my apps compile.

MoonWalk• 14 days ago

I was wondering how this kind of change makes its way into environments like Deno. I'm building a project on Deno too.

As I understand it, Deno provides the "language server" for editors like VS Code. So how does Deno use this... whatever it is from Microsoft? What exactly did they deliver here?

skybrian4• 14 days ago

Deno resolves import statements in its own way. For example, you can import URLs and JSR packages directly, but the file is usually loaded from Deno’s global module cache. To resolve imports you need to look at the deno.json file and deno.lock file. They also added Deno Workspaces (monorepos) which adds more complexity.

This means you need to plug an import resolver to the TypeScript compiler. Deno uses the TypeScript compiler API, but all the import resolution code is in Rust. I’ve done a partial reimplementation in TypeScript using a coding agent, but there’s quite a lot to it.

I don’t think Deno will be able to upgrade until the TypeScript compiler API is ready.

skybrian4• 14 days ago

No TypeScript compiler API yet, but I'm encouraged to hear that they're working on it.

simlevesque• 14 days ago

It's coming in 7.1

miiiiiike• 14 days ago

After a few years of using Typescript, having to use type annotations and import basic language features like `abc` in Python feels like an absolute slog.

Exoristos2• 14 days ago

Seeing these graphs of astounding performance gains with less memory requirements makes one wonder, Why am I using server-side TypeScript and not Go?

semiquaver• 14 days ago

For one, you’re not using TypeScript server-side. Whatever execution engine you are using is executing transpiled or JavaScript.

And yeah, I don’t know who in their right mind is starting projects in TS/JS/python these days except when they don’t have an option.

IshKebab3• 14 days ago

I don’t know who in their right mind is starting projects in TS/JS/python these days except when they don’t have an option.

I agree, although I would say that for web projects, writing the backend in TS is still a really great option because it means you can use TSX, which has a much better UX than any alternatives. For example https://usefresh.dev/ is much nicer to use than any non-TS options I've found, including Go and Rust where you basically end up using text-based templates along the lines of Jinja.

dbbk• 14 days ago

"In their right mind?" I wouldn't start a project in anything other than TypeScript now. My platform is a monorepo across web and native mobile (Expo), and is TypeScript throughout. All my types flow everywhere automatically. Even the shape of a database table is shared with the native app with tRPC. Nothing can break the type contract anywhere. How would you do that with another language?

atraac• 13 days ago

Absolutely everyone who doesn't work with hardware, or on specific problems, because it's far more popular, easy to hire for, easy to deliver an MVP with and easy to have people jump between frontend and backend with. I'm saying this as someone who specialized in .NET before and now writes Node/TS. I simply grew out of the opinion that language/architecture is everything. When you make a product delivering quicker matters more than choosing a marginally more performant language, unless you're solving a very specific problem that requires that performance. Adding one more server costs less than hiring engineer for a more niche language and if you have the success that requires you to scale up that much, money is probably not the problem anymore. Granted we're in LLM era where everyone can write anything but it's still better to have people vibe in language they actually know, so they understand what's happening. You can always extract services later on and rewrite them in a more performant way, noone's stopping you.

Scarbutt• 14 days ago

Because it’s easier to work with one main language if you can get away with it.

throw310822• 14 days ago

Because you can share types and even modules with your frontend project? Because for applications that aren't CPU-intensive it makes almost no difference? Because you are familiar with it and like it? Because of the humongous amount of libraries?

recursive3• 14 days ago

This is build-time performance, not run-time.

jenadine• 14 days ago

It is the run-time performance of the compiler depending on its implementation language. So totally relevant.

thunderfork• 14 days ago

Whether the performance difference between Go and JS (via node or whatever) matters depends on your use case - it definitely matters for the TS compiler, but it might not matter at all for your CRUD app.

madeofpalk2• 14 days ago

I like TypeScript. It catches bugs in programs that Go doesn’t.

Exoristos2• 13 days ago

Isn't Go strongly, statically typed?

austinthetaco5• 14 days ago

I'm still not sold on typescript. I've used it off and on professionally for years and it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape. Doing purely functional with it is or at least was an absolute chore and so much extra typing happens for extremely obvious variable values that you could derive from the name of the variable. YES you technically can do functional programming (but as i said its a pain) and YES its optional and you dont have to use it everywhere, but try pulling that maneuver on a technical team "lets use typescript where we each feel like it".

I am still of the opinion that well organized and named JS is all that anyone needs and typescript only exists for fresh graduates and fleeing OOP devs.

edit: also the downvote button HN is not for disagreeing with comments or unpopular opinions.

jakubmazanec3• 14 days ago

I am still of the opinion that well organized and named JS is all that anyone needs

You probably didn't work on any medium or large codebase and didn't have to do a refactor.

it has always just felt like a maneuver to create a safehaven to C# and java devs scrambling to find roles in the modern landscape

What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.

austinthetaco5• 14 days ago

You really should just not assume things about people with no reason other than "they dont like the things i like so therefor they must not be experienced". I've worked on plenty of very very large codebases with large teams.

What a nonsense. Perhaps read history of TypeScript and you'll learn why it was created.

did you? it was created by microsoft, a C# shop, to support their existing workflows around typing and hinting support. The typescript creation team was literally led by the guy who made C#.

drschwabe• 14 days ago

Same here, and if you really need its key features just add JSDoc and Zod to any given vanilla JS codebase.

Passing around mixed types is not necessarily an anti-pattern either ie- you can do type-checking at runtime and use them as conditions for branching into different control flow patterns - so I don't see the benefit of universal enforcement; not that most TS codebases do anyway (ironically).

I personally don't have a need for TS which introduces an extra build step, extra ritual when defining functions, and no performance benefit over vanilla JS. If I want stricter coding pattern with performance benefits I will use C/C++ for the job instead.

ameliaquining5• 14 days ago

Basically every JavaScript server runtime and build tool supports TypeScript out of the box these days, so the only situation where it adds an extra build step is if you were previously serving your JavaScript source files directly to browsers. Which is okay at small scale, but if you have a substantial-size app with a real userbase, you're wasting a lot of your users' bandwidth if you do this.

TypeScript and Zod serve complementary, mostly non-overlapping purposes; the former detects bugs in your code, while the latter validates data that comes from outside your program and so can't be trusted. There likewise aren't that many use cases where you can choose between C/C++ and JavaScript/TypeScript based on personal preference; usually only one of the two is suitable.

perrohunter• 14 days ago

For the average developer, does this mean we can simply ugprade to typescriptn 7 and start enjoying the improvements?

lelandfe• 14 days ago

If you’re continuing to use the previous version in CI, there’s no reason to not use this locally. It’s a tremendous speed upgrade.

herpdyderp3• 14 days ago

The reason to not use it locally is false negatives or false positives compared to your CI version. Your local tsc will not match the results of your CI tsc.

sheept• 14 days ago

It depends, but for larger projects, you might have tooling for TypeScript that relies on its API, which isn't available in TS 7.0.

herpdyderp3• 14 days ago

Depends on your tooling. I can't update yet due to ESLint package dependency mismatches. I'll have to wait for all the ESLint plugins to update. There may also be new failures in your code from the v6 to v7 update. I had only a very minor one though in my initial test.

dmix• 14 days ago

Eslint is like an anchor on upgrading anything (including Eslint itself). I'll be happy to move on from it.

fishgoesblub• 14 days ago

Are these performance improvements just for transpiling the Typescript to JS, or actually running programs written in Typescript?

tpetry• 14 days ago

These are for type-checking. Transpiling takes barely any time.

culi2• 14 days ago

TypeScript isn't a runtime language

m3h• 14 days ago

The speed up numbers based on their testing:

    Codebase    | TypeScript 6 | TypeScript 7 | Speedup
    ------------|--------------|--------------|--------
    vscode      | 125.7s       | 10.6s        | 11.9x
    sentry      | 139.8s       | 15.7s        | 8.9x
    bluesky     | 24.3s        | 2.8s         | 8.7x
    playwright  | 12.8s        | 1.47s        | 8.7x
    tldraw      | 11.2s        | 1.46s        | 7.7x

Congratulations to the team for pulling off this feat while doing a responsible migration (looking at you, Bun).

Quick question: How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase? Can I use TS 7 and current tsdown together?

hackerbrother• 14 days ago

Do you think Bun's migration was irresponsible?

ricardobeat• 14 days ago

Not the op, but this TS migration started long before AI was able to help. It was done slowly and carefully, as a project supporting millions of users should. And the benefits are very clear.

Bun’s port was a vibe coding fever dream that happened from one day to the next, with much looser motive, and yet to be proven reliable.

bastawhiz4• 14 days ago

It's unknowable, because the PR is unreviewable. The Bun migration PR is larger than any model ever made can fit into context. You just have to pray that test coverage is sufficient to catch all of the possible errors, which it almost certainly isn't.

mindwok• 14 days ago

I don't think irresponsible is the right word, but it has drastically reduced Bun's appeal. All the tools we use have a brand to them, and Bun basically changed their brand overnight to "reckless" in my eyes.

replygirl• 14 days ago

it's impossible to say, as v1.4 is in development and there has been no migration

phplovesong• 14 days ago

Its was basically "hey claude, rewrite this"

sdevonoes• 13 days ago

I would say it was a joke. Cannot take it seriously

DanRosenwasser• 14 days ago

How does this affect downstream tools like tsdown and esbuild, which need to build the TypeScript codebase?

esbuild doesn't rely on TypeScript at all, so there's no issue there.

With tsdown on the other hand, it depends on if you use --isolatedDeclarations. If not, you can install TypeScript 6 side-by-side (instructions for this are on the blog)

paulddraper• 14 days ago

"How does this affect downstream tools"

It’s worth calling out that workflows that use Vue, MDX, Astro, Svelte, and others will likely not yet be able to leverage TypeScript 7. Similarly, specialized type-checking within templates like Angular will also likely not use TypeScript 7. This is mainly because TypeScript 7 does not yet expose a stable programmatic API, and so tools (such as Volar) which embed TypeScript into their own compilers and language services can only currently rely on TypeScript 6.0. We expect this to be a point-in-time issue, as we are committed to providing a solution here. We will be actively working with the maintainers of these projects to ensure TypeScript 7 supports these workflows.

pjmlp5• 14 days ago

The Typescript team is also using AI, even if not to the crazy Bun level.

_pdp_• 14 days ago

I've been waiting for this for a long long time. Congrats on the release.

pmkary• 14 days ago

Glorious Day!

m_ke2• 14 days ago

After running out of Fable credits in a day on my max plan I started looking around for ways to trim down my token usage and came to the realization that all of the type spaghetti that opus wrote is probably eating up like 50-70% of my tokens.

A clean django project is probably 3-4x less code than the equivalent TS based service.

It made me consider dropping strict mode and defaulting to js for most simple things.

jw1224• 14 days ago

Interesting, I've come to the opposite conclusion: a lack of types (or types that are only weakly enforced) costs me significantly more tokens in the long-run to maintain, and makes it far too easy for models to silently introduce bugs.

I run all my projects now in TypeScript with the strictest possible settings, including disabling `ts-ignore` markers.

(This would drive me absolutely insane, but my agents get over it pretty quickly!)

IceDane• 14 days ago

Why not just do like.. actual engineering, and stay in control of what the LLM builds?

kodama-lens• 14 days ago

In a world where code generation is cheap, why use untyped languages? Types add confidence, stricter interfaces, and most likely a better runtime performance.

m_ke2• 14 days ago

With agentic coding the costs of tokens compound with each message / tool call and etc. Having to load in and update large files makes things slower and way more expensive.

Databricks actually just posted some of their own benchmarks on how harness alone impacts costs https://www.databricks.com/blog/benchmarking-coding-agents-d...

simple things like passing more file context, model having to explore the code base at start of each session, writing comments or markdown docs ends up increasing, running into test / build issues can 3-10x your costs.

PS: my code is still mostly TS and rust but I'm considering moving some of my annotations into .d.ts files and having them generated from runtime types (ala MonkeyType).

herpdyderp3• 14 days ago

I'm only seeing a speedup of 4x compared to v6, but I'll take it!

brikym• 14 days ago

3 - 3.5x here. I'm very happy with that though.

ksec2• 14 days ago

I know this is about Typescript. But I am wondering if anything happening in Go that will make this even faster?

kristianp2• 14 days ago

Just about every release of go has incremental performance improvements [1]. It's a very stable language, so don't expect anything mind-blowing. For example the latest 1.26 moved a new garbage collector from experimental to production [2]. In the latest compiler they state that: "The compiler can now allocate the backing store for slices on the stack in more situations, which improves performance".

[1] https://go.dev/doc/devel/release

[2] https://go.dev/doc/go1.26

ksec2• 14 days ago

Thanks I have somehow missed this. My mental model is that Go is still 1.5 to 2.5x speed of C hence I asked the question. This is likely wrong number now given so much has been happening without much fanfare. ( or may be I just missed all of it )

Thanks for the link.

dzonga• 14 days ago

congrats to the typescript team.

I have a longer blog post or audio to post. but in short - the javascript/typescript ecosystem is like working with wood.

you can have your cheap, laminate cardboard wood - Ikea type - the code equivalent will be vibe coded apps that are not original.

then on the high end - you can have your crafted furniture | wooden skyscrapers - that use custom joinery & lamination techniques using young lumber to make to make beams that are fireproof. you can also have high end stuff in the javascript/typescript ecosystem that uses A.I as one uses powerful machine tools but with crafting in mind.

for those that dare to make or dare to do - embrace the typescript|javascript ecosystem.

some-guy• 14 days ago

I remember going from Java in IntelliJ straight to TypeScript at work for another project, and I recall how _slow_ everything was in the editor(s). I have been using TypeScript 7 RC and most of my complaints have gone away with regards to speed.

mckee_plus_plus2• 14 days ago

Major ts pain point is scoping tsconfig settings for lib and types configurable for subsets of a project.

My project is a webapp, but I have node types in my ide tooling because of vite.config.ts, and playwright and unit tests. If I add a node api to a react component, tsc won't complain.

Current method to isolate dom lib from node lib requires project reference spaghetti, numerous tsconfig.json and tsbuildinfo output files, and avoiding emitting types with project references is cumbersome.

paustint• 14 days ago

Agree it is a pain. I have been using nx and it handles all that for you, playwright is a separate project with it's own twconfig and they all inherit from a root tsconfig.

I prefer nx for single applications and move shared code to "libraries" (I use non-buildable libs). It's pretty sweet for larger projects.

silverwind• 14 days ago

Yes, tsconfig is a mess to scope. It needs a re-design to allow glob-based matching for all options and in typescript instead of jsonc.

settled• 14 days ago

Great links but unfortunately it doesn't work with ts-jest out of the box, had to do the side-by-side compatibility workaround. Major releases should give more confidence for common tools like testing instead of pointing backwards

Timon34• 14 days ago

I don't think it's reasonable to expect the TS team to hold back the release until the ecosystem has caught up.

austin-cheney• 14 days ago

Fascinating, but since Node now natively strips the TypeScript type annotations I rarely run the TSC. I really only run it now when I make a major regressive change and need static output from the compiler to see things I have failed to update.

Even for front end code destined for the browser I rely on Node's type stripping.

MiTypeScript2• 14 days ago

fair, but, at the same time.. you may not think too much about it, but your editor is running the TypeScript language server all day long. presumably, so does your CI. presumably, so does your AI agent before feeling good about what it just did.

linzhangrun• 14 days ago

Congratulations! Although I'd prefer the C# authors to rewrite it in C# AOT :)

anankaie• 14 days ago

Or implement tsaot

knocte2• 14 days ago

Yeah! This way TS at runtime would also benefit from the speedup, not just the compilation.

jeswin2• 14 days ago

Congrats on launch. The code is beautiful, and the test suite is quite solid.

Over the past year, I've been working on porting the v7 tsgo compiler back into TypeScript - https://github.com/tsoniclang/tsts

It's fully functional now, but 2x slower than the original tsc and 10x slower than tsgo. But hopefully in a month or so, we'll get to C# and Rust targets and it should be able to compile itself to become nearly as fast as tsgo.

lioeters• 14 days ago

That tsts project looks very interesting. I suppose there are various practical reasons for doing this. For me I'm just glad to see an easy way to run the newest TypeScript compiler (and I guess type checker?) in the browser. There's an unofficial Wasm build of tsgo/ts7, if I recall was about 12Mb. Another advantage of tsts I imagine is the ease of diving into the compiler internals as it's running (interpreted) instead of a binary distribution, another language (though I like Go), or having to recompile it on every change. Good luck with the project, I'll be keeping an eye on its progress with interest.

jeswin2• 14 days ago

Thanks. The idea is that many projects (including tsts itself) can be run unmodified on a JS runtime, or as a native binary via NativeAOT/C# or Rust.

shafiq235• 14 days ago

Its the best thing ever. I have been waiting months for this Thanks to Microsoft for the first - NON SLOP release

ShinyLeftPad3• 14 days ago

Does lack of compiler API mean typescript-language-server is not going to play nice with 7.0?

kristianp2• 14 days ago

https://news.ycombinator.com/item?id=48840113 seems to answer that question. I.e. an api for the compiler is being worked on.

ShinyLeftPad3• 14 days ago

Sure but typescript-language-server is different because it's also from MS.

sharlos2010682• 14 days ago

I remember reading they're rebuilding it to use the same LSP as other languages instead of its custom thing.

ShinyLeftPad3• 13 days ago

it's not? pretty sure I use typescript-language-server as generic LSP from my editor for years

amai• 14 days ago

So the compiler written in Go is nearly 10x faster than the old one written in JavaScript

jekuer• 14 days ago

TS gained so much more relevance with AI. Hope they do not mess it up!

ramon156• 14 days ago

Awesome! Off-topic, can we get something like TS for PHP now? Tools like PHPStan work fine, but I'd love a typed language on top of PHP that can catch a lot of things on compile time. I want to be able to compile my symfony routes, avoiding as much as possible on runtime.

I've been thinking about this since 2022 and haven't really gotten further than "Hmm, I would like this".

I'm aware that tooling catches most stuff, but being able to shift this even more to the left (compile time) would be great.

I'm just very used to Rust, where my hand is being held

Cthulhu_7• 14 days ago

Have you considered Hack (https://hacklang.org/)? it's PHP with types from Facebook, probably the biggest contributor to the PHP ecosystem at the moment.

It does need a compiler though, unlike TS where an interpreter can just strip / ignore type annotations. But IMO, a compile step is worth it if you get type assurances in return.

plasticeagle• 14 days ago

I love Typescript, I think it's a fascinating language with a great runtime. It's already very fast to execute, but the compile times have been awful. Especially when you start to run production builds with minification and whatnot.

So I'm interested on what exactly has been sped up here. I can see compile times have been, but is that it? I suppose the runtime itself was always native code, and already very fast.

inbx0• 14 days ago

What do you mean by runtime? The JavaScript runtimes, like V8? Yeah those are impressively fast for a dynamically typed ”scripting” language, but that has little to do with TS. TypeScript’s work ends at compilation.

skybrian4• 13 days ago

The TypeScript compiler is (was) slow, but you don’t need it to minify code. This sounds like some other problem with the tools in your project’s build. (There are faster tools available these days.)

A faster type checker will help with performance problems in text editors since type info is needed for a lot of queries.

wartywhoa23• 14 days ago

Well, vscodium users are left in the cold, because the official extension isn't and most likely won't be on open-vsx repository, and the unofficial fork¹ is still WIP.

¹https://github.com/Nsttt/typescript-go

lelele• 14 days ago

Joel On Software: Rewriting software is the single worst strategic mistake that any software company can make. [1]

Microsoft: Take that, Joel!

;)

---

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

sharlos2010682• 14 days ago

To be fair, this wasn't just rewriting the software, it was translating logic in JS largely one-to-one into Go.

aabbcc1241• 7 days ago

I've not figure out how to run typescript script directly with type-checking (in dev mode) with typescript 7.

ts-node cannot be used with typescript@7.

although node@24 can directly run typescript file, but stripe the types, without type-checking, also it require changing the import path with .ts, and it doesn't support import .tsx files.

TypeScript 7

Related Stories