Join leaders from MIT and Vizio for a Remote IoT Development Virtual Summit.

Subscribe to our blog to get the latest articles straight to your inbox.

The Elephant in the Room

In recent years, developers have seen JavaScript explode. It seems like every day there is a new, shiny JavaScript tool that promises to solve all of your problems, while introducing a slew of new problems. Up until now, our client-side stack has been extremely volatile and it feels like every time a new project starts, we roll with a whole new set of tools.

There could be many reasons for that such as client requirements, lessons learned from previous projects, new community best practices, etc. However, this makes keeping up to date with all of the new tools extremely difficult unless they can be easily incorporated into your daily project. It is even more difficult when you are on a long term project with an existing code base that already has well defined patterns and deviating from those patters makes maintenance a nightmare.

So when it came time for me to change projects, I could feel the JS fatigue try to take me over again. After pairing with our JavaScript Practice Lead for a whirlwind tour of his latest project, I felt overwhelmed and like I needed to relearn all of the tools that I had already been using because their configuration hadn't needed to be touched in quite a long time. I became defensive, stating that we didn't need most of the tools and patterns he was using, I told him it was overkill. What was really happening is that I didn't want to hook myself up to a firehose of dependencies and patterns that I didn't have time to fully understand and dive head first into another project and drown trying to learn everything at the same time.

The Light at the End of the Tunnel

While I felt like I was staring into a dark JavaScript rabbit hole littered with dependencies, I was determined not to let JavaScript fatigue overtake me again. So, I made notes on all of the dependencies and patterns our JavaScript Practice Lead showed me in the tour of his project: TypeScript, React, WebPack, WebPack Loaders, StoryBook, Styled Components, Higher Order Components, Redux, Redux Forms, React Router, Jest, Enzyme, TSLint, Static Site Deployment, etc. Then, I added each to my project, starting with TypeScript, and only added another dependency or pattern once I understood the first one enough to be able to integrate it with something new. In doing this I found that I was having a lot of fun writing client side code again. I was able to learn the dependencies and patterns I needed fairly quickly yet understand them more deeply than when I tried to implement them all at once in a giant, tangled mess. I was able to take my current knowledge of ES6 and apply a base level knowledge of TypeScript to it that allowed me to better understand the errors that I was getting, resolve them, and move on with my life.

Diving In

What follows is a brief primer on TypeScript and I'm going to assume that you have some basic JavaScript knowledge.

In the past, if you needed to write a JavaScript function for greeting someone, you may have written something like this:

function greet(name) {
  return 'Hello ' + name + '!';

While this function may satisfy your requirements, it is fairly gross to look at and would be more difficult to maintain if the requirements changed and you needed to include more variables in greeting string. The same function in ES6 could be written as:

const greet = (name) => `Hello ${name}!`;

While this function is easier to read and the greeting message is easier to update. However, this function has many problems. If you try to use this function in your current code base, you will be able to call it without any parameters or any kind of parameters at all and receive unexpected results. So your instincts may be check if the variable is null, undefined, or to be a String. With TypeScript you don't need to do this anymore.

const greet = (name: string): string => `Hello ${name}!`;

By using TypeScript and declaring the type of the variable and the return type of the function, we will receive errors when the code is compiled if we try to call this function without params, if we try to pass an invalid value, or if we try to store the return value in a variable that expects something other than a string. Therefore we are able to do more by writing less code.

There is much more to learn about TypeScript such as: defining interfaces, writing global type declarations, building with WebPack, React with TypeScript, etc. I highly encourage that you read the online documentation for more details on getting started with TypeScript and start doing more by writing less.