Vanilla

At Baskin Robbins, they boast about their plethora of choices. 52 different flavors of ice cream. If you only mix two you have the possibility of wetting your taste buds with 104 different combinations. Add a third scoop and the possibilities are endless. Your tongue will swim in a different flavor everyday, as much as you try you will not get to taste all the combinations. At least not before you would have gotten an early death from diabetes. But I am of the boring kind. For the rare times I go to Baskin Robbins, or any of those ice cream parlors, I settle for two scoops of vanilla.

Plain boring vanilla. It doesn't look adventurous, or make you look cool in front of the kids. But vanilla taste good and like any other ice cream it gives you the satisfaction that comes from eating sugar. If it was a job to do, vanilla ice cream would get the job done.

Now since this is a blog that revolves often around programming, I have to find a way to tie this ice cream analogy with something relevant with code.

Turns out, there is something that ties very well with it. In programming, Vanilla is synonymous to "plain". Vanilla JavaScript means Plain JavaScript. In other words, JavaScript without the extra libraries on top of it. One example would be when you ask programmers today if they have any experience with JavaScript, they would say "I'm very good with Angular, but don't know much about Vanilla Js."

Just like with Ice Cream, most programmers find Vanilla JavaScript plain and boring. For that matter, they find many plain programming languages plain and boring. This could have been a good thing if you didn't need the plain part of the language to program, but you do. If you don't know Vanilla JavaScript, you will make a poor Angular developer, or jQuery, or any library for that matter.

It's common to hear that the tech landscape will shift from under your feet. Whatever you are learning today might be obsolete tomorrow. In some way it is true. I don't remember the last time I saw a website that runs the Yii framework. If you called your self an expert Yii developer, you wouldn't be bragging about it today. It's just not in use today. But PHP is still powering the bulk majority of websites. Libraries sure become obsolete, but the programming languages that power them stay relevant. C and C++ existed before I was born, they will probably be running the app that will gather people to come to my funeral, hopefully it won't screw up.

So in some sense you may start to see that in the programming world, the tech world, Vanilla is the only thing that keeps paddling, while those fancy flavors fall out of fashion, and are often forgotten.

But I am not a fan of Vanilla only because I know it will be around forever. It is very useful to form yourself as an expert[*] in the programming language you use.

One of the famous example is how badly jQuery is used. jQuery is designed to make almost anyone capable of turning their website into an interactive website. It takes all the quirks of the browser and nicely wrapped them in a user friendly API. No more you have to care if a browser has an odd way of supporting a certain feature. You just have to call a jQuery function and it will take care of it for you. Now, people go around copy and paste code from anywhere, never catering it to their own need. They take the example script that is only designed to teach you how a feature works and they add it to the actual website. When you and I visit the website, we wonder why it is frozen, why it takes 5 second to respond every time we click on something, why the animation is choppy. Remember how myspace was slow? Same reason.

I've worked on projects where every single feature of the website is a different library. And each library is daisy chained into another making it impossible to remove or move anything. Most of the times the features that are needed are trivial. Not long ago, we had the kik problem. A developer removed one of his small script, only a few lines of code from the NPM repo. Millions of other libraries depended on this library and you can imagine how many people woke up the next day to broken code with no apparent solution.

My favorite!

Recently we had to make this change in one of our projects.

<script async defer type="text/javascript" src="~/Scripts/moment.js"></script>
  <script>
  $(function () {
      //convert time to UTC
      $('.date').each(function(){
          var el = $(this);
          var localTime = moment.utc(el.text()).toDate();
          localTime = moment(localTime).format('MM/DD/YYYY h:mm a');
          el.text(localTime);
      });
  });
  </script>

VS:

<script>
      $(function () {
          //convert time to UTC
          $('.date').each(function(){
              var el = $(this);
              var local = new Date(el.text() + ' UTC');
              el.text(local.toLocaleString());
          });
      });
  </script>

The change is is not very obvious, but if you look at the top one it uses moment.js. A 4000 lines of code library, only to be used once. Doing the same thing in Vanilla JS takes only one line of code yet it delivers the same result.

The trick is to go Vanilla first, then if you are solving a problem that is too hard then you think of a third party library. But even then, you can easily copy the part of the library that solve your problem instead of entirely downloading it.

Don't sell yourself short. We are programmers, we have the expertise to look into a library and understand what is going on. If we don't understand it, we probably don't need it. Go ahead and try vanilla, there is nothing wrong with making the boring choices. Especially when they are the only ones with the guarantee of being around many years later.

---