Anyone that knows me knows that I'm a huge fan of coding everything by hand. Using plugins or 3rd party libraries is always last on my list, which is why you'll find me blog alot about how to do things with vanilla code. And there's a few reasons for this, which I'll go over today. And it's not because it's a longer less sought after process and that makes me cool. B) By no means.

This post will be filled with ice cream related metaphors.

The Best Flavor Of Code

Vanilla code is code void of any 3rd party ingredients and it just relies on itself. Like vanilla ice cream. It's just vanilla, and nothing else. You could add another flavor on top to sweeten up a bit, which you can think of as a JavaScript framework maybe. And then you can add a plugin for Stripe, a calendar, maps and a Twitter feed on top of that to top the whole thing off. Because nowdays we live in a very plugin-friendly environment, this seems like the way to go. Just like how no one really orders plain Vanilla ice cream anymore either.

After this, we end up with a nicer looking product, albeit a little heavier and a little harder to differentiate the many flavors.

And again, nothing wrong with that, except for the calories.

But it's a bit overwhelming right? You get to miss out on the base flavor down below. The vanilla probably no longer is discernible from the cookie plugin laying on top. Maybe it's not even vanilla down there. And the gallery plugin which is littered on every page and doesn't taste that good, can't really be moved aside anymore because it's too mixed in to the rest of your sweet dessert/code. And it's easy to get carried away adding more and more and weighing the whole thing down.

The Best Flavor Of Code

While adding 3rd party functionality to a project seems like an obviously faster and more streamlined approach, I have never once had a pleasant experience working with a plugin for a company. No one ever says "use that plugins functionality to do this". It's always something that either the plugin doesn't support, or that will take hours to figure out how to do and is not documented.

At my last job for example, I was tasked with adding an image to a carousel. Simple enough I would say. Except that part of the requirement included selecting the location of said image and adding a caption to said image as well. Two things which weren't supported by the plugin. I got it done. But am ashamed at that code.

College professors hate toppings

When you're in college, you are pretty much forbidden to use any 3rd party anything in your code. Because most professors don't want to correct the same code repeatedly across an entire classroom and because that would defeat the purpose of college. And many universities have policies forbidding such behavior. Kudos to you college.

...most professors don't want to correct the same code repeatedly across an entire classroom

Also look at this thing. It's somewhat difficult to make a red-black.js library that balanced nodes for you. Maybe one day.

The Best Flavor Of Code

But your manager...

When you go to work however, it's a different story and you're pretty much encouraged to use the latest and greatest plugins for everything. Full meetings are scheduled to decide just which calendar widget is the right one for the job. I've sat through many of those back in my hay day. I'll say this, on a new website, it's amazing to just plop in new features with a line of code. On an older and already weighed down site however, it's like having a week old melted ice cream cone and trying to revive it with fluff. You're just going to make matters worse.

I think deep down though, many times managers prefer to sugar coat projects with plugins in order to obfuscate the underlying project. If the vanilla isn't any good essentially. Just add some gummy bears and a few cherries and it tastes just fine. Just add a fancy carousel widget and a twitter feed and no one will notice the confusing sign up process that fails every 4th time.

Many times these plugins aren't doing anything that complex either. They might just be saving 2-3 keywords overall. And for a quick example, let me show quick and common jQuery command to toggle a class to an element.


$("#div1").toggleClass("selected");


So pretty straightforward really. This command will add a class to the selected element if it's not yet in the class list. Compare that to its JavaScript equivalent:


document.getElementById("div1").classList.toggle("selected");

And you can see that it's kind of weird to integrate an entirely new language to essentially convert classList.toggle to toggleClass. And more importantly, both pieces of code call the plain JavaScript one! Because that's how one toggle's classes in JavaScript.

Getting lost in your toppings

last ice cream analogy...I swear it...

Not that long ago we had the NPM story unfold, in which a developer unpublished many of his modules from NPM due to what he deemed unfair treatment. And what happened shortly after?

Well, this trickling effect of cascading failures began to unfold. As it turns out, Node.js was one of many big libraries that relied on one tiny removed library. So any websites using Node.js were in a for surprise. More shockingly to me was that this library didn't need to be a library at all. It was 11 lines of code. In fact, here they are:


module.exports = leftpad;

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch && ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

  return str;
}

This led to many discussions online asking the question if we had forgotten how to program. It's not that we forgot I think, but more like, we're in the process of forgetting. Just like no one remembers Assembly Language anymore really because we now have higher level languages like C# and Java.

Benefits of vanilla

So here are a few of my favorite reasons why I personally focus on plain old code before I give up and start thinking of that pre-built library.

  • Full code understanding
  • Self reliant
  • Fully customizable
  • In many cases, easier to understand
  • Better performance
  • It's free

And there's a ton more reasons, these are the just the primary ones. Focusing on just vanilla code will make you a much better programmer in the end. Because you're not just learning how to get a task done, but instead learning how to solve a problem to get a task done. Do this enough times, and it becomes second nature.

The only way to become better at programming is to actively do it. I've met way too many developers who show me their impressive looking websites, but that can't tell me how the login system works. It's a cookie. It's always a cookie.

I've always joked that we're just a few months away from a div.js library, that will render a div on your page.

<script src="div.js"></script>

Sadly, that's probably not too a farfetched idea.

And I'm not saying avoid all 3rd party libraries forever. That's just a waste of resources. I'm more saying have a reason to use that library, aside from "it makes it easier". Any other reason really. Maybe you have a deadline. Maybe this library uses some fancy 3D graphics and you didn't take physics in college. All good reasons. A plugin should be a treat for you, like ice cream toppings. You just spent a month working on this complex system, and you don't want to spend a week implementing the Twitter API. But if you're integrating a library to show a popup on button click...maybe it's time to start watching your calories.

Walter G. is a software engineer, startup co-founder, former CTO of several tech companies and currently teaches programming for a coding bootcamp. He has been blogging for the past 5 years and is an avid BMX rider, bio-hacker and performance enthusiast.
Buy me a coffeeBuy me a coffee
If you read this far, then I hope you enjoyed this post and found it useful! Consider adding to my daily coffee funds to continue to provide better and more helpful articles in the future!
Maybe later

Add a comment

Send me your weekly newsletter filled with awesome ideas
Post comment