Make Mine Vanilla (JS) – InApps Technology 2022

I’ve been seriously studying JavaScript for five months now. And not just “the good parts.” My goal is software developer or bust! Though there are occasional days when “bust” seems the likely outcome, overall I’ve been making slow but steady progress toward genuine JS proficiency.

When I tell people this they react in two predictable ways. Non-coders are all like, “Ooh, JavaScript, that is SO badass!” (Ok, not really, but that is how I choose to assign their universal and uncomprehending indifference. Type coercion ain’t just for booleans). Programmers, on the other hand, immediately ask, “Angular? React? Vue?”

This response used to make me panic. I had no idea what to say. There are so many JS frameworks out there, and someone still tentatively wading through the shallows of this diverse ecosystem can’t possibly know the “right” one to choose. So I would stumble through an explanation of how I was still evaluating the options before committing. (At which point I could just settle back and listen to the equally inevitable impassioned explanation of why Ember/Backbone/insert-your-personal-platform-of-choice-here is the ONLY reasonable choice).

Have you gotten solid with raw JavaScript yet?

And I was seriously trying hard to take all the various arguments, platform pros and cons, into account, in order to eventually settle on one. The right one. The BEST one. (Nerd alert: I made a spreadsheet to aid in the comparing and contrasting). But this veered toward me spending more time researching different frameworks than, you know, actually learning JavaScript. The indecision trap is real, people, and it can be an insidious time suck. Because it feels like you’re engaged in a real and important component of learning JS — only, research is not how you make actual forward progress. Actually writing code is how you, you know, learn to code.

I was about four long months in before I realized these future colleagues, though trying to be helpful, are asking the wrong question. They should be asking me, “Have you gotten solid with raw JavaScript yet?” Because that is not only the obvious first step but also the most important.

Taking time to understand the core principles of JavaScript before jumping on board all those tasty JS frameworks and libraries that the cool kids are using is not the fun way to go. But it’s the right way.

No matter where you are professionally, stumbling along with me early on the trail or perched way up on the 1337 heights of hackerdom, there will come a day when something doesn’t work as expected and you don’t know why. Now you got to start digging. And when you commence searching through that bolus of somebody else’s poorly documented, un-refactored, possibly (probably even) sloppy code, you’ll need a deep understanding of JavaScript to follow that trail of breadcrumbs to your problem. Otherwise, I can guarantee you’re going to squander all that precious time you saved by using your fancy framework — and then some.

I’ve been plugging away at programming long enough to understand two important things: first, the moment you commit to a framework, you are chaining yourself to a technology that will be deprecated sooner or later. Probably sooner, given the rate that new cool kids frameworks are popping up these days like Tribbles in Star Trek.

Second, when all is going well, frameworks will absolutely save you some time. Maybe even a small team of folks all working on the same thing. But. When are you ever going to be working on only one project? And in the far more likely scenario of more than one team working on more than one app — do you really think all team leads are going to agree on a single winner from the whole JS framework tower of Babel?

So, yeah, vanilla is my JavaScript flavor, thank you. It has taken me this long to be able to own that with pride. Come that great shining day when I finally take that dev job, I have confidence I will quickly pick up whatever frameworks they are using in their shop, for whatever projects I’m assigned to. And if sh*t breaks, I am also confident that I will be able to pop open the hood and see what’s going wrong.

Because at the end of the day, I’m not an Angular developer. I’m not a React or Vue or Backbone or Ember or etc. etc. etc. developer.

I am a JavaScript developer. Trying like hell to be, anyway.

Feature image via FreeStockPro.