You’ve done it! You finally have a good grasp of Javascript. Sure, you’re not developing your own Javascript framework anytime soon, but you can write and read Javascript at a level to build full, production-level applications.
But then you slowly realize even though you’ve spent all that time learning Javascript, a lot of teams aren’t even using it!
Javascript is still the language of the web (and most other things), but when you’re looking for Javascript jobs or projects, you keep seeing something that sounds like Javascript, but isn’t Javascript. One word that sends shivers down your spine…
Typescript.
“Oh great!” you think, “another thing I have to learn before I can build something or add value to a team as a developer.”
Well, two things…
First, you can still build production-grade applications using Javascript. There are many teams still using JS.
Second, if you already know Javascript and have a solid programming foundation, learning Typescript isn’t that hard.
In the next five or so minutes, I’m going to give you a quick overview of what Typescript is, why teams are using it, and (hopefully) convince you that you should use Typescript in your next large project.
Like with anything else, learning Typescript can seem a bit complicated at first. But look how far you’ve already come. I’m sure you’re already writing Javascript at a level you never imagined you’d write when you started learning.
Millions of people have learned it before, so you can, too! Okay, let’s get started.
What is Typescript?
Typescript is a language extension built on top of Javascript. It’s basically Javascript with more features. When you write Typescript, the code gets compiled into Javascript that is actually run on browsers, Node, or whatever platform.
Essentially, it’s a tool that makes developing robust Javascript applications easier. Typescript requires more effort upfront, but it’s easier to maintain and grow larger applications.
Typescript comes with various features, but the most important one is static typing. Luckily, I’ve worked with C# a bit (another statically typed language) so picking up Typescript wasn’t too difficult for me. But if you haven’t worked with a statically typed language before, let me show you what it is.
If you’re not familiar with types, types are essentially the kind of “thing” something is. For example, this is a sentence is a String while 101 is a Number. In Javascript, there are primitive types such as null, undefined, boolean, number, string, object, and symbol.
When you try to do an operation like:
"one" * 5
You get NaN because you’re trying to multiply a Number with a String.
If you do something like:
123.push()
You’ll get an error since the Number type doesn’t have the push method. That belongs to the Array, which is a kind of Object (actually a prototype if you’re more familiar or – like – a subclass if you’re familiar with OOP.)
In Typescript, you explicitly state types to catch these errors before runtime like this:
let name:string = "Josh"
Here we’re specifically telling Typescript the name variable’s type is a string.
Ok, so why does that matter?
Let’s say you’re writing a function like so (ignore the ‘:void’ part for now):
function helloWorld(name: string):void {
console.log(`Hello ${name}`)
}
If you try to call the function like so:
helloWorld(123)
You’ll get an error. Depending on your development environment, your text editor or IDE may warn you of an error and it may not even let you compile your code. That way you know there’s something wrong with your code now instead of later.
That might not seem like a huge deal now in a program with one function, but what about when you’re working on a large project?
Why Typescript will keep you from pulling your hair out.
If you’ve ever used test-driven development (TDD) before, you understand what I mean. If you don’t know what TDD is, it’s basically writing code that automatically tests your code for you. For example, if you add a new feature to your application, instead of manually using all the other features of your app to make sure your new code didn’t break anything, you do it automatically with tests.
Without using TDD, you can start a project and start adding features pretty quickly. There’s not a lot of “extra code” needed. You just start building your application.
But if you’ve worked on large projects without TDD, you’ll start to realize that adding additional features takes a lot more time. Instead of running the automated tests you wrote at the beginning, every time you add a new feature, you need to manually test your code to make sure your application still works.
All the time you saved initially by not writing tests is quickly sucked up as now you’re manually testing your application. And then you continue doing so, or you finally go back and write the tests you should have written at the beginning.
This is very similar (although not a one-to-one) to why you’d want to use Typescript. It takes more work upfront when writing your code, but you’ll save a whole lot of time (and headaches) by not having to fix bugs later.
Do you really need to start using TypeScript?
I typically never like to give definitive yes or no answers. There are always edge cases and each project has a different goal, context, requirements, etc… Without knowing your specific situation, it’s hard to give you a definite answer.
That said… even though it can be a bit of a pain when you’re starting to learn and use Typescript, it’s something that you’re going to be glad you had when you’re working on large projects and with a team.
Need to write a quick script to process some files one time? That sounds like a great candidate for just using Javascript since you can knock that out quickly. But if you’re working on anything substantial, it wouldn’t hurt to use Typescript. It also doesn’t hurt that many teams are using it, so it’s in demand.
That’s what Typescript is and why you may want to use it. But what about learning it? If you want some tutorials showing you how to use Typescript, let me know below and I’ll put some together.
Top comments (0)