DEV Community: Paul Thompson

Don't Learn A JS Framework

Paul Thompson — Mon, 15 Nov 2021 16:05:04 +0000

...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.

3 reasons to use 'var' in JavaScript

Paul Thompson — Mon, 08 Nov 2021 22:19:53 +0000

The var keyword was JavaScript's first way to declare a variable. It fits, right? Var, variable, it's in the name. But like the Joker, var is more than pretty face -- it has some baggage. As a beginning programmer, or a seasoned one dipping your toe into the seedy underbelly of JavaScript development, you maybe be wondering when you should use var to declare your JavaScript objects and functions.

Never fear. I have 3 reasons for you to use var in your next JavaScript project.

You love tradition and spurn anything new

Var may be the oldest keyword to declare a variable, but it is by far the only one. It's younger cousins, let and const exploded onto the scene with ES6 (over 6 years ago as of this writing!). But if sticking to old norms fraught with perils is your thing, keep using var and leave these upstart keywords to listen to their terrible pop music and complain about their parents.

You prefer mutability, even when you don't

Var has the troubling distinction of creating a variable of any type, which can then be changed to a variable of any type later. That's right, the number you declared on line 4 just became a string on line 17 and a boolean on line 109. This type flexibility is a key feature of JavaScript, but it can be avoided. But if you too like to live dangerously, keep using var.

You like leaky scopes

Prior to ES6, JavaScript variables were always defined at the function scope. In a lot of cases, this meant variables were global. JavaScript didn't enforce block-level scopes such as inside a for loop or if block. So a variable declared with var would be hoisted to the top of its function scope. In other words, the variable declaration moved to the top of the current lexical environment with a value of undefined. A common issue arising from hoisting is that such variables are accessible outside the block scope, where the developer may not expect them to be.

A subtler and more difficult to detect bug can happen here as well, variable shadowing. Rarely this may be desired. If that is you, var is your hero.

There must be a better way

If you made it this far, you're probably seconds away from pounding out a fierce comment about how I'm wrong about var. The truth is, no one should be using var in any JavaScript code except for a history lesson. Even then, it should come with a footnote that says something like, "please don't ever do this."

Let and const have been available in every major browser for the last 6 years. This is really, really ancient in frontend years. var isn't just the parent misunderstanding their teen, it's the great grandparent everyone loves but no one invites to the fun parties.

Let retains JavaScript's flexible type system while enabling block-scoping. Const creates a -- you guessed it -- constant variable in block-scope. Const creates a variable that cannot be reassigned, but similar to most other languages, const objects can have their properties mutated. These two alternatives to var should cover every use case you have. Even if you are in the tough spot of needing to support truly archaic browsers, don't use var. Use a tool such as Babel.

So please, please, do not use var.

HyperHTML Up and Running part 1

Paul Thompson — Thu, 06 Jun 2019 21:31:07 +0000

If you haven't heard of hyperHTML, it is worth your time checking into it. As an alternative to the big, popular frameworks, hyper is a blazing fast, small-footprint library that keeps you in the driver seat. HyperHTML centers around making extremely fast DOM updates, and can be integrated into any other framework if you wish (pro-tip: you won't want to).

But seeing is believing, so let's fire up a new project and see how easy it is to get started using hyperHTML. This tutorial will focus on the various ways to set up your development environment using hyperHTML. You'll learn a bit about hyperHTML, webpack, rollup, and modules. We'll assume you have working knowledge of web technologies like HTML, CSS, and of course JavaScript.

Let's begin by setting up our local folder structure.

hyperhtml
|_dist
|_src

We'll be using a few tools from npm throughout this tutorial, so make sure you have nodejs installed.

In your root folder, create a standard, boilerplate index.html file. By far the easiest way to enjoy developing apps with hyperHTML is to use the unpkg CDN. Include this line in the <head> of index.html:

<script src="https://unpkg.com/hyperhtml@latest/min.js"></script>

This gives us access to the hyperHTML variable. Create a <div id="app"> and then before the closing body tag, work magic the likes of which Merlin couldn't fathom:

<script>
    const app = document.querySelector('#app');
    hyperHTML(app)`<h1>Welcome to Hyper</h1>`;   
</script>

Fire up your favorite dev server (for the moment, we're using http-server. Http-server is a simple, zero-config server) and load the page. Tada! HyperHTML everyone. If you aren't sure what's going on here, take a minute to research tagged template literals. We'll be here when you get back.

Let's add a couple more DOM nodes to our "app":

<script>
    const app = document.querySelector('#app'),
          welcome = (name) => `Intrepid traveler, ${name}, welcome!`;    
    hyperHTML(app)`<h1>Welcome to Hyper</h1>
                    <div class="row">
                      <div class="col-sm-6">
                         <p>${welcome("Steve"}</p>
                      </div>
                    </div>`;
</script>

Save, refresh, drop the mic. But can we move this JavaScript madness to another file?

Sure!

Create an app.js file inside the src folder in our project. Move all that JS magic into app.js, then include the file in index.html.

<script src="./src/app.js"></script>

Let's see if it worked; before you save and refresh, kick Steve out and let King Richard the Lionheart come to the party.

<p>${welcome("King Richard the Lionheart"}</p>

This is very, very basic stuff. However, it shows that hyperHTML doesn't need anything more than the library and a server. You could develop loads of apps with just this, but why would you want to?

Let's harness the power of some other tools to make our development lives easier.

Webpack

The first tool we'll look at is webpack. Webpack is a module bundler and loader. The first step is to install webpack with npm, locally to our project. In the root folder, run:

npm i webpack
npm i webpack-cli

Cool.

Since we're using webpack now, we don't need to use a CDN to grab hyperHTML. We can import it. First, install with npm:

npm i hyperhtml

And at the top of app.js, do the import:

import hyperHTML from 'hyperhtml/cjs';

Note: '/cjs' is a module hyperHTML has to work with CommonJS module loaders like Webpack. In a little bit we'll see another module hyper gives us, '/esm'.

We can now remove the script tag from index.html that was pulling in hyperhtml. We're almost ready to let webpack bundle everything. We need to make one more modification to index.html:

Change <script src="./src/app.js" /> to
<script src="dist/bundle.js" />.

Finally, we need to tell webpack where to start bundling our files. While we can run wepack without a config, most projects you'll make will need one, so we're going to set it up now. Create a webpack.config.js file and place it in the project root. Inside this file we need a very simple config:

const path = require('path');

module.exports = {
  entry: './src/app.js',
  output: {
    filename: 'bundle.js',
    path: path.resolve(__dirname, 'dist')
  }
};

And now, the moment you've been waiting for. In your project root on the command line, run npx webpack. Don't worry if you get a couple warnings or errors. You should now be able to find a bundle.js file in your dist folder. Fire up http-server and check it out!

Ready for more wizardry, my young apprentice? With just a few more steps, we can import CSS files. Watch and learn:

Create a styles.css file and put it in the src folder. Include some style rules in it.
In app.js, import "styles.css"
Run npm i style-loader css-loader on the command line.
Add this to your webpack.config.js:

module: {
     rules: [
       {
         test: /\.css$/,
         use: [
           'style-loader',
           'css-loader'
         ]
       }
     ]
  }

Run npx webpack again a see the lightning bolts fly from your fingers! For more in-depth information, see the webpack docs.

Feel free to import/export until your heart is content. With this very quick introduction to hyper + webpack, we've seen that it's easy to get up and running with hyperHTML in a modern webdev environment.

Rollup

Another great module bundler we can use is rollup.js. One reason you might choose rollup for your next project is that it utilizes a technique called tree-shaking. Tree-shaking is a term we use to refer to only bundling code we're actually using. Sometimes we might not want an entire library, just one function from it. Tree-shaking allows this, we're shaking the dead leaves (dead code) from our tree. Webpack offers tree-shaking too, but there's another configuration to set before that happens. Rollup uses tree-shaking automatically.

As you'd expect, our first step is to install rollup in our project.

npm i rollup

You're already familiar with webpack.config.js, so the new file we need, rollup.config.js should come with no surprises.

module.exports = {
  input: 'src/app.js',
  output: {
    file: 'dist/bundle.js',
    format: 'es'
  }
};

Place rollup.config.js in your root.

Now, rollup comes as a basic utility with a lot of features out of the box. However, there are a lot of plugins you can install to enhance your applications even further. This gives you the ability to use only what you need, not more. More on plugins in the next part.

One caveat of rollup is that everything you import needs to be a relative link. So, for example, importing hyperHTML from a node modules as we were when we used webpack won't work with rollup. We can install a plugin to do the trick, rollup-plugin-node-resolve, but since this is a simple project we'll just link to the file we need.

In app.js, change import hyperHTML from 'hyperhtml/cjs' to
import hyperHTML from '../../node_modules/hyperhtml/esm', provided your node_modules directory exists two levels above your /src directory.

For now, remove our import for styles.css.

And now, run rollup from the command line:

rollup -c

If we refresh our webpage, we see everything is working.

I hope you've enjoyed this introductory post about getting an environment up and running with hyperHTML. In the next part, we're going to look at some quality-of-life plugins that will make app development even easier. So stay tuned code wizards!