![image](https://user-images.githubusercontent.com/224636/79864242-244ca000-83a7-11ea-8bb5-b7b11f9d7ec7.png)

> Is it not a strange fate that we should suffer so much fear and doubt for so small a thing?

Typescript has been around since 2012, but it wasn't until a few years ago that it really started picking up speed. A lot of *famous* JavaScript library developers started switching to it (particularly in the Angular, and then React, communities—and now everywhere). This was fine to ignore at the time because it didn't affect me. But in the past few months I keep noticing this trend in job descriptions: *"extensive Typescript experience"*.

I'm not new to types. I wrote a pretty large [open-source project](https://github.com/corysimmons/postcss-ant) using Flow (Facebook's challenger to Typescript), and I remember thinking Typescript was better for a few reasons:

1. In Flow you can cheat and just ignore typing half of your project (which doesn't make it very reliable). You can do this in Typescript too, but it requires the malicious effort of going through and adding the `any` type to everything, whereas you can just "forget" to type certain files in a project with Flow. So Flow's biggest selling point is actually a weakness.
2. Typescript has a **massive** collection of types for various popular npm packages out there. For instance, React. Go to [https://microsoft.github.io/TypeSearch/](https://microsoft.github.io/TypeSearch/) and search for some of your favorite libraries.

## But what is Typescript?

In programming, there are two types of languages: loosely typed and strongly typed.

JavaScript is loosely typed. If I say `var x = 1` then I (or some library) can accidentally re-assign that `x` var doing something like `var x = "1"` later on.

So think about that for a second. You are expecting `x` to be a `number` of `1` but it got changed to a `string`. This can frequently introduce bugs. Like... you are lying, or new, if you haven't ran into a bug like this hundreds of times in the past.

Just for type safety, I wouldn't say introducing Typescript is worth the overhead. I don't run into type bugs very often so it's not a huge selling point for me. The real benefit of using Typescript is all the annotations your code editor gives you now. Holy crap your code editor will light up like a Christmas Tree.

So I create an type **interface** (which is just something that looks like a JS object) and then feed that into a React component, and 💥—if my component doesn't have the right props passed into it, then VSCode let's me know.

![Untitled](https://user-images.githubusercontent.com/224636/79781962-55c45d80-830c-11ea-80e0-559fc7f14616.png)

Now I never have to worry about if I forgot a prop that my component needs.

## But wait, there's more!

These type definitions also act as pretty damn good layer of automated documentation.

![Untitled 1](https://user-images.githubusercontent.com/224636/79781979-5bba3e80-830c-11ea-8303-37cc9d7c1993.png)

I'm having a hard time holding `option` and hovering that `IPost` while simultaneously doing the keyboard shortcut and dragging to get a screenshot, BUT IF I COULD, it would show you a popup with:

```ts
export interface IPost {
  title: string
  body: string
  author: string
}
```

Think about how handy that is. 90% of the documentations we use are API References, and this is effectively that.

Think about that co-worker who writes all kinds of spaghetti and never documents it. Now you'll know the required (and optional) parameters, and types, of every function they push to the project. 🔥

### Does this mean docs are dead?

There's still a place for a greeting page with a getting started and some demos, but for the most part, yes, people should stop writing docs. Traditional docs are frequently outdated/broken and **frequently** a huge source of frustration for me.

Typescript can't lie or forget to update docs, so, combined with decently-named functions and parameters, it's strictly better.

## It looks hard.

It is and isn't. It's intimidating at first, so I highly suggest you make a ☕️ then speed-watch a video course on it to at least have a compass.

Then it takes a small project to get used to, but after that you'll be competent enough to fall in love with it like so many have before you.

You really don't have a choice. Like I said, Typescript is more-and-more frequently appearing in job descriptions, and being used in every significant project on GitHub. Unless you're the CEO/CTO, it's only a matter of time before you're asked to learn it. Might as well start now. You'll like it. 😇

Stay safe. ❤️

Why Typescript?

---
pubDate: 2019-10-17
---

![image](https://user-images.githubusercontent.com/224636/79875796-266b2a80-83b8-11ea-8be3-c9b843da4e89.png)

I very randomly got curious how to compare objects in Javascript so opened DevTools and began tinkering. I remembered you could use `JSON.stringify()` to do this, and it even works with deep equality. Example: `JSON.stringify({a: 1, b: {c: 2}}) === JSON.stringify({a: 1, b: {c: 2}})`

But it breaks the second those properties aren't in the same order. For instance, `JSON.stringify({a: 1, b: 2}) === JSON.stringify({b: 2, a: 1})` fails.

Like most deep things, I figured a recursive function would be necessary, and out of laziness, started Googling around to see if there was a really slick ES6 way to do it (like some fresh/obscure `Object.deepEqual` native method I hadn't learned yet or something), but alas, there wasn't.

I was certain Lodash had something. And of course it did. And in practice, I would probably use it because it's probably better tested for fringe cases, probably pretty performant, and Lodash is familiar to all developers and comes with lots of usage documentation.

But I was curious how it worked so I dove into Lodash code for a second and it was depending on sooo many little stupid building block modules for every single thing, that reverse engineering it made the problem _"not fun"_.

So, I just figured I'd try to solve it myself (which I'm proud to say I did really quickly—usually these things hamstring me for a couple hours but I solved this one instantly) and submit it to StackOverflow (since its an incredibly popular question, and my solution is elegant, maybe I could get some of that sweet SO karma), but all the threads for it were locked, so **HERE WE ARE**. 😩

```js
const nestedObj1 = { b: 2, c: { e: 3, d: 4 }, a: 1 }
const nestedObj2 = { a: 1, b: 2, c: { d: 4, e: 3 } }
const nestedObj3 = { a: 1, b: 2, c: { d: 4, e: 9999999999999 } }
const shallowObj1 = { a: 1, b: 2 }
const shallowObj2 = { b: 2, a: 1 }
const shallowObj3 = { a: 1, b: 9999999999999 }

// Recursively sorts the keys and returns a fresh object
function sortObj(obj) {
  return Object
    .keys(obj)
    .sort()
    .reduce((acc, curr) => {
      if (typeof obj[curr] === 'object') {
        acc[curr] = sortObj(obj[curr])
      } else {
        acc[curr] = obj[curr]
      }

      return acc
    }, {})
}

// Does that stringify comparison stuff to the _now 100% recursively sorted_ objects
function deepEqual(obj1, obj2) {
  return JSON.stringify(sortObj(obj1)) === JSON.stringify(sortObj(obj2))
}

deepEqual(nestedObj1, nestedObj2) // true
deepEqual(nestedObj1, nestedObj3) // false
deepEqual(shallowObj1, shallowObj2) // true
deepEqual(shallowObj1, shallowObj3) // false
```

That's it. Curious how it performs vs Lodash (maybe my next post should be figuring out how to do isolated function benchmarks 🤔), but it seems to work well in these few generic tests.

> **Update:** As it turns out my implementation is about 35% slower than Lodash's. 🤷‍♂️ Ah well, it was fun to tinker with.

Vanilla JS Deep Object Comparison

---
pubDate: 2016-10-12
---

![image](https://user-images.githubusercontent.com/224636/79875473-b5c40e00-83b7-11ea-8326-10864c127645.png)

Type-checking is pretty sweet and helps prevent lots of hard-to-find bugs. If you're using [default named params](https://github.com/corysimmons/blog/issues/4) for all your functions, it's fairly easy to integrate some simple type-checking.

A real-world example might make this more clear!

Frankenstein (the doctor -- not the monster) has some cats. Some of them have less legs than they are supposed to have. He can add more legs, but he developed some compulsive disorder and can only add legs if he's allowed to double them. As @mpjme would say, this is the kind of problem you encounter every day in Enterprise-level Coding™.

```js
const typeCheck = (interface, argsObj) => {
  for (const param in interface) {
    if (typeof argsObj[param] !== interface[param]) // Comparing the arguments to the type interface.
      throw new TypeError(`${argsObj[param]} should be a ${interface[param]} type!`)
  }
}

// Type interface
const kittenTyping = {
  nickname: 'string',
  legs: 'number'
}

const frankenKitten = ({nickname = 'Hops', legs = 3}) => {
  typeCheck(kittenTyping, {nickname, legs}) // interface, argsObj
  console.log(`*sewing sounds* 🙀  Now ${nickname} has ${legs * 2} legs! 😻`)
}

// Lets saw a leg off so Hops ends up with a normal amount of legs (4), then let's rename him Skip.
frankenKitten({nickname: 'Skip', legs: '2'}) // TypeError: 2 should be a number type!
frankenKitten({legs: 2}) // Ah, that's better!
```

Now we're catching type bugs that otherwise would've leaked through since clever JavaScript will "intelligently" (aka: magically) convert that `'2'` string into a number during the multiplication step.

> **Protip:** Place `typeCheck()` right above `return` statements to help prevent bugs. If you encounter a bug, just add `typeCheck()`s higher and higher in your code until you find the culprit (then clean up after yourself except for that one right above your `return`). Psst, the culprit usually looks like `Object.<anonymous>` in the terminal stack trace.

This isn't great because it requires us to pass all the interface params to `argsObj` whether we're using them or not.

```js
// Hops is still a good name!
frankenKitten({legs: 2})

// ...

typeCheck(kittenTyping, {legs}) // Error! We always need to pass whatever params match in the function defaults and the interface.
typeCheck(kittenTyping, {nickname, legs}) // Works, but smells a bit.
```

I'm sure there's some clever way to capture deconstructed variables without having to explicitly pass _all_ of them within `typeCheck()`, but tbh, this solution isn't as nice as existing tools and I'm getting hungry.

It **is**, however, a pretty good way to start sneaking basic type-checking into stuff without introducing any dependencies.

It also educates and promotes the discussion of integrating one of those more feature-rich solutions. Coworkers should begin to see the value in type-checking, but probably feel kind of gross about all the `typeCheck()` functions littering your code, or they'll want to typecheck arrays and such...

That's the _purrfect_ time to sell something like Flow/TypeScript/Elm. 😽

Building a Simple Typechecker

---
pubDate: 2016-10-11
---

![image](https://user-images.githubusercontent.com/224636/79875242-6382ed00-83b7-11ea-82e7-789a8670d246.png)

I'm starting to wonder if we should just use named params for everything. They provide a lot of flexibility with no side-effects that I know of.

Here's how you do it:

```js
const foo = ({a = 1, b = 2}) => console.log(`a: ${a}\nb: ${b}`)

foo({})
// a: 1
// b: 2

foo({b: 3})
// a: 1
// b: 3
```

- We don't have to pass any smelly stuff like `foo(undefined, 3)`.
- Our parameter is more descriptive.
- Our parameter is more flexible because it's not bound to any order-of-appearance.

Equal sign when setting defaults. Colon to assign when calling.

Yes, now you have to at least pass an empty object to your functions, and yes, we're forcing people to pass objects at all times, but there's probably an argument to be made about objects being more flexible anyway, and all-in-all, these are small prices to pay for how nice default arguments and named params are.

Named params have always been one of my favorite features of a language. JS doesn't seem to support a super-clean (still have to pass these as objects) way to do this, but at least now we can do it somewhat elegantly.

Now... if only there was a way to [type-check those params](https://github.com/corysimmons/blog/issues/5)...

Default Named Parameter Functions for Everything

---
pubDate: 2016-06-23
---

![image](https://user-images.githubusercontent.com/224636/79872348-b064c480-83b3-11ea-866c-fa69c0a2f821.png)

There are new versions of Javascript (ES6, ES7) full of [new features](https://babeljs.io/docs/learn-es2015/) and a ton of syntax shortcuts. For example:

```js
() =>
  2
```

...is shorthand for an anonymous function that returns 2.

As with everything in programming, people can't agree on anything and browsers are slow to implement stuff. We'd have jetpacks before browsers implemented it correctly/consistently so some cool people made some things called "transpilers" that convert ES6+ to usable old-fashioned Javascript (ES5). The most popular one is Babel.

[Here's](https://babeljs.io/repl/#?evaluate=true&lineWrap=false&presets=es2015%2Creact%2Cstage-2&code=()%20%3D%3E%0A%20%202) what it converts the above code to.

Babel works with just about [any build process](https://babeljs.io/docs/setup/), and is extendable with [modular plugins](https://babeljs.io/docs/plugins/).

## How to use it

The easiest/cleanest way is installing some npm packages and configuring it in `package.json`. We'll make an npm script for it so we can run something like `npm run dev` from the terminal.

- `cd ~/playground/babel`
- `echo '{}' > package.json` (create a valid JSON file so we can `npm install` to it)
- `npm i -D babel-cli babel-preset-es2015 babel-preset-stage-0` (this will install Babel's CLI, ES6 (aka: ES2015), and ES7 support)
- Add a `"babel"` object to `package.json`. Inside it we'll tell it to use the presets we installed:

```json
"babel": {
  "presets": [
    "es2015",
    "stage-0"
  ]
}
```

- Create a `test.js` file and put it in a `src` folder. `src` (sometimes `lib`) is your original code. We transpile stuff from `src` to the sibling `dist` folder.

> **Protip:** You transpile CSS (Sass, Stylus, LESS, PostCSS, etc.) and HTML (Pug/Jade, Haml, etc.) as well. Currently most companies organize this stuff as `src/css`, `src/js`, `src/html`, etc. but I think [component architecture](http://ecss.io/chapter5.html) is a better solution for larger projects so try it out if you can.

- Now run `node_modules/.bin/babel src -d dist` to ensure ES6/7 files in `src` are being transpiled to vanilla Javascript in the `dist` folder.
- If you run `node_modules/.bin/babel -h` you'll see it has a watch flag.
- Run `node_modules/.bin/babel -w src -d dist` and change some stuff in `src/test.js` to make sure it's being transpiled on saves.
- Now... it'll suck to have to type all that crap every time so add it to the `"scripts"` object in `package.json` as `"dev"` then just run `npm run dev` (`package.json` scripts don't need the `node_modules/.bin/` part).
- You can add/nest extra files in `src` and everything will work fine.

`package.json` should look like this (if you copy this make sure you run `npm i` before using it):

```json
{
  "devDependencies": {
    "babel-cli": "^6.10.1",
    "babel-preset-es2015": "^6.9.0",
    "babel-preset-stage-0": "^6.5.0"
  },
  "babel": {
    "presets": [
      "es2015",
      "stage-0"
    ]
  },
  "scripts": {
    "dev": "babel -w src -d dist"
  }
}
```

## Congrats

Now you're able to use ES6/7. Not only that, but you're using `package.json` scripts to perform tasks which is [pretty nice](http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/) as long as a CLI for a particular tool is available (if one isn't, consider doing everyone a favor and [making one](https://github.com/sindresorhus/meow)).

## Homework

- Learn ES6/7. It's awesome and will make your code much more elegant.
  - [https://babeljs.io/docs/learn-es2015/](https://babeljs.io/docs/learn-es2015/)
  - [http://www.2ality.com/](http://www.2ality.com/) (amazing tutorials)
- Learn how to use [npm-run-all](https://github.com/mysticatea/npm-run-all) to watch/transpile Babel and Sass at the exact same time and consider completely replacing Gulp/Grunt with npm scripts.
  - Make Sass output source maps to `dist/css/maps` folder.
  - Make Sass build everything in `src/css` before it watches.
  - [Answer Gist](https://gist.github.com/corysimmons/80e206aba0e807df2ef6f9ab5fd25300)

Babel

---
pubDate: 2016-06-22
---

![image](https://user-images.githubusercontent.com/224636/79872522-e43fea00-83b3-11ea-925a-90e206d9a384.png)

Linting is cool. It keeps people from making stupid mistakes and can make your code a lot neater/easier to read.

Not linting is how you end up with spaghetti code that no one can read.

Lint **everything**. HTML, CSS, JS, Python, Ruby, PHP, etc.

ESLint lints JS really nicely.

There was JSHint and JSLint, but they were hard to extend so someone made a JS linter that was easy to extend called ESLint. It's now the standard.

Agree with your team on a coding style. This part isn't super important and there are a ton of well thought out configs out there already like [AirBnB](https://github.com/airbnb/javascript/tree/master/packages/eslint-config-airbnb). What's important is you all agree to do the same code style!

## How to use ESLint

Use npm. It's easy and portable.

- `cd ~/playgrounds/eslint`
- `echo '{}' > package.json`
- `npm install --save-dev eslint-config-airbnb eslint-plugin-import eslint-plugin-react eslint-plugin-jsx-a11y eslint` ([AirBnB usage](https://github.com/airbnb/javascript/tree/master/packages/eslint-config-airbnb#eslint-config-airbnb-1))

> **Note:** I feel ya. All of these npm packages seem silly, but it's the whole Unix philosophy of making everything modular. It's a bit annoying, but overall it's usually a good thing.

- At this point you could do something like `eslint --init` to make an ESLint config file. In that file, you could add something like `"extends": "airbnb"`, but that's newb stuff. Do we really need **yet another** config file?
- Do this instead: in your `package.json` add an `"eslintConfig"` object with `"extends": "airbnb"` in it.

> **Protip:** If you're configuring some npm package, see if you can put it in `package.json` instead of having 20 config files polluting the root of your project.

- Now you could run `node_modules/.bin/eslint` in terminal (and this is actually cool/useful for the `--fix` flag), but you don't want to be switching between terminal and editor after every keystroke to see if you made a mistake, so install an editor plugin for ESLint. Here's [Atom's](https://github.com/AtomLinter/linter-eslint). ESLint is insanely popular so there is almost certainly a plugin for your editor.
- Restart your editor and type some sloppy, error-filled, JS. Your editor should light up like a Christmas tree.

## What if I have some global variables? jQuery doesn't work! `alert()` is throwing an error!

Config it!

```json
"eslintConfig": {
  "extends": "airbnb",
  "env": {
    "jquery": true
  },
  "rules": {
    "no-alert": "off"
  }
}
```

## Congrats

Now you're linting your JS like a pro. Enjoy your impending OCD.

## Homework

- Experiment with some other configs ([standard](http://standardjs.com/) is currently my favorite).
- Write your own config.
- Skim through the [rules](http://eslint.org/docs/rules/) and read what some of them do.
- Skim through some [configuration options](http://eslint.org/docs/user-guide/configuring) so when something breaks you might have an idea as to what's wrong.

Cory Simmons

I made these sweet grid systems

I HAVE MORE TOOLS ON GITHUB

I like teaching

READ MY BLOG AND LEAVE COMMENTS ON GITHUB

I have worked with

AND MANY MORE