jakebailey

6 gün öncediscuss

The compiler was written in TS; it wouldn't make much sense to compile TS to Wasm, only to have that same code run in the same interpreter as the JS code.

And yes, threading was a big part of it. See also: https://devblogs.microsoft.com/typescript/typescript-native-...

jakebailey

6 gün öncediscuss

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

jakebailey

geçen yıldiscuss

The automatic generation was mainly a step to help with manual porting, since it requires so much vetting and updating for differences in data layout; effectively all of the checker code Anders ported himself!

jakebailey

geçen yıldiscuss

This is specifically about the performance of the TypeScript toolchain (compiler, editor experience); the runtime code generated is the same. TypeScript is just JS with types.

jakebailey

2 yıl öncediscuss

> Until trademark laws come into play, and you find yourself obligated by law to give up your domain username to a big corporation.

This wouldn't be a big deal in practice (besides losing the domain). Domain usernames are just the combo of you telling Bluesky "I intend to use this domain name" and then you placing a TXT record on the domain to prove you own it. If you want to change domains (or, are forced to), you just give them the new domain name and you set another TXT record (just like if you had set up a domain name as a username for the first time). The underlying DID is still yours.

jakebailey

3 yıl öncediscuss

> One of my major gripes with the JS/TS ecosystem is that "explanations" are sorely lacking. See https://www.typescriptlang.org/tsconfig for the relevant documentation for tsconfig files. Tutorials are on the page, how-to guides abound on the wider internet (like the OP), and the linked TSConfig Reference and JSON Schema (used in code completion in IDEs) are together absolutely massive.

> But an explanation is missing! There is no official documentation about how different options interact to say: as I'm walking a file tree as the Typescript compiler, this is how I will interpret a certain file I encounter, what will be outputted, and how that will be interpreted by bundlers and browsers, especially in an ESM world.

Perhaps you missed it, but Andrew (from the TS team) recently finished a massive overhaul of our module docs: https://www.typescriptlang.org/docs/handbook/modules/introdu...

The "theory" page describes TypeScript's perspective on modules. The "reference" page documents things from the "as I'm walking a file tree" perspective (among many other details). The "guides" page also provides recommendations for certain kinds of projects.

comments