Enterprise Architecture Patterns

TypeScript vs Vanilla JavaScript

Enterprise Architecture Patterns

Check out a free preview of the full Enterprise Architecture Patterns course

The "TypeScript vs Vanilla JavaScript" Lesson is part of the full, Enterprise Architecture Patterns course featured in this preview video. Here's what you'd learn in this lesson:

Lukas demonstrates why TypeScript makes it easier for developers to communicate the intention of code. Prior to ECMAScript 6, class-like objects could only be created through prototypes. ECMAScript 6 introduced native classes in JavaScript and TypeScript adds strict typing to those classes.


Transcript from the "TypeScript vs Vanilla JavaScript" Lesson

>> So let me move on and I want to do a quick TypeScript interlude. So we're gonna be using TypeScript where appropriate, but when we talk about plain old JavaScript, what do we mean? Well, we're typically talking about ECMAScript 5 the reason being is that this is what runs in all the browsers and so when you write JavaScript at some point, it's being compiled into plain old JavaScript.

I know it's boring but More frustrating is that if I said I want you to create a class and add some methods to it. Well, it is five like, this is a real mind warp. Like how do you create the concept of classes when that's not even part of the framework and so imagine so I learned how to program with ActionScript one, which was essentially Ekman script three.

Imagine trying to learn object oriented programming on a prototypical language like this. The problem with this is that We're trying to express an object and methods in the context of a class but the code itself doesn't look anything like it is that it's obscured by the language mechanisms of like, like what has shaped our prototype.

Well, you don't understand that until you have to go and backfill like this long theoretical and academic discourse of like how prototype works and what does this mean? Well, who knows what does this mean? It can mean anything. And so, things are a little better when we move to ECMO script at least I can define, the concept of an object that does things.

And so now we have a class with a shape that, has a constructor method that has two more methods set location, and get location. So somebody would look at this especially coming from maybe a classical background and this would make a lot of sense. This, you look at just like Java programmers and C sharp programmers, they see this and they just throw a chair through the window.

They can look at this, and this makes sense, or more sense. TypeScript, on the other hand, which we're going to use, because it's better at communicating intention, and let me show you what I mean there are now this little bit of sprinkles that we've put on to this that helps communicate not only to myself, my future self, but other developers and to the IE.

What I expect when I write my code so if we go back here, this is pretty good, but how do I know. What ID is, is that a string or a number? How do I know what x and y are? Is it an object, a number, a string?

What is it? Well, TypeScript because it's good at communicating intent, this is one of the main reasons why I love it. Is that we go in and say ID is string, x and y, or a number. And that's helpful because not only are we communicating to somebody who's consuming this, but to the UI, now it can infer and introspect this class and help you out.

Not only that is we can start to extract pieces and say, location is actually a combination, it's just an object that has an X and Y property. So we can pull that out, and we can define that and so now when you look at x and y, what are we talking about?

Well Probably we're talking about location but we're not communicating it very well. Now when we look at this, when we say get location, and it returns this dot location, that makes a lot more sense. And so this is again, reducing complexity at the technical level and at the human level.

This is why I believe, and I'm all in on TypeScript, in fact, every major framework that is around has TypeScript options if it's not baked in, so I know that obviously angular is all in on TypeScript, but you can do react, you can do view. Interestingly enough, the one framework that a lot of people don't talk about anymore, but it's still really, really good is dojo and Dylan Shimon he lives in Phoenix and he runs the TypeScript meetup in dojo.

They've done a lot of really cool stuff but it's all TypeScript they rewrote the entire framework in TypeScript. So pretty much every major framework that I know of is at least as an option for TypeScript. Why? Because it reduces complexity through meaningful Signaling of intention. And when we talk about flow control, what are we talking about communication, TypeScript helps solve the communication problem.

But at the end of the day is just JavaScript is that our TypeScript is compiled down into something the browser can use.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now