Hasty Treat - TypeScript Compilers and Build Tools

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS, web development treats coming in hot. Here is Wes, Barracuda, Boss, and Scott, El Toro Loco, Tolinski.

CSM. Welcome to Syntax. In this Monday, hasty treat. We're gonna be talking about TypeScript, Talking a little bit about the differences between using compilers and build tools and whether or not you still need to use Webpack or Babel with your TypeScript Along with some of the interesting newer options, my name is Scott Talinsky. I am a full stack developer from Denver, Colorado. And with me as always is Wes Bos.

Hey. I'm excited for the show because these are the questions I had when I got into TypeScript. I'm like, do you still need Babble, webpack, Parcels, Notepad. Like, do you still need these things or not? Or, like, where does TypeScript compiler fit into it? So we're gonna attempt to answer that today. Her whole platform is built on this stuff Right?

So I got lots lots of thoughts here. Yeah. I thought, like, you're this is all fresh in your mind, so I thought it's a good time to do it. Fresh as can be. And both of our sponsors today are also fresh as can be. I'm talking about Sanity at Sanity dot I o and Sentry. Now Sentry is the error and exception handling tool that is one of our favorites over here at Syntax and Piece of software that I've been using for a very long time myself. In fact, when we launched our new level of tutorials platform built on many of these things that we're gonna be talking about in this episode, well, We wouldn't have even dreamed of doing it without Suntory.

So if you want to get the best error and exception handling tracking service on the market In your app performance tracking and release tracking and GitHub issue integrating all sorts of stuff and more, head on over to century.io.

Sign up. Use the coupon code tasty treat, all lowercase, all one word. You'll get 2 months for free. We're also sponsored by Sanity. Sanity dot I o is the Structured content CMS. It's an awesome CMS. Users love actually using it. And I'm gonna highlight one feature of it today, which is their They have an entire image pipeline, so it will do all of your resizing and compression and all that on the fly, and they just rolled out Support for Next Image. So if you're using Next. Js and their new image component, they rolled out support for that. So what that means is that You can do all of your compression and resizing, and it actually happens on Sanity's servers. And it also happens on demand, which is really, really nice So you don't have any, like, really long build times to wait for when you're building your website. So I'm excited to see that. They just keep rolling out all the Awesome stuff. So check it out, sanity.ioforward/ syntax.

I mean, that's gonna get you double the free usage tier when you build your next site. Thanks so much to Sanity for sponsoring.

Super. So let's get into it here. Let's talk about TypeScript.

And I have our platform is built on TypeScript. I know, Wes, you've been working in Type quite a bit. And one of the things that definitely mystified me when we first started learning TypeScript or converting over, because my my platform used to be in Meteor. Okay? Why don't we get TypeScript in Meteor? This was at the time, and people say, oh, you could just use it from Babbel. And then other people would say, well, that doesn't give you all of the same benefits, blah blah blah. And then once we did get it in Meteor, I kinda started to get the understand the difference between the TypeScript compiler in Babel. So do you add add, like, the very

Brief overview. Do you wanna say, like, what the TypeScript compiler is and what it does? Yeah. So the TypeScript compiler, the two main things is that it It analyzes your code and does what is called type checking. So when you write your code, it will ensure that all of the types That you're right. All the functions that you write with passing in arguments, all the values that are returned from your functions, all your variables that are created, all your Arrays that are filtered, they all resolve to what types it's expecting. So if it's expecting you to Return an array of dogs, and that dogs has a property of likes bones, which is a Boolean of true.

And for some reason, That dog returns a property that it's never heard of, like is a good boy or returns a string of true Or or or anything. It'll say, hey. This is not returning the right value, and that is what is referred to as type checking. And the TypeScript compiler will not let you go past that If you are running through a type checker before you go in into compile. And then you go into the compile in TypeScript, which is it takes it from TypeScript And turns it into JavaScript and allows you to actually run that in the browser. And there's a couple different options as to How it will output your JavaScript, it can output it in ES modules.

It can output it in common JS modules. It can also do some transpiling.

We'll talk about what that is in just a sec. But at the end of the day, it just takes your TypeScript and kicks it out to either common JS, ES modules are just regular JavaScript without any modules at all. Word. Yeah. I think that's a a great explanation.

And that's really the the big benefit other is that you can use TypeScript's compiler to not only, you know, give you that the end result code that the browser can read, but You can use TypeScript's compiler to maybe prevent shipping of code that has bugs in it. You can have this no emit Feature where basically the code won't even compile if the types are broken or even with the TypeScript compiler, it can still compile if the TypeScript is broken. It's all up to you, but it gives you that control whether if you were just writing this in normal JavaScript, do you ship some code that maybe has some Difference in types, JavaScript doesn't care. Nobody's gonna care until your users end up seeing, like, a not a number error or or some, you know, String concatenation when you meant to do an addition of numbers, those types of bugs that end up hitting the user in the user interface because They're just so hard to catch if you're not being careful on build time, on develop time, or anything. You just those just go unnoticed.

So let's talk a little bit about the other ways of getting TypeScript files to be JavaScript files because The TypeScript compiler is sort of the thing to do type checking, but there's a whole host of other tools that are easier to bring into your current setup Such as Babble. If you're already using Babble, there is a Babble TypeScript plug in. And you know what this plug in is going to do? It's gonna take your TS files And make them JavaScript files. But you know what it's not gonna do? Any sort of type checking. It's not gonna do any of that. It's basically just going to strip all of the TypeScript stuff out, pretend that it doesn't exist, give you JavaScript, which means that, hey, you can write your code in TS, and It's not gonna be completely useless because your text editor does a really good job of running TypeScript behind the scenes To evaluate your code, so that way you can still get many of the TypeScript benefits, all of that introspection stuff that you get from TypeScript, Being able to quickly get the documentation in your code, those types of features that you would normally get from TypeScript, you can get those with Babble. CSF. The only difference is is that you will not be able to prevent like, it doesn't run the type check on the build time or prebuild time, so it does not do any type checking itself. I've seen in the past where people just use the TypeScript compiler just to check if there's any type checking errors, and then they use Babel to actually transpile the code. So That's how we do it. Perfect. There you go. I didn't even know this until we did our show on it, and it just strips out all of the types. Right? It it strips out all the TypeScript stuff From it and then just returns to you regular JavaScript, which you can then go ahead. So, like, why does somebody wanna use Babel and TypeScript together versus just using TSC. Well, for us, we have different reasons than why you might do it with Babbel. So, I can get into for for why once we talk a little bit about Yes, build.

But for Babble, the reason why you might do it is because it's kind of difficult for people to modify their build process that much Yeah. To be able to change the The entire build of your entire application, let's say you're on something like Webpack using Babble already.

If you have to then add TypeScript Compiler. On top of that, you have to augment your build system a ton more than just dropping in the plug in transform TypeScript. It's like an easy way to ease into it. In fact, when we moved our code base over, that's exactly what we did. We Purposefully did not run TSC, and we ran TypeScript with Babel. This is back when we were on Meteor. We purposely ran it just with Babel so that we could Specifically,

convert code base over without the entire thing blowing up every 2 seconds. Another thing you might want Babel for is If you are using anything that's not in either languages yet, meaning it's not in TypeScript yet and it's not in JavaScript yet, A good example many months ago would have been the nested checking with the the question marks or coalescing.

These are just features that Have been added to language, and they're they're in TypeScript now. But if there is a feature that you want to test out in your TypeScript, Then you need to still run it through a transpiler,

and you can get plug ins. So if you have any babel plug ins, there's tons of them out there That you want to still use in TypeScript, then you'll still need to run your code through Babel. That's really neat. I think that's very common for people to run TypeScript through Babel. But there's also, like you said, you can run the TSC on the side just for the type checking when you need it. That's also very common to run both of those Or just have the TSC running within your continuous integration, continuous deployment set up, something like that on poll requests and things like that. We actually before we when we had it just in Babble, we had a we had a right to, like, a log file that showed us how many TypeScript errors we had because when we moved our whole Project over to TypeScript. We had, like, 500 some TypeScript errors. Right? So then we ran the the TSC to the type color checking, and it would create a text file for us, and then we could just diff that file to see you would see, like, 500 lines removed, and you'd be like, okay. We're down 500 TS errors just so you could see that, like, really quickly. Oh, that's a good idea. Yeah. That was Tom's idea Tom Allen's idea, and it was really super good. It was nice to see at a glance. Alright. Let's get into some of these other ways of compiling TypeScript.

Now this one is interesting to me, but I don't know a ton about it. I've seen it, obviously, the project a whole bunch. It's s w c dot r s. This is SWC. It's a Rust based compiler, and I have the feeling like this is going to be a little bit like Yes. Build is for Go. But for Rust, I honestly do not know too much more about it than that, though. Yeah. This is the one that they are Considering adding to Deno. So 1 question we had on our Deno show was, does Deno have its own

TypeScript compiler, or does it just use TSC, which is the TypeScript compiler. And the answer is kind of both. They are looking at moving away from TSC because of performance reasons and moving over to this new one as SWC, which is built in Rust.

And this is a pretty common thing that you see happen in web development is that somebody builds something. Like, I'll use Sass as an example. Sass was built in Ruby, And then people love it, and they pick it up. And then you start getting into really large projects, and the thing starts to just chug, and it gets a little bit slower. And we've all had like, Years ago, we had SaaS projects that took 3, 4, sometimes, like, 30 seconds to compile the entire thing, which is Brutal for your productivity. So they rewrote Sass in I believe it was c plus plus or just c. I forget. It was one of those low level languages. Somebody much smarter comes along and rewrites the compiler in a language that is better at doing that, and it gets way faster.

And then it's since been rewritten again.

There's 2 versions of Sass. There's Dart Sass. I was gonna say, it seems like there's a whole bunch. There's Node Sass, Lib Sass,

Ruby Sass, although I don't know. Yeah. Node Sass was the JavaScript version of it. There was a Ruby version of it, but the officially supported one is Dart Sass, Which I thought was really interesting, so they rewrote the entire thing in Dart as well. Cool. I remember many years ago when Dart was announced, and that was supposed to be what TypeScript is today. Yeah. I think it might have been too early for a lot of people. Yeah. I remember, like, there was, like, a leak of it. Like like, Can you imagine that there was, like, leaks of compilers? Like, what a what an industry we live in. Someone leaked a compiler announcement.

Yeah. I remember being like, oh, man. This is gonna be huge. It just never caught on. And then TypeScript came around, and everyone's like, yep. Yeah. I think it might have been too early. I don't know. I remember when Dart came out because it was when I was working at Ford. So yeah. That was that was really cool. So that's why there's other people working on Different compilers.

Imagine with WASM, it wouldn't matter what language it's it's written in. And because Deno this is, like, the next one. Deno uses TSC right now, but there's a huge threat on them moving over to this Rust based one just because it is much more performant to compile your TypeScript before it Goes ahead and runs it. And there's a an issue here I'll link up. I read about half the thing, and somebody went through and described How Deno handles the TypeScript? So it does compile it before it's run, obviously, and then it will recompile it if you're using the watch flag

before it runs it again, which makes sense. Yeah. Yeah. You have 1 more here, and I have ES build I wanted to talk about. Circase? I've never heard of Circase.

I never heard of it, until today. This is another one that came out. It looks to be written in TypeScript itself.

Basically, it's it's like another TypeScript compiler that's apparently faster.

I just threw it in here just in case anyone wanted to check it out. It says in the documentation, it says instead of compiling a large range of JS features to be able to work in Internet Explorer, Circass assumes you're developing for a recent browser or no JS version, so it focuses on compiling nonstandard language extensions, JSX, TypeScript, and Flow. Because of the smaller scope, Circase can get away with architecture that is much more performant but less extensible and maintainable.

I don't know. Like, they're honestly, there's much smarter people building these things. They do the whole thing where they compare it against the other ones, and it's, like, a 1000 times faster.

Let me tell you. When I talk ES build, though.

It is. Yeah. It is. Okay. So that's it. I I don't I don't really know whole much about it. I don't And why TypeScript wouldn't be able to do that if you, like, pass it what environments you're targeting. But, obviously, it's built for a reason. But ES build, I've been hearing nonstop about a fellow, so about that. It's a Go based compiler. It does not use Babel. So, basically, it would take the place of what Babble would be in your setup or even, like, ours takes the place of where we would use Webpack or whatever on the server side. We're compiling all of our TypeScript with ES build now. And out of the box, under the hood, without any modifications, type it it's supported for TS and TSX s x files, which means you could just start writing TS or TSX files and ESBuild's gonna know what to do with them, but it runs the same way that it would through Babble, isn't it? Just strips all of that TypeScript Stuff out. So they actually recommend in their docs to run TSC no emit in parallel for that type checking if you want build to break. For our server side setup, we only run it in our pull request, in our continuous integration. So before pull request, before deploys,

on merges, those types of things. I should note the Rust based one does not currently do type checking either. So at the time of recording, the only way to get type checking is with the native TSC TypeScript, But they are working on implementing it in SWC.

And for, like, most of most people listening to this, it probably doesn't matter. You just use the thing, and it works.

And that's cool, but it is interesting, especially because we seem like we're, I think, early days in this stuff. It's interesting to, like, Understand about all the different compilers. So the ES build one looks really, really cool, and you shouldn't really care that it's built in Go other than you know that it's it's fast Because somebody built it in Go. You can install it basically

with NPM, and then it just exists like any other package that you have. And there's a JavaScript interface for it. So you just write a JavaScript function, and it's like it's it's that or you just use it on the command line. They just added a watch functionality for it, which is great because they didn't have watch before, so now it can watch.

And let me tell you, it's just so much faster. And I would take This without the types checking on compile

over TypeScript compiler with the type checking every day of the week in a development environment just for how much time this saves Oh, yeah. And the type checking, you can just use the Versus codes, like, problems tab Yeah. If you need to know that. Right? You just pop that problems tab open and and look through there. And, Yeah. That's really cool. I'm gonna I'm gonna have to check out the CS build because I keep hearing awesome stuff. One kinda interesting thing I'm wondering is, Like, how can it just be installed as a NPM module? Oh, they have a prebuilt binary. So it's kinda cool that they could just build in and go Build this binary and then ship that with a JavaScript module, and it just works. You don't have to, like, oh, I got the wrong version of Go on my computer. You know? Oh, yeah. I didn't even have to think about The word go beyond the fact that it was built in this. Like, the go part of it does not factor in at all. Our tool base and everything is just straight up node. Yeah. Wow. Okay. So those are the compilers, and then we'll talk about bundler. So the difference between a compiler and a bundler. A bundler is more of like, like a puppet master. Often, your bundlers will understand JavaScript modules, but they don't necessarily do any of the conversion for you. They architect And allow other tools to sort of do the work for you. So we're talking about Parcels, Snowpack, Webpack. ESBuild is also one. All those other thousands of of ones out there. So the question is, if you're writing TypeScript, do you still need a bundler? Because TypeScript TSC Will allow you to output JavaScript at the end of the day. The question is, do you still need it? And the answer is you don't, but you probably still want one because it adds on A whole bunch of extra stuff. Like, you could take the output of TSC and just run that in the browser directly. But if you want, like, things like, handling Like, a lot of people think, like, importing CSS or images into your React application, that's not standard JavaScript. That's just special sauce that Webpack or Parcel or something actually handles. Right? Yeah. I mean, even for us, GraphQL,

I had to write my own GraphQL

loader for ES build. Oh, Oh, yeah. Loading GraphQL files. Yeah. I didn't think of that. Yeah. Which,

that actually might be a, worth a hasty on its own just like the process for writing a loader because You would not believe how actually simple it was. I didn't have to do anything other than say, hey. Look for doc GraphQL files. Is it this? Alright. What I'm gonna do is I'm gonna take this. It's gonna turn it into a JavaScript object, and then I'm gonna return that object. So that way, when the system does the import, all it sees is The JavaScript object that's being returned from the file is actually really pretty neat, and it was, like, less than 10 lines of code to write that loader. That's really cool. Don't you love when you, like, adventure into, like, a new dark corner of the web, and then you realize, oh, it's not that bad. Hey. That's it. Yeah. I wrote a GraphQL plug in. I was like, yeah. I I copied and pasted, like, 10 lines of code, and it just worked. Okay. I always think that about with the Babbel plugins because there's, like, these, like, syntax trees and Oh, man. I wrote one of those too, and that was fun. That was easier than I thought. Did you? So it's it's not even that Difficult. Okay. There you go. I wrote 1, 2, require styled components on every single page that uses the s t y l d, whatever, or styled by default so I didn't have to Ported everywhere. Oh, yeah. That's beautiful.

Other things a bundler will do is a tree shaking and smaller bundle files, so it'll figure out what code you're using. S. You can chop them up into smaller bundle files. If you need, TypeScript either exports every TS file as a JS file Or it will bundle it all into 1 big file. So if you need anywhere in between those 2, you have to reach for a a bundler as well. Mhmm. TypeScript does convert The syntax.

So if you're using, like, a generator syntax or the a nullish coalescing, all these, like, new syntaxes, And your target output is something like e s 3 and you want it to work in Internet Explorer 6, it will convert it all back to the equivalent of JavaScript at that time, but it doesn't polyfill functionality.

So it's not gonna add new methods to strings, or it's not gonna add Promise that all settled. All those, like, you're like, oh, this new JavaScript now needs to be polyfilled. TypeScript doesn't do that. You still have to go out and get your own Your own polyfills, whereas you can

add in polyfills pretty easily with something like Babel or Parcel. Yeah. Yeah. This is really interesting. I mean, once once everybody is able to turn on, like, modules in their package dot JSON files And they're able to do imports just natively and everything. I think everyone's JavaScript syntax is gonna get a little bit nicer, Especially once it's compiled from something like this, it it all just gets a little bit easier once you remove that step of this common JS and whatever, and everything starts To feel like, oh, these files could just about run. If it didn't have TypeScript in it, this file would just run as is without any any compilation. It's pretty neat. Totally. I'm I'm excited for that because we should do an updated show on,

like, how do you get away from CommonJS now that Node has Native modules? Yeah. Native ESM modules? So ESM modules. That's like ATM machines.

ES modules is the is the word for it. Alright. I think that's it. Anything else to add? No. I think that sounds great. And then, that we should dock that as an episode. I think that sounds like a a really interesting

Discussion. Yeah. Cool. Alright. Sounds good. Thanks for tuning in, everybody. Catch you on Wednesday. Peace. Peace.

CSF. Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player, or drop a review if you like this show.