DEV Community

I've been writing TypeScript without understanding it

vincanger on June 11, 2024

I admit, I don’t really understand TypeScript The other day, I was stuck with a bug in some code that was handling optimistic updates, s...

Read full post

Rense Bakker • Jun 11

It's worth noting that transpilation and compilation are not exactly the same thing. Transpilation is a style of compilation that translates code from one language into another. In typescript that's theoretically really simple because it is a superset of JavaScript. Presumably if you remove all type information from the typescript file, it could be run like a normal JavaScript file. This is not exactly the case, but you get the difference with a language like C that gets compiled into machine code. Transpilation is typically really fast, while compilation can take a little longer. There are actually several runtimes now (bun/deno) that can run typescript code directly, without any transpilation.

vincanger • Jun 11

Oh nice. Thanks for the info. I wasn’t aware that bun and deno could do that!

eshimischi • Jun 14

Small correction about bun/deno. Both indeed execute TS without transpilation when do it directly, BUT if you launch your app in the browser they will use esbuild to transpile code into JS.

JoelBonetR 🥇 • Jun 16

That's because Deno and Bun are Runtime Environments for Javascript/Typescript.
If you want to run your app in Browser (which contains a different Runtime Environment) you need to give it what it supports (JS in this case).

I don't know what's the sense on using Deno or Bun if your target is the browser in the first place but here's the explanation.

eshimischi • Jun 20

To be clear, from Bun's documentation: "Bun natively supports TypeScript out of the box. All files are transpiled on the fly by Bun's fast native transpiler before being executed. Similar to other build tools, Bun does not perform typechecking; it simply removes type annotations from the file."

JoelBonetR 🥇 • Jun 20

Oh well, that's more lazy even, thank you for letting me know! <3

Andrea Giammarchi • Jun 12 • Edited

the article is nice but the satisfies looks like a non-sense to me ... in JS:

const a = { name: 'Bob', age: 12 };
const b = a;
b === a;
Object.is(b, a);

A constant that points at another constant is the other constant itself. If b is exactly a it makes no sense that b satisfies Person but a does not satisfy Person, they are the exact same reference to the exact same pointer in memory.

I think this was a genuine mistake form TS itself and I get people trying hard to explain the difference but if JS is what matters at the end: there is no difference.

Specially with composition, I find extremely hard to also justify this:

// what does this do?
const a = {
  ...foreign,
  otherThing: 123
} satisfies Person;

// why is this fine?
const b = a satisfies Person;

It looks like a limbo between casting where satisfies act like an enabler at distance but can't validate the "satisfaction" of the literal source of an object.

Once again, it's not about your post, rather about the fact you are giving for granted that satisfies behavior makes sense only because the master of TS or TS itself told you so ... I think they could've done a better job with a single keyword that is ambiguous for no reasons and it honestly makes zero sense at the JS level.

Jen Lewis • Jul 10

I agree, honestly the more I learn about TS the less it seems necessary. Just kind of seems like it's forcing Javascript to do something it wasn't designed to do.

Andrea Giammarchi • Jul 10 • Edited

that's where I'd draw a line between being a superset VS a shenanigans based logic ... luckily enough, I still don't need TS in my projects as they are all core JS enablers, no need for this mental muscles unnecessary overhead 🤷‍♂️

Michael Mior • Jun 12

Now, Let’s see how TypeScript inferred the types of the person properties:

TypeScript isn't really inferring anything here. You told TypeScript that the type of the properties should be either a string or a number :)

vincanger • Jun 12

Yes, you're right. What I should have said is that typescript did not infer the narrower type I defined. :)

Daniel Nwokocha • Jun 11

Informative.
I also like your honest style of writing.

vincanger • Jun 11

Thanks, Daniel.

Karan Sethi • Jun 12

Thanks for sharing this! Admire your style of writing mate.

Stevenr • Jul 3

TLDR- I’ve been writing every language without understanding it. 😂😂😂

Misael Braga de Bitencourt • Jun 12

Typescript is a linter

JoelBonetR 🥇 • Jun 16

Just in the sense of static code analysis but the similarities end there. Sadly though 😅 If that were the case we wouldn't require ESLint and additional sh*tload of dependencies which would be nice

Robert Schaffrath • Jun 11

With the Bun runtime, you can run TypeScript as is. No transpiling needed. Also runs CommonJS and ESmodules without special file name extensions.

eshimischi • Jun 14

Transpilation by bun or deno is happing when you launch your app in the browser.. because non of modern browsers know something about TS yet (i know that community is working on it)

Joel Jose • Jun 13

This is really good. I enjoyed the reading.

vincanger • Jun 13

thanks!

Arun kumar • Jun 14

Superb article

Antonio | CEO at Litlyx.com • Jun 12

Great content! It brings real insight on real life!

Thank you!
Keep the great work up!

Antonio, CEO & Founder at Litlyx

Syed Muhammad Ali Raza • Jun 12

Good one with real life example

Mikhael Esa • Jun 12

This is a great one! Will definitely try the satisfies keyword. Thank you!

Alex • Jun 13

Nice post, thanks!

Devpugg • Jun 12

Couple of things:

Transpilation is a made up new term, it's just compilation.
Compiling means parsing source code, building an AST and then generating some other source code. Usually, that's lower level code like Assembly, which can be used to produce machine code, but that's an implementation detail.
Some folks thought compiling higher level langs into other high level langs warranted a new term. Personally, I think it's just confusing, but whatever. Just wanted to point out there's nothing special about it.

The distinction between scripting and compiled langs is also a bit misleading. That X user, @yacineMTB, and this article seem to conflate scripting with interpreted, but that's not quite the same thing. It's even more confusing that he then asks for a binary, which is the result of compilation. So he's essentially asking about running a compiled language without compiling it and yet, somehow, magically, still have a binary. Makes no sense.
If you want to run a script, you typically use an interpreter, and you can do that for TS too, via Deno and Bun.

Which brings me to VMs. They don't generate machine code per se, in fact, the whole point is to avoid it. Again, that's a compiler's job. VMs instead take an AST and evaluate it, thereby skipping the code generation step.

Finally, type systems! TS's excess property checking is a semantic rule and not necessarily related to the Structural nature of the type system. It's more about subtyping, which granted, is more frequent in structural systems. A structural type system can still throw a type error in subtyping situations if the definition of type equality demands it.
For example, you could rule {foo: string} != { foo: string, bar: integer }. TS developers decided against it, and while that's a somewhat controversial decision, I personally think it was a good one given the nature of most JS codebases.
If you're interested, other languages, name Purescript and Elm, are far stricter on this and avoid subtyping, instead opting for something like row polymorphism or extensible records. That has its downsides too, though.

Michael Mior • Jun 12

Transpilation isn't really a "new term." Transpilers have been around since at least the mid-90s.

Ayush Thakur • Jun 11

Quite an informative article

vincanger • Jun 11

Thanks, glad you like it :)

Mirzalazuardi Hermawan • Jun 12

Thanks for sharing your knowledge

Dimitar • Jun 16

On a first look this is just a runtime type error waiting to happen...

What's the point of declaring a string | number when you know what the type is? The whole point is to show you the potential type error, and with satisfies you've not fixed the real issue, but hidden it.

If your variable can be more than one type and the function/property you're calling doesn't exist on all types then you will have to do type checks at runtime to avoid a runtime error anyways.

Alex Peirson • Jun 17

Thanks for a great article! Like you I've been increasingly using TS but have realised that I don't truly understand it. This scenario where an object can have multiple keys of different types is something I run into all the time so am really grateful to learn about the satisfies keyword - thanks!

Dmytro Shchehlov • Jun 18

It seems the author is more interested in promoting their product than discussing TypeScript. It's just clickbait, nothing more ... unfortunatelly.

By the way, JavaScript has become a compiled language since the introduction of Just-In-Time (JIT) compilation in modern JavaScript engines like V8, which was introduced in 2008.

cabulous.medium.com/how-v8-javascr...

Matija Sosic • Jun 11

Nice stuff! I think "transcompilation" is often referred to as "transpilation" - any difference between the two?

Michael Mior • Jun 12

They're the same thing although transpilation is the much more commonly used term.

z2lai • Jul 10 • Edited

Great topic! I never knew about this feature which seems to be an alternative to explicitly casting with "as".

However, everything starting from "Why is that? (when you were explaining the bug with intermediate variables) makes no sense. You mention it's a Javascript thing then you immediately introduce a TypeScript concept.

Excess property checking is actually the exception to the rule. TypeScript uses what’s called a “Structural Type System”. This is just a fancy way to say that if a value has all the expected properties, it will be used.

This paragraph was confusing, are we talking about excess property checking or structural type system and how is it an exception to what rule?

And lastly, your solution to the "bug" with satisfies is avoiding it altogether and going back to direct type annotation. But this brings us back to the original problem, so I'm actually unsure of what you're trying to say at the end.

My feedback is less about your technical knowledge but more about improving your thought process or paragraph structuring. I think it would help if you added a concluding sentence per paragraph that summarizes the point youre trying to make by tying the why and how back to the what, before jumping to the next paragraph. And on the same note, the entire article jumps all over the place from introducing the satisfies keyword, then to what is TypeScript, then to promoting your SaaS (please move this to the end), then back to the actual topic of the article.

Anyway, thank you for sharing and keep on writing and improving!