No Stupid Questions (Developer Edition)

Typescript is Javascript with extra rules added to keep you, the developer, honest and explicit. The main way it does this is by enforcing types. This is a whole subject in and of itself, so here’s a lazy hand-wavy example from an internet stranger:

// regular js You, the developer: “hey js compiler, I’m gonna make a new array” JS compiler: “Cool, dude!” You: “Now please push ‘cat’, 5, NaN, and Date.new() onto the array” JS compiler: “No problem my guy (or girl)! You probably know what you’re doing!”

// typescript You, the developer: “hey js compiler, I’m gonna make a new array” Typescript: WHAT. THE. FUCK. Just like that?? An array of what, exactly?! Do you even know?? You’re grounded, mister. Don’t ever try to pull that shit again. The FUCKING nerve.”

Basically you and the compiler are co-parenting a removed js baby and you can pick between deadbeat dad or helicopter Karen mom.

It's going to be hard to explain to a new person.

Typescript is a subset of Javascript. All typescript compiles to Javascript.

There are large class of bugs/faulty logic that occurs in code, you might have noticed this with Javascript if you add the string/text to an integer, something like "5"+1, returns "51".

It might not behave how you would expect. Maybe the dev was lazy or tired and forgot to convert the string to an integer.

Typescript runs some logic checking on the code to make sure we catch these bugs before they make it to a website and cause real problems for users.

Generally learning either of them is fine, typescript might be harder at first since you need to compile it to Javascript. And there probably are more resources for Javascript as well.

TypeScript is a superset of JavaScript. It means any valid JavaScript is also valid TypeScript.

You should start to learn basic JavaScript mechanisms : prototype inheritance, hoisting, scopes, this, event loop, type coercion.

Once « JavaScript » sounds familiar you will embrace TypeScript which is JavaScript with steroids!

Typescript is 3 things:

• A language that you can write code in that compiles down to JavaScript. It's 99% JavaScript, though there are custom things.
• A type syntax system that can define object schemas.
• A type checker system for both JavaScript and Typescript files.

Generally, people use all three at once (.ts files), but you don't have to. Types aren't runtime code and can be mixed into the same file you are working on, even inline. Or you can use a separate d.ts file. Or you can use JSDocs.

You can also ask the Typescript checker (bundled with the compiler) to perform type checking on your .js or .ts with a slew of custom options. Commonly, when working with .ts, if the type checker fails against the ruleset, it won't continue on to transcompiling to .js.

I think sometimes the difference between strongly typed and loosely typed is easier to explain in terms of workflow. It's possible (note: not necessarily a good idea, but possible) to start writing a function in vanilla JavaScript without any real idea of what it's going to output. Is it going to return a string? Is it going to return null, because it's performing some action to a variable? Or is it going to return that variable? And vanilla JS is good with that.

But that same looseness that can be kind of useful when you're brainstorming or problem solving can result in unexpected behavior. For instance, I write a function that prepares a string for additional processing. For the purposes of this conversation, let's say that it removes white spaces and any non-letter or number characters, and then returns the transformed string.

What happens if I feed a number (integer) to this function instead of a string? What about a number with a decimal (float)? Does my function (and/or JavaScript) treat them as literal strings? Does it remove the decimal from the float, since it's a non-letter, non-number value?

Without Typescript, you have to either a) write your code in such a way that you ensure that the situation never comes up (i.e. by validating inputs, or by being very careful about when and how this function is used), or b) you have to handle those weird cases, which turns a cute little three line function into a 30 line monster with a switch case and typecasting. And truthfully, on any project 'at scale' you're going to have to do both.

With Typescript, you specify that this function takes in a string, and returns a string, and that's it. Then, when another dev (or you, in six weeks when you've forgotten all about this function that you wrote) tries to send in a boolean, or a float, or an array of strings, Typescript is going to blow up. Nope. Can't do that. And they (it's more fun to think of it as future you) will have to follow the rules that you put in place by writing the function the way you did, which just means being careful enough to cast a float or integer into a string before passing it, or concatenating an array, or whatever.

Strongly typed languages expect you to write functions with the end state you're expecting in mind. You've already got the solution in your head before you start typing, at least enough to know what type of data goes in and what type of data goes out.

It also hides (but doesn't totally get rid of!) some of the sillier things that JavaScript does because it's not strongly typed. True + True should probably never equal 2.

As to OP's question, though - if you know how to do things in JavaScript (.trim(), for example), then you know how to do a thing in Typescript. Manipulating data in JavasScript and manipulating data in TypeScript is identical - but TypeScript is also watching what the types of the different data types being used, and throwing up the BS flag when you get too loose with what you're doing (or don't think through the consequences of your design decisions).