You SHOULD Learn Vanilla JavaScript Before JS Frameworks

Photo by Ilya Ilyukhin on Unsplash

Rewind to 2013. ⏪

Our small dev team is about to ship one of its most impressive client projects to date. I’m at my stand-up desk, skimming through morning emails. My partner bursts through the office door:

“Something’s wrong with our Angular app, man. I’ve got a digest is already in progress error popping everywhere—can't figure out what's happening," he says, visibly nervous.

But I’m not nervous, nor stressed. I know exactly where to start looking, because I know my JavaScript.

And I know all of this thanks to a robot.

Rewind to 2011. ⏪

I was still a dreamy-eyed software engineer student back then, unaffected by the business imperatives of real-world coding. I was passionate about back-end development and had no desire whatsoever to learn vanilla JavaScript, or anything related.

But my friends and I had to build a soft real-time, task-oriented robot for one of our classes.

We named the robot Optimus Prime, and eventually sold it to Michael Bay.

We stumbled upon this new cool thing called Node.js (its docs back then). No fancy dependencies, easy child processes spawning, async and event-driven… and many online were saying it was the sh*t. We had absolutely no clue of what JavaScript or V8 were, but it still seemed like a good call for our project.

Peers told me to find a decent library for my use cases, and pull off some copy/pasting art to get the socket communication job done. I could’ve done just that.

But I didn’t. Although I didn’t know it at the time, that was one of the best early career decisions I made.

I started reading avidly instead. About asynchronous programming, the history of JavaScript, its pros and cons, everything. Because I wanted to master the underlying principles of the language powering my project. And it took quite a lot of time, coffee, beer, and dummy code to do so.

In between managing my teammates’ impatience and creating a not-so-clean, functional robot codebase, I learned a whole dmn lot*.

So what’s the point here? I took enough time to understand the core principles of JavaScript before using shortcuts provided by JS frameworks and libraries. Why is that important? Well, this is what this post is about: not just pretending.

Source: the ever-hilarious @iamdevloper.

What is “Vanilla JavaScript”?

Let me quote an answer from koenpeters on Stack Overflow:

“VanillaJS is a name to refer to using plain JavaScript without any additional libraries like jQuery. People use it as a joke to remind other developers that many things can be done nowadays without the need for additional JavaScript libraries.”

Or, in our case, without new, fancy frameworks.

The Vanilla JS “framework” joke

Online forums are filled with questions like:

What’s the meaning of Vanilla JavaScript? When was the term coined?

The history of the Vanilla JS site, which poses as a “JS framework” site, is short but funny. Eric Wastl created it in 2012, using a bit of trolling and confusion to hammer home a point: you can often use plain JavaScript instead of additional JS frameworks or libraries.

While Eric didn’t coin the term per se, his site definitely helped popularize it.

The state of modern, plain JavaScript

Historically speaking, developers needed to bypass plain JavaScript for MANY tasks, be it to make their code behave consistently across browsers, or just to go beyond what Javascript offered at the time. We’re talking IE 6–7 days. Developers often defaulted to jQuery in the process. But this long-lasting reflex of relying on external libraries is now irrelevant, thanks to the evolution of the ECMAScript spec, and to modern browsers keeping up with it more closely.

Today, picking vanilla JS vs jQuery is more often than not the smartest choice, so your codebase doesn’t end up needlessly bloated with dependencies. An obvious example from the excellent You Might Not Need jQuery:

jQuery

$('.my #awesome selector');

vs vanilla JS:

document.querySelectorAll('.my #awesome selector');

That site is full of useful vanilla JS examples — have a look!

Oh, and in case you need any more social proof:

A word on JS frameworks: pros and cons

First, what do I mean by JS “frameworks” here?

I put all of the Angular, Vue, React, Backbone, Ember, Knockout, Ext, jQuery, Meteor, Express, Koa, Total, Socket.io, and so on, in the same box. Yes, I know some are quite different. Yes, I know some are “not really a framework, but more of a library and BTW have you seen this thread on HN?”.

But please, for the sake of this article, let’s declare them equivalent in their primary purpose.

Pros: Why I think JavaScript frameworks are awesome

→ They help you out by abstracting hard & complex code.

→ They help you ship code faster and increase development velocity.

→ They force you to focus on your app’s value rather than its implementation.

These reasons quickly come up whenever we discuss the popularity of JS frameworks. But to me, they are marketing-ish reasons more than anything else. I’m not ranting against frameworks here — I’ve actually used quite a few of them throughout my career.

I believe the greatest value there is to find in JS frameworks is collaboration. Their consistent interface and methods allow developers from, say, Canada, the US, and Brazil to understand one another and work together.

If you’re building an app with [insert your favorite framework], when the time comes, you’ll be able to find an experienced developer to hop in the project codebase with confidence. This person will be able to start tackling features without you needing to explain every part of your software architecture.

Another key reason to use frameworks is practice. They make you practice, over and over again. And that’s good! Practice always leads to mastery, whatever you’re trying to accomplish.

Cons: Why I believe JS frameworks are not THAT awesome

People who work on frameworks implementation are all talented — at least most of them. They do a tremendous job of simplifying complex endeavors. But all of these levels of abstraction can quickly become evil.

In every app development, there comes a day when something doesn’t work as expected, and you don’t know why. That’s when you have to start digging. When you begin searching through poorly documented, complex, generic, pure JavaScript code, you’ll need a deep understanding of JS to make it. Otherwise, I can guarantee you’re going to lose all the precious time you saved by using your fancy framework. You might just have to buy a new espresso machine to meet your deadlines.

Sure, frameworks are useful for small teams working on a single app. Yes, they’ll save you some time (unless you’re a refactoring addict). But what if you have more than one team working on more than one app? Do you think all team leaders will agree on a single framework for the whole suite of apps? And what if a new “cool kid” framework comes around in 2019?

Problem is: the moment you settle on a framework, you impact every single upcoming engineering decision. Plus, you chain your team to a technology that will probably soon be deprecated. This stuff blows my mind.

Why should you learn vanilla JavaScript before frameworks?

If you master JavaScript fundamentals, your only challenge when learning new JS frameworks will be scoped to their specific syntax.

JavaScript is now the programming language for the web. Understanding its core engineering principles is paramount if you want to build yourself a decent web career. Especially if you’re aiming for the front of the pack.

In the past 5 years, more than 10 frontend JS frameworks made the news. Guess how many will do the same in the next 5–10 years? If you’re merely pretending to know JavaScript, the engine powering this web revolution, how will you keep up?

Just think about what “jQuery developers” are doing today: trying to catch up on Angular. Tomorrow, they’ll be trying to catch up on React/Vue. And the sad, depressing loop goes on.

Knowing vanilla JavaScript will make you actually understand — or even contribute to — JS frameworks, and help you choose the right one when you need it.

For me, it brought a lot of positive stuff:

• It helped me deliver a killer set of client features in a super short timeframe for an Ember app, without knowing jacksh*t about Ember.
• It got me a job offer from one of the tech giants because of a very simple library I wrote in my spare time.
• It made me identify bugs in libs implementation and suggest simple solutions super quickly.

Where and how can you learn vanilla JavaScript?

I hope I convinced you to get your hands dirty with plain ol’ JavaScript. If you want to kick ass at web dev, here’s my high-level advice:

Always be curious, always read the source material, and always try it yourself.

And some more specific advice:

• Whenever a new JS lib or framework is trending on Echo JS, Hacker News or GitHub, go on and read the sources.
• Every time you write a piece of code, try to think of a plain JS solution that could fit your needs instead of instantly seeking for a lib to integrate.
• Go on Stack Overflow and challenge yourself to answer vanilla JS questions on your own.

For beginners: I believe the learning flow outlined in this post by J.S. is a good starting place:

Now for the learning resources:

Learn Vanilla JS — Open source list of resources on GitHub 👈

I worked with my friend Franck from Snipcart to compile a carefully curated list of vanilla JS tutorials, books, courses, documentation, news sources, and blogs.

🔔 We want to keep it as open and collaborative as possible. So don’t hesitate to add valuable stuff with a fork + PR! 🔔

Some notable one-off articles not added to the list above:

I hope you find value in this small vanilla JavaScript wiki!

Takeaways

So here’s my TL;DR for you folks:

• If you don’t know the underlying principles of the web, you’ll eventually hit a wall thanks to the evolution of the language itself and the constant arrival of new frameworks.
• Knowing pure JS will make you a key engineer who can solve complex problems (reason before frantic searching).
• It’ll make you versatile and productive, both on the front-end and back-end.
• It’ll give you the toolset to innovate, not just execute.
• It’ll guide you on when to use a framework or not.
• It’ll give you a better general understanding of how browsers and computers work.

Using a JS framework can surely bring you somewhere fast. But it won’t bring you far if you don’t understand the core concepts behind it. Just like learning to play Wonderwall on the guitar won’t teach you how to compose music, but it’ll give you a reason to practice.

I firmly believe that this “learn the basics/roots first” principle applies to pretty much everything in life. From learning a new programming language to starting a new sport. It requires a lot of practice, but once you master it, the only thing left to do is to get creative with it. And that’s where the real fun begins.

If you’ve enjoyed this post, please take a second to 👏 + share it on Twitter. Comments, questions? Hit the section below!

Originally published at snipcart.com.