Talking TypeScript with the engineer who leads the team

The most interesting takeaway for me, was their opinion on Deno.

> Q: Most of the time, TypeScript is transpiled into JavaScript. With deno, It’s a first class language. What do you think about efforts like that? And do you think browsers will ever do TypeScript first?

> A: Deno is super cool. I love that someone’s built this tech and is seeing what would happen with it. I think the browser case is really interesting because it seems like it makes sense. Then, every time I walk five steps ahead in my head, it all breaks down for me.

> So for me, it’s like, OK, you’re going to serve TypeScript to the client. And then the clients can interpret the TypeScript. Well, if you’re if you don’t want type checking on that file that you sent down, then there’s really no point. Stripping off the type annotations is a very mechanical process and there’s not a lot of value there. You can send down source maps or whatever, but that’s more of a diagnostic debugger experience. So we get into this mode where we’re sending this down as TypeScript so it can be type checked by the client.

> My first question is, why is this the client’s job? Because you push this TypeScript code up to the server, and I hope that it type checks at the point that you did that. If it didn’t, it’d be weird to consider why you would have done that. And again, development scenarios are just totally a different beast here. I’d like to see more investment in the development space for questions like, would it make more sense to have that?

> But anyway, let’s say we keep going and type checking on the client. Well, you can’t really start this type checking process until you’ve pulled all your dependencies in. And then you’re gonna end up sending down .d.ts files that don’t really do anything. And how did the .d.ts file get on your server?

> I’m not going to say it’s never going to happen, but I think there’s a lot more room for technologies like what you see with `create-react-app`, where there’s a live web server for development purposes, checking the types in the background as it serves up the transpiled JavaScript on the fly. Like, that’s a fantastic model that renders all of my objections totally moot because the type checking is happening at a more logical time. Maybe there’s some space for a browser plug in. But that model’s a little confusing, too, because ultimately your `<scripts>` tag is going to pull in a .js file unless suddenly all browsers everywhere support TypeScript. That’s what you’ll have to do.

> It becomes a question of if you’re debugging or loading, say, production HTML that references the .js files. Where in the process do we actually get the .ts file instead? Never say never. But to me it’s kind of a not soon situation. Deno is completely its own thing because there it’s a new runtime. So that scenario makes a lot more sense to me, at least to be type checking during the first time you run a script and making sure that you’ve got some compatible environments.