WEBVTT 00:00.020 --> 00:06.620 Okay, this is just a quick lesson to demonstrate the benefits of using TypeScript versus using JavaScript. 00:06.620 --> 00:10.310 And I've replicated this project using JavaScript. 00:10.310 --> 00:12.290 And this is an app.jsx. 00:12.590 --> 00:17.810 And it's exactly the same code that I have inside the app dot TSX. 00:17.810 --> 00:22.940 And I've made a small change because the demonstration doesn't really work because I did have a type 00:22.940 --> 00:28.130 for this use state, but instead I've just put the name and the price inside. 00:28.130 --> 00:28.550 Here. 00:28.550 --> 00:29.630 You don't need to follow along. 00:29.630 --> 00:36.860 This is just a quick demo to justify the use of TypeScript, if you will, because not all developers 00:36.860 --> 00:42.590 love TypeScript, and some developers still to this day think that it adds unnecessary boilerplate to 00:42.620 --> 00:43.160 our code. 00:43.160 --> 00:49.070 But I disagree, and TypeScript has improved a lot over the years, so that the boilerplate that we 00:49.070 --> 00:55.910 do need to add to get type safety in our code is quite minimal, really, in comparison to the time 00:55.910 --> 00:59.300 it saves us when we make a typo. 00:59.300 --> 01:02.450 And typos as a software developer are the enemy. 01:02.450 --> 01:07.930 It's very easy to do, especially in configuration files, especially in JavaScript. 01:07.930 --> 01:13.270 And it used to be a real problem, because a typo in a JavaScript file is not going to let you know 01:13.270 --> 01:16.540 at compile time whether or not you've made a mistake. 01:16.690 --> 01:20.440 TypeScript is going to fail, and it's going to fail very noisily. 01:20.470 --> 01:24.580 So these two projects, they're effectively the same in the app.jsx. 01:24.760 --> 01:27.670 In this case, and the app dot TSX in this case. 01:27.670 --> 01:34.270 And just one other small change I've made is that the JavaScript project is running on port 3001. 01:34.300 --> 01:41.200 The TypeScript one is still on port 3000, but to accommodate multiple origins inside our Cors configuration, 01:41.200 --> 01:44.080 then we do just need to add both of those in there. 01:44.080 --> 01:45.520 You don't need to follow along with this. 01:45.520 --> 01:49.840 This is just a very short demo to demonstrate the benefits of using TypeScript. 01:49.840 --> 01:56.170 So this is the TypeScript version of this application. 01:56.170 --> 01:59.410 And this is the JavaScript version of this application. 01:59.410 --> 02:03.790 Both going out to the same API endpoint, both receiving the products back. 02:03.850 --> 02:11.790 Now the benefits of using TypeScript is if I was to make a typo in, let's say, the ad product, for 02:11.790 --> 02:19.620 example, and for the name, instead of the correct spelling of name, I decided or I made a mistake 02:19.650 --> 02:20.730 and called it names. 02:20.760 --> 02:27.480 Then in this case, in the JavaScript world, we don't get notified that there's a mistake in our code. 02:27.510 --> 02:33.450 And even without adding the TypeScript information, just the inference that we get from providing an 02:33.450 --> 02:40.320 initial value to our use state without actually specifying any type information, then we get notified 02:40.320 --> 02:44.370 very noisily that there is a problem if we hover over this error. 02:44.400 --> 02:51.000 One of the gripes about TypeScript is these warnings or these error reporting inside the code editor. 02:51.030 --> 02:54.120 These do admittedly look horrible. 02:54.120 --> 03:01.410 And when you do encounter this, and you will encounter this because TypeScript can on occasions be 03:01.410 --> 03:02.310 tricky to use. 03:02.310 --> 03:08.100 My suggestion is to scroll down to the bottom of the error and take a look at what it says in the last 03:08.100 --> 03:14.210 line or two, because typically this is going to give you the information you need, and specifically 03:14.690 --> 03:20.630 it tells us that the property name is missing in type and then it tells us the type. 03:20.660 --> 03:22.670 In this case names. 03:23.180 --> 03:28.940 And it's required in type name colon string price colon number. 03:28.940 --> 03:35.450 So in the last few lines we can kind of figure out what it is we're missing here, especially when it 03:35.450 --> 03:37.190 comes to looking at the code. 03:37.250 --> 03:41.660 Then we can say oh okay of course I've made a typo here. 03:41.660 --> 03:45.980 But in the JavaScript world then we don't get notified what the problem is. 03:46.010 --> 03:49.190 And this can go all the way into production without us noticing. 03:49.190 --> 03:52.970 And the only time we see that we do have a problem is when we try and use it. 03:52.970 --> 03:58.040 Then we don't get the desired effect inside the code in the TypeScript one. 03:58.040 --> 03:59.720 This used to crash our application. 03:59.720 --> 04:03.110 It doesn't do that anymore and we do still get the same. 04:03.110 --> 04:06.770 We still can use the application and still get the same problem. 04:06.770 --> 04:12.950 But the advantage is, we're told very noisily as we're writing the code that something isn't right, 04:12.950 --> 04:15.820 and then we can make the desired correction. 04:15.940 --> 04:21.520 Now, as it comes to using TypeScript in our code, we're going to create proper types for each of the 04:21.520 --> 04:22.750 things that we're using. 04:22.750 --> 04:27.700 So when it comes to hovering over the products, then we're going to have the full properties available 04:27.700 --> 04:29.080 inside our products. 04:29.080 --> 04:31.990 And what that gives us is much better. 04:31.990 --> 04:39.580 IntelliSense and Autocompletion inside our code editor VS code is brilliant with TypeScript by using 04:39.610 --> 04:46.480 TypeScript, even if we don't specify proper types, we do get decent intellisense and type safety because 04:46.480 --> 04:53.410 if I start typing or try and use item dot something, I get the list of properties that are available 04:53.410 --> 04:57.400 for this type that it's inferred from what we're using inside the state. 04:57.760 --> 05:05.410 In JavaScript world, if I try and do the same thing and I say item dot, then sure it can guess and 05:05.410 --> 05:08.860 it can guess pretty well because things have improved over time. 05:08.860 --> 05:12.580 And we do see the name and price, but we've got all of these other things that we can select. 05:12.580 --> 05:16.210 And I could say, yeah, sure, I want item dot JSON here, but guess what? 05:16.210 --> 05:17.140 That doesn't exist. 05:17.140 --> 05:20.040 And I don't get notified that there's a problem. 05:20.040 --> 05:25.500 So these are a few of the reasons that TypeScript is beneficial to use in our application. 05:25.500 --> 05:30.960 It doesn't have to mean that that we write a lot of extra code to get the benefits from it. 05:30.960 --> 05:40.050 But the time savings is immense, because if you make a small typo in a large code base with lots of 05:40.050 --> 05:46.290 functionality in just pure old, plain old JavaScript, and you have to track that problem down, it 05:46.290 --> 05:48.210 is time consuming. 05:48.840 --> 05:53.400 Whereas in TypeScript you're not going to make that mistake because you're going to be notified of the 05:53.400 --> 05:56.130 problem as you're writing the code. 05:56.580 --> 05:58.830 So it's a bit like insurance. 05:59.130 --> 06:01.890 You don't appreciate it until you actually need it. 06:01.920 --> 06:06.900 Otherwise it just feels wasteful to keep paying out for insurance that you don't need because you don't 06:06.900 --> 06:07.800 crash your car. 06:07.830 --> 06:12.030 But at that time where you do crash your car, you are very grateful when you've got insurance. 06:12.030 --> 06:15.240 And TypeScript can be seen in the same way. 06:15.270 --> 06:17.280 So we will be utilizing TypeScript. 06:17.280 --> 06:22.350 And in the next lesson we're going to take a look at creating a type for our products.