Comments

simlevesque 9d
Wow I think I know a lot of Typescript but I'll have to go through it because I'm always asked for ressources to get started and this one seem great.

I also recommend type-challenges: https://github.com/type-challenges/type-challenges

It works great with the VSCode extension.

YoannMoinet 9d
I particularly love the interactivity of the training. So polished.

Can't get enough of the fireworks!

nonethewiser 9d
This is a really nice website.
bwestergard 9d
This is fantastic! I've often had to advise coworkers to read documentation for OCaml or Rust to learn idiomatic, functional, statically typed programming. It's great to see a Typescript specific resource with exercises.
mikessoft_gmail 9d
greate, will check tomorrow wrote good software in Latoken, 2019
d4mi3n 9d
I'm always impressed at how much the type system in TS is capable of. The provided examples remind me of what I'd expect in something like Rust; it brings me joy that we can do this sort of stuff in our frontend code and tooling these days.

We have come far.

Myrmornis 9d
This looks fantastic, not just for people learning Typescript, but I'd think it would be useful (when completed) as an introduction to generics and type-level thinking etc for lots of newcomers to those areas.
guggleet 9d
Seems like a good start, but there are a lot of interesting offerings in the introduction that really don't exist in the content so far.

Maybe finishing one of the more advanced chapters would be enough to lure people who are more experienced to check back on progress / pay / whatever you want traffic for.

agentultra 9d
Nice course, and nice site.

Although, as a Haskell developer, I am curious what type system TS is using (System F? Intuitionist? etc) and what limitations one can expect. Aside from the syntax of TS being what it is, what are the trade-offs and limitations?

I was under the impression, and this was years ago -- things are probably different now?, that TS's type system wasn't sound (in the mathematical logic sense).

amadeuspagel 9d
Looks cool. I like how it gives immidiate feedback, but doesn't feel constraining or arbitrary. Is there are more basic tutorial in a similar style?
cercatrova 9d
Speaking of types, what are your thoughts on fp-ts if you've used it? It brings functional programming concepts like in Haskell such as monads into TypeScript.
Rapzid 9d
I wish this issue would get addressed: https://github.com/microsoft/vscode/issues/94679

Showing fully resolved types in Intellisense would be the single largest usability enhancement they could make for me right now..

kaladin_1 9d
Just came here to say that this is really nice. Fantastic way to play with Typescript Types even for people with decent knowledge of Typescript as I would consider myself.

Particularly enjoy the confetti :)

cogman10 9d
A great idea. Now, everyone that learns this stuff, show some restraint!

The drawback of a powerful type system is you can very easily get yourself into a type complexity mudhole. Nothing worse than trying to call a method where a simple `Foo` object would do but instead you've defined 60 character definition of `Foo` capabilities in the type system in the method signature.

Less is more.

HellsMaddy 9d
This is great. Can you please create an email list where we can sign up to be notified when new chapters are available? If I follow you on Twitter, I will invariably miss any announcements.
classified 9d
Is TypeScript's type system Turing-complete?
tunesmith 9d
Might as well ask here. On our teams, we have the occasional developer that is insistent on using Typescript in an OO fashion. This has always struck me as square peg round hole. Even though I come from an OO background, Typescript strict settings really seem to push me in a direction of using interfaces and types for type signatures, and almost never classes, subclasses, instantiated objects. I don't have a very good answer for "yeah, but what about dependency injection"? though. Any thoughts from anyone?
323 9d
One think I struggled a lot with until I got it is that the TypeScript types and the JavaScript code live in totally separate universes, and you cannot cross from the type world to JavaScript values because the types are erased when transpilling - meaning they can't leave any trace.

This means that it's impossible to write this function:

    function isStringType<T>(): boolean { return ... }

    const IS_STRING: boolean = isStringType<string>();
At best you can do something like this, which is inconvenient for more complex cases:

    function isStringType<T, IsString extends boolean = T extends string ? true : false>(isString: IsString): boolean { return isString }

    const IS_STRING_1: boolean = isStringType<string>(true); // compiles
    const IS_STRING_2: boolean = isStringType<string>(false); // type error
You basically need to pass the actual result that you want in and just get a type error if you pass in the wrong one. Still better than nothing.

Link if you want to play with it online: https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABDA...

Put another way, you can't do reflection with TypeScript.

You can write that function in C++ templates, and I naively assumed that it's possible in TypeScript too, since from my observations TypeScript allows complex typing to be expressed easier in general than C++.

kbr- 9d
Is there any place I could report issues or ask questions about the course other than Twitter?

If the author is reading this, the proposed solution to the `merge` challenge is:

  function merge<A, B>(a: A, b: B): A & B {
    return { ...a, ...b };
  }
That's the "obvious" solution, but it means that the following type-checks:

  const a: number = 1;
  const b: number = 2;
  const c: number = merge(a, b);
That's not good. It shouldn't type check because the following:

  const d: number = { ...a, ...b };
does not type check.

And I don't know how to express the correct solution (i.e. where we actually assert that A and B are object types).

Also, looking forward to further chapters.

somewhereoutth 9d
> Over the years, the type system of TypeScript has grown from basic type annotations to a large and complex programming language.

Give someone (particularly a developer) the opportunity to build something complicated and undoubtedly they will. So now you have two problems, the complicated program that actually does some hopefully useful work, and another complicated program on top of it that fills your head and slows you down when trying to fix the first complicated program. You may say 'ah yes, but the second complicated program validates the first!'. Not really, it just makes things more complicated. Almost all bugs are logic bugs or inconsistent state bugs (thanks OOP!), almost none are type bugs.

However, static analysis of existing code (in Javascript), without having to write a single extra character, may well have great value in indicating correctness.

Edit:

> TypeScript's type system is a full-fledged programming language in itself!

Run! Run as fast as you can! Note that this 'full-fledged programming language' doesn't actually do anything (to their credit they admit this later on)

Edit2:

> [...] is a type-level unit test. It won't type-check until you find the correct solution.

> I sometimes use @ts-expect-error comments when I want to check that an invalid input is rejected by the type-checker. @ts-expect-error only type-checks if the next line does not!

What new level of hell are we exploring now??

aussiesnack 9d
Looks good. Given the course is unfinished, it's a shame the only way to get updates is via a third party corporate web site ("Twitter"). RSS would be the obvious way to go.
robertwt7 9d
Really interesting articles, will definitely have a look at night.

After so many years of JS programming, moving to a company that uses TS extensively (in a huge scale) feels life changing. You don't even know the effect until you use it daily. Even so, daily usage of typescript at a large web application doesn't seem to be using its full potential. I feel like libraries creator and maintainer use them more in the definitions that they created (i.e redux toolkit type is mind blowing).

Thanks for creating this lesson, it will definitely teach me a lot

Benjamin_Dobell 9d
One of the worst things about Next.js, Remix etc. is their file system driven routes. I really wish these frameworks would stop relying so much on hidden magic. Conventions are good, but as to why those conventions aren't in code is quite peculiar.

Previously, I wrote my route definitions with types for both path params and query params, in one file and used TypeScript to enforce that the equivalent back-end definitions (async loaders etc.) and front-end definitions (React components) were kept in sync.

When I first implemented this in the previous project, I found many instances where routes were expecting query params but they were being dropped off (e.g. post login redirects).

Supporting things like parameters for nested routes certainly means the TS types themselves non-trivial, but they're the kind of thing you write (and document) once, but benefit from daily.

Examples of stuff that can and should be 100% type checked:

  // ...
  template: {
    path: idPath("/template"),
    subroutes: {
      edit: { path: () => "/edit" },
      remix: { path: () => "/remix" },
    },
  },
  onboarding: {
    path: () => "/onboarding",
    query: (params: { referralCode?: string }) => params,
    subroutes: {
      createYourAvatar: { path: () => "/createyouravatar" },
    },
  },
  // ...
Routing:

  // Path params
  navigate(routes.template.edit({ id: props.masterEdit.masterEditId }));
  // No path params, just query params (null path params)
  navigate(routes.onboarding(null, { referralCode }))
  // Nested route with query params (inherited from parent route)
  navigate(routes.onboarding.createYourAvatar(null, { referralCode }))

React hooks:

  // Path params
  const { id } = useRouteParams(routes.template.edit)
  // Query params
  const { referralCode } = useRouteQueryParams(routes.onboarding);
API routes:

  // ...
  play: {
    path: () => "/play",
    subroutes: {
      episode: {
        path: idPath("/episode"),
      },
    },
  },
  // ...
Express relative routes (for defining nested express routers):

   const routes = relativeApiRoutes.api.account;
   router.post(routes.episode(), async (req: express.Request, res: express.Response) => {
nsxwolf 9d
I currently have to occasionally contribute to a TypeScript codebase at work. I appreciate how much better it is than Javascript. When I write code as an outsider (Java and Go developer), I feel like I use the type system in sensible and readable ways. When I look at the code written by the native TypeScript experts in my company it is a bewildering, abstract, unreadable morass. I have no idea what's going on half the time.
SeriousM 9d
Types are here to help but with this power comes great responsibility. The deeper you allow an input to be used in your library/method the more it makes sense to put a well defined type contract on it. Exhaustive type definitions may show that the author doesn't have a understanding of a required interface, abstractions or pattern to use. I use c# professionally for 20 years and I love the type system. It helps to tell the contract about the types and functions you expect yet you can overcomplicate things if you really about to. c# makes it "hard" to create method type definitions and you should use interfaces to achieve the contract definition. This helps to avoid the inline type definition as it's done in typescript. My approach is to use types in typescript as I'm used to in c#.