Don't Learn A JS Framework

...until you master JavaScript.

Now, you don't have to be on the same level as Brendan Eich, Eric Elliott, or @getify , but you should endeavor to understand as much about vanilla JavaScript as you can.

Fan bois, rise up! Jump to the comments to defend the glory of your framework!

Now that I have your attention, let's have a discussion. Imagine you're at a fun party. Macarena comes on and a group of people immediately jump up to dance. You stare on, wishing you knew the moves, but you only know how to dance dance. You spent the last year learning to put your feet -- and only your feet -- in the exact spot the game told you. And when the dancers now shift to the electric slide where you have to move your feet and clap...well, this is the exact kind of situation your mother warned you about.

If I've spent time learning a JavaScript framework without taking time to understand the language at a deep level, I'm more like our woeful dance-dancer than I'd like to admit. Frameworks are built on and with JavaScript. So while you can code an app or website with React© or Vue©, you'll inevitably run across a situation where having a deep understanding of JS is necessary to solve a problem. Furthermore, if you always bet on JavaScript you'll be able to move from ~~the macarena~~ React© to ~~the electric slide~~ Vue© fairly easily.

Here's a real-world example of where understanding how JS handles object references could trip you up inside a framework.

Consider this Vue© SFC, Books.vue.

<template>
    <ul>
        <li v-for="(book,idx) in processedBooks" :key="idx">
            {{ book.toFilter }}
        </li>
    <ul>
</template>

<script>
    export default {
        computed:{
             processedBooks(){
                 const toProcess = this.books;
                 return toProcess.map(book => {
                     book.title = book.title.toUpperCase();
                     book.hasBeenProcessed = true;
                     book.toFilter = `${book.title}-${book.author}`;
                     return book;
                 });
             }
        },
        props: {
            books:{ type: Array, required: true }
        }
    }
</script>

<style scoped>
   li { list-style: none; }
</style>

And we use this little guy like so

<template>
    <Books :books="books" />
</template>

<script>
    export default {
        data(){
            books:[
                { author: "Eric Elliott", title: "Programming JavaScript Applications" },
                { author: "Kyle Simpson", title: "You don't know JS" },
                { author: "Matt Pagett", title: "The Best Dance Moves in the World" }
            ]
        }
    }
</script>

Now, if you were to take a look at the books property inside the Books.vue component, what do you think you'd find? You might expect it to just contain the authors and titles of our book list. However, this is what you'd see:

    [{ author: "Eric Elliott", 
      title: "PROGRAMMING JAVASCRIPT APPLICATIONS",
      hasBeenProcessed: true,
      toFilter: "PROGRAMMING JAVASCRIPT APPLICATIONS-Eric Elliott" },
    { author: "Kyle Simpson", 
      title: "YOU DON'T KNOW JS",
      hasBeenProcessed: true,
      toFilter: "YOU DON'T KNOW JS-Kyle Simpson" },
    { author: "Matt Pagett", 
      title: "THE BEST DANCE MOVES IN THE WORLD",
      hasBeenProcessed: true,
      toFilter: "THE BEST DANCE MOVES IN THE WORLD-Matt Pagett" }]

Even though Vue© won't let us mutate a prop, and we've copied the data from this.books into toProcess, we've still managed to alter the objects in the array. Why? Because JavaScript keeps the reference to the objects in the array throughout the processing. This has nothing to do with Vue© or any other framework, this is the way the language works. If you needed to do something with the original prop data, say POST that data to a DB, we're now working with objects that have more information than we were expecting.

Could this be avoided by knowing JS at a deep level first? Maybe. At the very least, when the bug of mutated original data crops up, you'd be able to identify how to fix it. If later on you tackle a project in React© or --shudders-- Angular, you'll be able to avoid similar problems.

JavaScript frameworks are great. They can make a developer's life easier and they do add value to our projects, especially large complex ones. However, it's very important to understand JS at a deep level before we dive headfirst into the ever-crashing tide of frontend frameworks.