My new ebook  Design Systems for Developers  is here! Start reading


Use The Source, Luke

Professional JavaScript: Episode 1

Last Updated: 2021-02-09

The following is a transcript of the latest episode on the Professional JavaScript podcast.


Hey everyone and welcome to the first episode of Professional JavaScript, the podcast for learning how to grow as a JavaScript developer in a professional environment where the problems are greater than just another todo list tutorial.

Each week, I, Michael Mangialardi, will be sharing what I’m learning as I write JavaScript code on a professional team. I’ll cover tips, tricks, technologies, and other goodies that you don’t always get when consuming other online resources.

Today’s Episode

In today’s episode, I’ll be telling you why you should “use the source” like Luke Skywalker used the force.

This is a timely episode. My wife and I just recently got a Disney+ subscription and watched the entire Skywalker Saga from start to finish.

It was my wife’s first time watching the series…I know 😱

Since watching the series, the talk of the house has been full of Star Wars references such as “use the force.”

While my wife and I have been saying “use the force,” I was reminded of the value of telling myself to “use the source.”

professional javascript use the source luke

You see, the dependencies of a JavaScript codebase can sometimes seem like the dark side. It’s cold and mysterious, and if you expand your node_modules directory, you might get blasted by Emperor Palpatine.

professional javascript use the source luke

There is some good reason for that. After all, there can be a lot of packages within your node_modules folder.

At the end of the day, we almost always use someone else’s code to build things. There is enough to be overwhelmed with given all the frameworks, utilities, and tools in the JavaScript ecosystem.

However, the way to grow as a professional JavaScript developer is to think about the “why” behind your code, not just the “how.”

Using the source is a great way to find out “why” a shareable package was created in the first place.

A package is shared when it solves a common problem.

Reading the README often provides a good sense as to what the problem is and how the package solves it.

Digging into the source code reveals “how” the problem was solved.

You may not need to write all the code out yourself to solve the problem (since you can use the shared package), but you may need to peak into the source code to understand how it solves the problem.

As you explore how packages solve problems, you will gather ideas of how you can take bits and pieces of the solutions and apply them to unique problems that you come across as a professional developer.

Think of a shared package as a completed Lego set and the source code as the Lego.

professional javascript use the source luke

For example, as part of my series on design tokens, I wrote an article on using a package called Style Dictionary to generate HSL color shades.

Style Dictionary is a shared package that can take a JSON file representing design specifications (also called design tokens) and transform them into a platform deliverable.

My article was on leveraging Style Dictionary to transform a JSON file with design specifications of “primary,” “secondary,” and “error” colors and exporting those colors, along with a range of shades, as CSS variables.

Before, Style Dictionary seemed like magic. I ran the CLI tool and it transformed a JSON file into CSS variables after I sprinkled some settings in a config file.

After getting stuck on how to generate shades from a single color, I dove into the source code.

It turns out that the transformations Style Dictionary did on colors were nothing more than a thin wrapper around a small JavaScript package for manipulating colors called tinycolor.

When I was not able to find a pre-defined way to use Style Dictionary to transform a single color into shades, I was able to go straight to the tinycolor library to solve the problem.

If I only knew about the Lego set, I would never have known about the value of the Lego. If I never looked into the source code, I would have never learned about how I could extract a portion of the code to solve a different problem.

Use the source.

professional javascript use the source luke

I’ll conclude this episode with a final tip as well as a challenge.

My tip is to start at the entry file of the source code and work your way through it. It can be confusing if you pick a random file to examine. However, starting from the beginning of the problem and working your way through the solution will help demystify the source. Treat it like a code review, read comments, and parse out what is relevant versus irrelevant.

My challenge is to use the source this week on any codebase that you touch.


Thanks for tuning in for this week’s episode of Professional JavaScript. Be sure to like, subscribe, and head over to my blog to learn with me.

Cheers! 🎉

Design Systems for Developers

Read my latest ebook on how to use design tokens to code production-ready design system assets.

Design Systems for Developers - Use Design Tokens To Launch Design Systems Into Production | Product Hunt

Michael Mangialardi is a software developer specializing in UI development with React and fluent in UI/UX design. As a survivor of impostor syndrome, he loves to make learning technical skills digestible and practical. Formerly, he published articles, ebooks, and coding challenges under his brand "Coding Artist." Today, he looks forward to using his mature experience to give back to the web development community. He lives in beautiful, historic Virginia with his wife.