Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Progress on TypeScript 7 – December 2025

devblogs.microsoft.com

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Progress on TypeScript 7 – December 2025

#21

Post by oskarkk »

paxys wrote: post #7
vivzkestrel wrote: post #2

stupid question: why doesnt google chrome support native typescript execution on their chromium engine?

"Native typescript execution" can mean two different things: 1. Chrome/v8 takes TS code, compiles it down to JS internally, erases types, and then runs it like normal. This isn't going to be too hard to do, but also isn't going to be very meaningful. Compiling is a one-step process in any case, and plenty of tooling exists to make it seamless. 2. Chrome/v8 actually understands TS types at runtime, and throws exceptio…

I think there's also option 3, v8 understands types and uses them for optimization, but handles wrong types gracefully.

I don't think any type of understanding TS would require changing ECMAScript spec. Would a TypeScript-understanding parser not be able to handle normal ECMAScript correctly? It could switch between two modes based on the file type.

For option 1 the speed of TS development is not an issue, as Chrome would only need to include some up-to-date compiler, and the TS files could specify their TS version. But doing TS compilation in the browser would only be a small nice thing for devs, for website users it would be a downgrade, as the page load would be slower because of the compiling and the larger file sizes (JS files can already be very big these days).

Re: Progress on TypeScript 7 – December 2025

#22

Post by ZiiS »

klysm wrote: post #9
ZiiS wrote: post #6

Earlier quoted context omitted.

Different projects use different versions of typescript with different configurations, and almost no one wants the client to throw type errors where the untyped code would have actually worked. I.e. the are drawbacks but no advantages. This is ongoing standardisation work to allow it to _ignore_ typescript and just run the JavaScript which will be nice but not a huge win.

> no one wants the client to throw type errors where the untyped code would have actually worked That’s not how TypeScript works. You execute it after erasing the types.

Exactly so all the Browser should do is erase the types. Doing that after you have spent extra time downloading and parsing them is not a useful enough feature to lumber the language with having to get all Browser's to ship each new change.

Re: Progress on TypeScript 7 – December 2025

#23

Post by sidpatil »

beart wrote: post #8

I'm excited for this, but I'm not looking forward to yet another round of refactoring for all of the linters, formatters, bundlers, etc. I still haven't fully migrated every project I maintain to eslint 9.

I'm unfamiliar with all the changes coming soon. What would you need to refactor?

Re: Progress on TypeScript 7 – December 2025

#24

Post by eternityforest »

paxys wrote: post #7
vivzkestrel wrote: post #2

stupid question: why doesnt google chrome support native typescript execution on their chromium engine?

"Native typescript execution" can mean two different things: 1. Chrome/v8 takes TS code, compiles it down to JS internally, erases types, and then runs it like normal. This isn't going to be too hard to do, but also isn't going to be very meaningful. Compiling is a one-step process in any case, and plenty of tooling exists to make it seamless. 2. Chrome/v8 actually understands TS types at runtime, and throws exceptio…

1. Would still be meaningful, since it would pretty much mean we could completely ignore untyped JS code aside from legacy support, the same way we can currently pretend untyped python doesn't exist

Re: Progress on TypeScript 7 – December 2025

#26

Post by bastawhiz »

oskarkk wrote: post #21
paxys wrote: post #7

Earlier quoted context omitted.

"Native typescript execution" can mean two different things: 1. Chrome/v8 takes TS code, compiles it down to JS internally, erases types, and then runs it like normal. This isn't going to be too hard to do, but also isn't going to be very meaningful. Compiling is a one-step process in any case, and plenty of tooling exists to make it seamless. 2. Chrome/v8 actually understands TS types at runtime, and throws exceptio…

I think there's also option 3, v8 understands types and uses them for optimization, but handles wrong types gracefully. I don't think any type of understanding TS would require changing ECMAScript spec. Would a TypeScript-understanding parser not be able to handle normal ECMAScript correctly? It could switch between two modes based on the file type. For option 1 the speed of TS development is not an issue, as Chrome…

It's unclear whether you could build a JIT that meaningfully benefits from typescript types.

1. Hidden classes can't be created from TS interfaces because they don't represent the full data of the underlying object

2. You don't really ever want to compile code the first time you see it, because that takes a lot of memory and extra CPU cycles. By the time code has run enough to be worth compiling, you probably have enough profile data to optimize better than you could with data from the types anyway.

3. Many of the juiciest optimizations come from types that aren't representable in TS, like integers.

4. Including all the types for all your code and deps (literally all the .d.ts) is huge, and the size increase alone might nullify any performance benefit.

Re: Progress on TypeScript 7 – December 2025

#27

Post by conartist6 »

WorldMaker wrote: post #20
conartist6 wrote: post #18

Earlier quoted context omitted.

That proposal is a practical joke. You haven't got a language at all if the words don't mean anything .

It is an approach that has already seen some success in Python. Languages often have constructs that are reserved for future use or that "parse but don't validate". JS has a lot of reserved keywords (thanks to ES4 and ES5, especially) that "don't mean anything" today but could in the future and still parse even though they'll give a runtime error. Beyond that, almost every language has a syntax for comments . Comment…

If you allow arbitrary meaningless data in today, you can never add meaning in the future. That's why the reserved words cannot be used. They need to be safe to add meaning to down the line!

Re: Progress on TypeScript 7 – December 2025

#28

Post by mdhb »

jerrygoyal wrote: post #25

Typescript is my favourite language. Glad it's being continuously developed.

I genuinely don’t understand this sentiment at all. Typescript looks great when you put it next to JavaScript in most cases. And looks like shit when you put it next to any other modern language that emerged from a similar time frame (Kotlin, Dart, Swift etc..)

I really don’t see TypeScript destined for long term success with the rise of Wasm on the web. It is only where it is currently because it has operated at a huge advantage of being the only viable solution to a problem that every web developer has needed.

I say this as someone who writes a lot of typescript professionally and a lot of Dart for everything else I possibly can. The difference between the two is huge on almost every factor I can think of where Dart wins by a considerable margin. I’m thankful that Typescript existed at a time when it did but I don’t think it’s in anyway actually a good or sensible language (because it’s so closely to JavaScript) and I can’t wait to not have to use it in the future because better options exist and are becoming viable for more use cases.

Re: Progress on TypeScript 7 – December 2025

#29

Post by mdhb »

oskarkk wrote: post #21
paxys wrote: post #7

Earlier quoted context omitted.

"Native typescript execution" can mean two different things: 1. Chrome/v8 takes TS code, compiles it down to JS internally, erases types, and then runs it like normal. This isn't going to be too hard to do, but also isn't going to be very meaningful. Compiling is a one-step process in any case, and plenty of tooling exists to make it seamless. 2. Chrome/v8 actually understands TS types at runtime, and throws exceptio…

I think there's also option 3, v8 understands types and uses them for optimization, but handles wrong types gracefully. I don't think any type of understanding TS would require changing ECMAScript spec. Would a TypeScript-understanding parser not be able to handle normal ECMAScript correctly? It could switch between two modes based on the file type. For option 1 the speed of TS development is not an issue, as Chrome…

If you want proper run time type safety you’re going to need a language designed for that which Typescript never was. I write a bunch of Dart which I compile to Wasm and get proper run time type safety in the browser and it works great.

Re: Progress on TypeScript 7 – December 2025

#30

Post by beart »

sidpatil wrote: post #23
beart wrote: post #8

I'm excited for this, but I'm not looking forward to yet another round of refactoring for all of the linters, formatters, bundlers, etc. I still haven't fully migrated every project I maintain to eslint 9.

I'm unfamiliar with all the changes coming soon. What would you need to refactor?

I don't know, hopefully not much! Just reading the article about IDEs using one version of typescript and builds using another, along with some incompatibilities. It raises concerns there will be some hiccups with various dev tools.
Post reply on HN