[HN Gopher] Progress on TypeScript 7 - December 2025
___________________________________________________________________
Progress on TypeScript 7 - December 2025
Author : DanRosenwasser
Score : 71 points
Date : 2025-12-02 17:37 UTC (5 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| vivzkestrel wrote:
| stupid question: why doesnt google chrome support native
| typescript execution on their chromium engine?
| Analemma_ wrote:
| I'm not enough of an expert in PL theory and compilers to say
| for sure, but I suspect that because Typescript's syntax and
| semantics are all designed with total type erasure in mind,
| there's no advantage you could get to executing it natively
| versus compiling to JavaScript and taking advantage of all the
| optimizations JS engines already have.
| benbayard wrote:
| It's not a stupid question, but here is the TC39 proposal to
| add type declarations to JS: https://github.com/tc39/proposal-
| type-annotations
| ZiiS wrote:
| 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.
| klysm wrote:
| > 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.
| antihero wrote:
| Unless you use enums, of course.
| jauco wrote:
| Or constructor property initializers.
| constructor(public foo: string){}
|
| Is a typescript feature.
| ZiiS wrote:
| 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.
| paxys wrote:
| "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 exceptions for mismatches. This isn't going to be
| possible without a major rewrite of the v8 engine and the
| ECMAScript spec itself.
|
| And a big challenge for both of these is that TypeScript is
| iterating at too fast a pace for something like Chrome to keep
| up. It's best to just leave versioning and compilation for the
| developer to manage and give end users a consistent JavaScript
| experience.
| oskarkk wrote:
| 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).
| halapro wrote:
| Because TypeScript is a (legacy) mess.
|
| There's effort towards "erasable syntax" but in practice not
| many really want to run anything more than basic TS in the
| browser, simply because you lose things like 'import _ from
| "lodash", which requires further setup (import maps) or is
| impractical in larger projects.
|
| The real reason however is that TS is just _a_ language, not
| part of any standard, and browsers are not just going to
| support random languages headed by corporations (Microsoft) and
| that are not community projects.
| nikeee wrote:
| The "types as comments" proposal has a stated goal to not
| codify any semantics to the annotations.
|
| This is not only due to implementation complexity, but also
| to keep TS to be able to change. Or even to build an entire
| different JS superset. With that proposal, even flow could be
| natively executed.
| conartist6 wrote:
| That proposal is a practical joke. You haven't got a
| language at all if the words _don 't mean anything_.
| WorldMaker wrote:
| 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_. Comments don 't
| mean anything to the parser/compiler either, but they
| mean a lot to the people writing the source files and
| they still need syntax to write them.
| WorldMaker wrote:
| > you lose things like 'import _ from "lodash", which
| requires further setup (import maps) or is impractical in
| larger projects.
|
| I think importmaps are reasonably practical even for larger
| projects today. I know Firefox supporting multiple importmaps
| in the same HTML is still a wishlist item for some to avoid
| more scenarios that need an importmap compile step in very
| large projects, but importmaps are relatively easy to
| automate (it's just JSON wrapped in a script tag; merging
| them can be just a matter of a couple Object.assign calls or
| object spread notation; the multiple importmaps standard that
| Firefox is behind on _is_ just that, a basic Object.assign
| merge).
|
| > The real reason however is that TS is just a language, not
| part of any standard
|
| Right, which is why the TC-39 (committee that owns JS)
| proposal for "erasable syntax" for "type annotations" isn't
| Typescript-specific and isn't a pure superset of Typescript
| syntax. The node implementation of erasable syntax doesn't
| use the Typescript compiler and doesn't support the full
| Typescript syntax and is relatively close to the TC-39
| proposal.
|
| > not just going to support random languages headed by
| corporations (Microsoft) and that are not community projects.
|
| Nitpicking somewhat, but Typescript has been open source
| since it was publicly launched and a fair enough chunk over
| the years of contributors aren't/haven't been Microsoft
| employees. It's fairly reasonable to say it is a community
| project. I appreciate the point that it is still seen as a
| specific-vendor solution and the point of separating the JS
| language standard proposal from being "just do what Microsoft
| decides is right for Typescript" (as TC-39 is trying to do),
| but to be fair to Typescript, it is a also bit wilder and
| more open than that "just a Microsoft solution" at this point
| (and arguably also for most of its history).
| xiaomai wrote:
| is anyone using the preview releases in neovim yet?
| homebrewer wrote:
| Does IDEA count? It's the same server underneath. I've been
| using it since support for it became available, maybe four
| months ago, and it's been pretty OK. Much faster, but there are
| some occasional crashes at least with incremental type checking
| enabled. The speed difference more than makes up for it.
| beart wrote:
| 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.
| conartist6 wrote:
| Migrated to what? Rust, or Go? Or Rust and Go?
| hamasho wrote:
| I confused those features of the native language server, so
| here's the summary: - Go-to-Definition: For
| variables, jump to the declaration. For functions/classes/types,
| jump to its types or implementation. - Go-to-Type-
| Definition: For variables, jump to its type declaration instead
| of the variable declaration. - Go-to-Implementation: For
| interfaces/abstruct classes, jump to (multiple) implementations
| of the method. For compiled TypeScript file (like them under
| node_modules), jump to its implementation rather than .d.ts
| files.
| zeroc8 wrote:
| Love it. What a fantastic show case for Go.
___________________________________________________________________
(page generated 2025-12-02 23:01 UTC)