With the growing number of libraries and frameworks these days, it is getting harder and harder to bring code back down to the basis in order to complete a task. Sometimes, even the smallest and simplest of functions can become complex and hard to understand when a programmer is relying on a framework to handle the job.
This is where you might hear the term "vanilla programming" come into play. In this article, I will be breaking down just what it means to write vanilla code and why it might be more beneficial to do so, sometimes.
What is vanilla?
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.
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.
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.