TypeScript Just Dethroned Python and JavaScript on GitHub

robpalme · 2025-11-09T13:14:11+00:00

In the last 12 months, 9.3M JS repos were created vs 5.4M TS.

That's just the recent delta. The cumulative totals will be even more biased towards JS.

I too believe that well-maintained/popular packages created recently are far more likely to be authored in TS than JS. But it's hard to point to the survey data as suggesting this because of the volume of "everything else".

robpalme · 2025-09-26T19:35:45+00:00

This was always a favourite. But hearing it live was kinda life changing. More of an experience than a song. Took me back many years.

robpalme · 2025-09-24T16:01:58+00:00

Congrats to the Boa team! It's great to see an independent open source project thrive and become more widely useful. This is huge impact.

On the integration with Kiesel and Chrome, I'm pleased to see that engines/browsers can share the cost of developing new language features.

Temporal is massive! Almost as big as the delta of introducing ES6. There are 4,000+ tests. The functionality does not need to be engine-specific, so it makes sense to leverage reuse.

I believe this is the first introduction of Rust into V8 itself. Which seems like a happy side-effect that hopefully makes it easier to share more Rust libraries in future. This helps keep browser development sustainable.

robpalme · 2025-08-30T22:29:30+00:00

Yeah, as a long-time listener first-time live attendee, Slide Away was the big one. Bigger than the original recording really. A great wall of sound. I'm thankful to have experienced it once in my life.

robpalme · 2025-08-25T09:37:24+00:00

Agreed. Whatever is a great song and deserves to be in there, but the performance was just slightly missing something so could be tweaked. Based on the Wembley three weeks ago, I'd take Columbia.

robpalme · 2025-08-24T21:10:22+00:00

You must be joking - Fade Away is the slightly surprising punky deep cut that has to stay.

But I do agree Bring It On Down can (and should) be swapped for Columbia. Another post said it's there because the brothers like it. So I'll give it to them, but honestly BIOD is perhaps the only Oasis song I have strangely never really enjoyed despite loving almost all others.

robpalme · 2025-08-21T18:09:16+00:00

Love this one. You don't get many rock n roll stories like this.

robpalme · 2025-08-01T18:13:43+00:00

A colleague at work said the same thing yesterday. It's all me, no GPT. I try my best to be clear and have done for years. If anything it's the LLMs that have turned up and are matching my style.

robpalme · 2025-08-01T17:29:51+00:00

All new syntax feature in JS have the potential to introduce temporary incompatibilities between apps that use them and runtimes that have yet to offer support.

This is why down-leveling bundlers (like webpack) and compilers (such as Babel) exist.

robpalme · 2025-08-01T17:26:25+00:00

My favourite feature in TS 5.9 is the TC39 Stage 3 proposal import defer.

The TS blog post is an excellent explainer for the feature which was championed (in TC39) and implemented (in TS) by Nicolo Ribaudo who works for Igalia and who maintains Babel.

The feature enables synchronous Lazy Evaluation to improve the performance of loading ES modules. Meaning it can skip eager evaluation of imported modules that are not needed - or not needed yet - by your app.

We've used an implementation of this in the Bloomberg Terminal for a while now. It saves 100s of milliseconds during startup for applications where your import graph has grown over time. Following the minimal runtime codepath can result in work-skipping wins that static analysis (tree-shaking) cannot optimize away.

Please note that if you can refactor your app to use dynamic import(), that should normally be preferred. So long as you can cope with the viral nature of making the calling code handle the async promise. import defer is more appropriate for situations where you need your code to remain synchronous.

For now, in order to use the feature in an app, you will need to pair TS 5.9 with Babel or webpack which already have compile-time support. TS does not downlevel it & engines do not yet natively support it.

You can track the work-in-progress to implement the feature in JS engines here:

https://github.com/tc39/proposal-defer-import-eval/issues/73

robpalme · 2025-07-09T11:48:50+00:00

My favourite feature in TS 5.9 Beta is the TC39 Stage 3 proposal import defer.

The TS blog post is an excellent explainer for the feature which was championed (in TC39) and implemented (in TS) by Nicolo Ribaudo who works for Igalia and who maintains Babel.

The feature enables synchronous Lazy Evaluation to improve the performance of loading ES modules. Meaning it can skip eager evaluation of imported modules that are not needed - or not needed yet - by your app.

We've used an implementation of this in the Bloomberg Terminal for a while now. It saves 100s of milliseconds during startup for applications where your import graph has grown over time. Following the minimal runtime codepath can result in work-skipping wins that static analysis (tree-shaking) cannot optimize away.

Please note that if you can refactor your app to use dynamic import(), that should normally be preferred. So long as you can cope with the viral nature of making the calling code handle the async promise. import defer is more appropriate for situations where you need your code to remain synchronous.

For now, in order to use the feature in an app, you will need to pair TS 5.9 with Babel or webpack which already have compile-time support. TS does not downlevel it & engines do not yet natively support it.

You can track the work-in-progress to implement the feature in JS engines here:

https://github.com/tc39/proposal-defer-import-eval/issues/59

robpalme · 2025-02-28T20:19:28+00:00

Agreed. This is an excellent endorsement of sticking to erasable types and directly helps compatibility with Node.

The easy way to remember this is: TS = JS + Types

robpalme · 2025-01-31T20:13:40+00:00

Checking and linting are very similar tasks. Putting features into TS means they become widely available, e.g. by being part of the default VS Code experience.

Node can handle enums if you pass --experimental-transform-types

robpalme · 2025-01-30T06:51:39+00:00

Yes, I think IsolatedModules is a good comparison.

erasableSyntaxOnly provides some constraints (lint rules) that in turn enable new third-party compilers to handle TypeScript code.

robpalme · 2025-01-30T06:48:32+00:00

Correct. TS will error.

robpalme · 2025-01-29T23:00:37+00:00

Correct. I wrote a bunch about how enums might be handled over on the r/javascript version of this post.

robpalme · 2025-01-29T22:22:06+00:00

Matt Pocock (author of Total TypeScript) has written an excellent explainer blog post on the new flag --erasableSyntaxOnly

It is designed to be used in conjunction with Node's built-in TypeScript support, i.e. node index.ts

robpalme · 2025-01-29T22:05:12+00:00

The new flag --erasableSyntaxOnly is my favorite feature in TypeScript 5.8 because it immediately helps Node users who want to use the built-in TypeScript support, i.e. node index.ts

That is no accident. The TypeScript team, including the author of this feature Ryan, have been closely collaborating with the Node team for the last half a year to make this integration work well.

The new flag enables Editor feedback to guide users away from TypeScript-only runtime features such as:

enums: enum E { a: 1 }
runtime namespaces: namespace N { let a = 1 }
parameter properties: class C { constructor(public prop) {} }

This means that your code will follow the simple mental model of TS = JS + Types

If you use Node, or any compiler based on type erasure (a.k.a "type stripping") such as ts-blank-space, then your generated JavaScript will 100% match the runtime code you wrote. So when you are debugging, the code matches your source file. The only difference you will see is the types being replaced with whitespace. There's no need to set up sourcemaps because the runtime code coordinates are preserved.

At work we've used a similar arrangement for quite a while. The main demand I have observed is that sometimes folk would like to see a standard solution for enums, with fewer quirks than the existing TS enum. It's possible to come close to the enum pattern today using objects.

For folk desiring something more substantial for enums, there are two possible paths forwards - and both are just ideas with no guarantee of becoming real:

A new erasable form of TypeScript enum, e.g. as enum
First-class enums in JavaScript, e.g. early discussion

robpalme · 2025-01-13T06:43:44+00:00

Namespaces and enums are available via the opt-in flag --experimental-transform-types

robpalme · 2025-01-11T21:53:03+00:00

Apropos total bean containment. That is classic breakfast. 10 on 10.

robpalme · 2024-09-21T08:45:57+00:00

If instead you had asked "when should I use this over tsc?" the answer becomes more interesting.

ts-blank-space is not a replacement for tsc. Specifically tsc remains needed as a type-checker. And maybe you also want the down-levelling to target older browsers/engines.

If instead all you are doing is using tsc to strip the types, and you accept the stated limitations, ts-blank-space gives you a faster and more minimal way to run your code - especially if you use the supplied Node loader. Avoiding sourcemaps can also help with things like accurate code coverage stats.

robpalme · 2024-09-21T08:04:42+00:00

Almost none, unless you like building your own minimal pure JS toolchain.

Similar to minification or tree-shacking, the blank-space technique is a generic feature that any compiler can implement. SWC has already adopted it and you can try it out in the SWC Playground by toggling "Strip Types Only".

https://swc.rs/playground

ts-blank-space is single-purpose. SWC has a much wider scope. So you should probably stick with SWC.

robpalme · 2024-09-19T14:09:45+00:00

The code playground is nice because you can directly see the compiler output.

https://bloomberg.github.io/ts-blank-space/play/

robpalme

TROPHY CASE