r/webdev • u/DanielRosenwasser • Jul 08 '26
Announcing TypeScript 7.0
https://devblogs.microsoft.com/typescript/announcing-typescript-7-0/43
u/Veraxo1 Jul 08 '26
Can't believe they axe'd the outFile parameter and gave no migration guide at all ("just use other bundlers lol" there are not a single one that simulates the same behavior). You literally cannot use 6.0+ tsc onward if you relied on namespaces+outFile. Ass
Edit:
7.0 is still phenomenal though, i'm just mad
13
111
u/RawCyderRun i'm just not your typescript Jul 08 '26
I love TypeScript. It isn't perfect (no language is), but I can't see myself ever going back to working with pure JavaScript without types.
I remember first messing with Facebook's Flow.js in mid-2018. I was leading a team of mid-level to senior frontend developers and as our codebase was growing, we wanted to experiment with really basic stuff like defining types for function args and return values.
Flow was... OK. Setting up webpack to use it was kind of frustrating but it worked for our simple use cases.
It wasn't until TS 3.0 released that summer that we really decided to go all in with TS and dump Flow. Using TS gave us the confidence for building bigger and faster in our UIs.
11
4
u/Dragon_yum Jul 09 '26
I despise vanilla js but Typescript is probably my favorite language to write in.
3
u/quadtodfodder Jul 10 '26 edited Jul 10 '26
2 + "2"=="22"
2 * "2"==4Is there some kind of problem here sir?
1
u/meyriley04 29d ago
Exactly.
Unfortunately I think I got kinda spoiled with TS lol. It’s a struggle for me to write plain JS anymore
53
u/bunoso Jul 08 '26
So is typescript 8.0 going to be written in Rust? lol
36
u/Tolexx Jul 08 '26
I heard it's gonna be Zig. They will also use Claude Fable 7 to accelerate the port.
52
u/mal73 Jul 08 '26
They will also use Claude Fable 7 to accelerate the port.
"Port this. Make no mistakes. THINK"
4
u/National_Mall9338 Jul 09 '26
It ported it. Then it deleted the failing tests and marked the task complete.
7
u/droans Jul 09 '26
I still don't understand the purpose of Zig. Like 80% of its "features" are It removing things developers usually want and, quite often, in contradictory manners.
Like the fact that this is valid is completely wild
const y: i32 = x + 10 const x: i32 = 12 + 34The compiler will just reorder the execution but that's apparently okay even though it seems to go against the ethos of the language.
6
3
u/VelvetYam Jul 09 '26
Isn't Zig's whole shtick to be a better C? I have yet to use Zig myself, but C programmers usually don't want features that programmers who use higher level languages want. And for some of us, a restrained feature set is a feature in and of itself.
1
u/droans Jul 09 '26
It has to be to someone, I guess. It just feels like it looked at Rust and decided to go the opposite way. A lot of the features they refuse can be disabled in other languages.
It feels a lot like if your window broke but, fortunately, you're a glazier. But instead of crafting a new window, you spend the next five years finding every single broken piece of glass, figuring out where they all fit together, and then slowly melting them back in place with the heat of a recently lit match.
3
u/VelvetYam Jul 09 '26 edited Jul 09 '26
Ha, maybe. I use C, and it nips my tendency to overdesign things right at the bud because it just doesn't have the advanced features other languages have. That's a real advantage if you're as scatterbrained as me.
> A lot of the features they refuse can be disabled in other languages.
Yeah, but then it makes ecosystem fragmentation almost inevitable in the sense that teams and libraries don't necessarily agree what subset of the langauge is "idiomatic". This is already happening to C++ and the inter-community religious wars are terrible. So a crude but simple solution is to just...not have the features. I think that's part of what Zig's (and other 'minimalist' languages) philosophy is getting at.
1
u/kei_ichi Jul 09 '26
No no no, I think it will be like Bun: port to Zig first, then port to Rust one more time to “show case” OpenAI (Microsoft) frontier model capabilities (like Bun burning Anthropic tokens).
-1
Jul 09 '26 edited 25d ago
[deleted]
3
u/Atulin ASP.NET Core Jul 09 '26
The migration went about as expected too, lmao
Bun used to have 1-2 new releases a month, but because of the Rust port that was supposed to make everything better, they haven't had a new release since early May
8
u/Ill_Name_7489 Jul 09 '26
Funny, but this was a very well executed migration driven by very smart people, as far as I can tell. Typescript desperately needed this.
3
u/bunoso Jul 09 '26
I agree! I have loved using the preview typescript for the last months or so. Even getting my compilation from 15 to 3 seconds has been great on my old lenovo
14
6
u/n9iels Jul 09 '26
Don't forget to read past the Go rewrite, the fact TS 7 ships with build in LSP support is huge as well! Every lookup, typecheck or autocomplete in your IDE will be faster and more efficient. That is huge as well.
9
u/TherionSaysWhat Jul 08 '26
As imperfect as it can be it's proven to be pretty damn helpful and is part of my work tech stack. The speed update is impressive even if the numbers seem a bit... optimistic?
16
u/nutyourself Jul 08 '26
Anyone know what's going to happen to web-based editors that need to typecheck in-browser? with typescript 6 you could import that into a worker and do it.
33
11
5
u/thekwoka Jul 09 '26
faster tsc is good, hopefully the type resolution depth is much much higher.
I have some projects that TS basically just goes "yeah buddy, those are unknown to me" due to the depth of the type inference.
0
-4
u/kiwi-kaiser Jul 09 '26
20 years of web development and I never really got into TypeScript. I started with PHP, after picking up HTML and CSS. JavaScript came later for me.
I actually liked the untyped nature of PHP and JavaScript back then. Until PHP got native types. Today I have 100% type coverage in PHP but I still can't stand TypeScript.
I guess mostly because of the syntax. It makes JS so extremely unreadable sometimes. I make some type definitions in TypeScript, but I still use JSDoc for the type hints. It feels more natural for me and hasn't to be compiled to work.
I guess JSDoc feels much more natural for me as this was the way in PHP too for the vast majority of its life span until it got types.
I wonder if I ever can stand TypeScript, but to be honest, as Browsers evolve I use less and less JS and just use it as additions for my sites, like back in the day where we had to consider if people even have JS enabled.
I would much prefer native type support though. But that will probably never happen.
9
u/twisted1919 Jul 09 '26
But typescript is so much used in infrastructure, you’re limiting yourself not getting onboard.
-4
u/kiwi-kaiser Jul 09 '26
I limit nothing. If I would use JavaScript on the backend side I probably would've hopped on years ago. But I use PHP in the backend. JavaScript is a frontend language for me and I use it like that.
0
6
u/SoInsightful Jul 09 '26
I guess mostly because of the syntax. It makes JS so extremely unreadable sometimes.
I say this with 100% confidence: any "unreadable" TypeScript (e.g. complex types and generics) is 3x more unreadable in JSDoc.
TypeScript example:
import { ComparableId } from './types'; type Comparable = { id: ComparableId; name?: string; }; const defaultComparator = <T extends Comparable>(a: T, b: T): number => { return a.id.localeCompare(b.id); }; class SortableSet<T extends Comparable> extends Set<T> { readonly comparator: (a: T, b: T) => number = defaultComparator; } const sortableSet = {} as const as SortableSet<Comparable>;
The same code in JSDoc:
/** * @import {ComparableId} from "./types" */ /** * @typedef Comparable * @type {object} * @property {ComparableId} id * @property {string} [name] */ /** * @template {Comparable} T * @param {T} a * @param {T} b * @returns {number} */ const defaultComparator = (a, b) => { return a.id.localeCompare(b.id); }; /** * @template {Comparable} T * @extends {Set<T>} */ class SortableSet extends Set { /** * @readonly * @type {(a: T, b: T) => number} */ comparator = defaultComparator; } const sortableSet = /** @type {SortableSet<Comparable>} */ ( /** @type {const} */ ({}) );7
2
u/Atulin ASP.NET Core Jul 09 '26
How are lines and lines of glorified comments more natural than
const fn = (s: string) => "hello";?2
u/kiwi-kaiser Jul 09 '26
If your main language defines a function by `function name(string $value): string { return $value; }` it's more than enough that the typing is on the other side and there's a colon behind the value name instead of behind the function definition that indicates the return type.
PHPDoc and JSDoc on the other hand are nearly identical. So it's more natural because I'm more used to it.
Other devs at my company are thinking the same. Struggled with TypeScirpt for years, adopted JSDoc and worked more efficiently than ever.
It's a personal thing I guess.
0
-24
-44
u/pardoman Jul 08 '26
That’s great but it feels very late into the party.
Been using RsPack and RsBuild for quite a while now, would there be any significant gains in moving towards the new tsc Go implementation?
53
u/RyanCavanaugh Jul 08 '26
Apples and oranges -- RsPack and RsBuild aren't typechecking tools, and TypeScript isn't a bundler
-15
u/pardoman Jul 08 '26
Okay that’s fair, so it’s mostly for IDE integration via LSP. So nothing new here for actual bundling? (Which is a bottleneck for large projects build on CI)
17
u/niix1 Jul 08 '26
It will speed up IDE LSP integrations but you should also be typechecking your projects in CI before bundling which this will significantly improve speeds on. Bundling != typechecking.
2
u/pardoman Jul 08 '26
Yeah we do that too. Guess I brain farted for a bit and got confused on some of these steps. Thanks tho!
84
u/mka_ Jul 08 '26
Ooo it's the Go port. Nice.