When to Prefer ES Features to TS Features
Let's summarize the ES and TS features we've looked at and when you should use them.
We've looked at enums, namespaces, and parameter properties. Each of these features has a pretty predictable output.
Enums are compiled into an object with properties for each enum value, as well as properties for
Transcript
00:00 Okay, I've been giving my opinion on whether you should use ES features or TS features throughout this whole section. I've not been particularly guarded in my opinion. I think you should probably be using mostly ES features, but let's just take everything that we got,
00:16 put a bow on it and summarize it all. Each of these features, enums, namespaces, parameter properties has a pretty predictable output, right? We know that an enum on the left hand side here will get compiled down to something that looks like this, an object that has properties
00:33 of up, down, left and right and 0, 1, 2, 3. Okay, cool. We also know that a namespace will be compiled to something that looks pretty similar actually, and just essentially is an iffy with an, or an immediately invoked function expression that has a, passes in
00:50 math utils and basically assigns some stuff to that math utils. We know that's fine. Okay, good, good, good. Then we have inside this class here, we know that if we use a parameter property like private, my private prop, then inside the class on the right, we'll have a constructor and it will just automatically add this little assignation
01:08 to it. Fine. Okay. And if you want to use those, I think that's absolutely fine. But now we get to, I think the sort of philosophical points, full screen. I think I've, I had
01:21 a really hard time kind of articulating why I feel that enums and namespaces and classes are maybe not what you want to be using in your app. Oh, sorry. Classes are fine, not private properties. I had a hard time articulating why I think you shouldn't be using them. I
01:36 think because there are several efforts in JavaScript right now to actually bring TypeScript a bit closer into JavaScript. There's a, there's a proposal called types as comments. What types as comments says that we're going to bring in a lot of the features of TypeScript
01:55 into JavaScript. So you would write them in .js files and you would basically say, okay, we're not going to bring in the stuff that changes at runtime. So all of these namespace, enum and parameter properties, they wouldn't count. It would just be some type annotations and the type annotations, JavaScript engines would just ignore them. So you could type
02:13 checked, type check JavaScript files using TypeScript annotations, but you wouldn't need to sort of strip them at runtime. That's pretty exciting. And it means that if that's true, then these features do have a kind of like, they might be killed at some point in the
02:33 future, not by TypeScript itself. TypeScript will always support these features, but if TypeScript changes into something where it's mostly just running JavaScript files, then you're not going to want these features. The other thing is that let's say we get enums
02:48 in JavaScript. Well, enums in JavaScript might not conform to the spec that's in TypeScript. They might be slightly different. They might require slightly different things. And so you would then, TypeScript would probably have to add a flag saying experimental enums
03:04 or something inside the TS config. So it just feels like you shouldn't be using these. And every time I talk to the TypeScript team, they're kind of like, yeah, we maybe shouldn't have done that. And I think they might be a little bit annoyed that they have to keep
03:21 kind of fighting off the accusation that they want to change JavaScript or change JavaScript into something that's more, I don't know, like C sharp or something where, you know, you have enums and classes and things like that. Because really what they want to do now and they have been wanting to do this for a while is just add type annotations on
03:41 top of JavaScript and then work with JavaScript and the TC39 committee, which is what decides the future of JavaScript in order to kind of figure out what should go in. So my thinking is you should probably not be using any of these features. Also, I got linked to this
03:59 list of open enum bugs as well, which you can check out here, which is just like a huge array of bugs that are just sort of built on the fact that enums exist in TypeScript, but not in JavaScript. I would tend to not use these in a code base that I started from
04:18 scratch. I wouldn't mind though, if I had to use them based on a code base that's already existing. If that's a pattern in your code base, if you're using namespaces for some reason, I don't mind jumping on the back of that. If you're using private parameter properties
04:34 or enums, sure, I can get behind it. I don't think though you should be starting new projects with this. And I think that's my final word on it.