There's a new kind of coding I call "vibe coding", where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard.

Since then, the concept has caught on and people have been using this technique to build all kinds of things.

There are strong opinions on both sides. It seems to be particularly popular with the “indie hacker” crowd.

Vibe coding, to me, seems like a good way to prototype something in a short period of time. I experimented with it recently, using Cursor and nothing but its agent mode to build a fully functional toast notification web component, complete with notification stacking and nice animations.

I wrote a specification of what I wanted, it built it, and fixed all the bugs that I found. I had a fully working web component with all the bells and whistles in about an hour. I didn't write any code, and just accepted all of Cursor's proposed changes. I was seriously impressed with the final product.

However, without studying and understanding the code that was generated, I don't feel comfortable publishing this component as an npm package. Some might say that taking this step would defeat the purpose of vibe coding. Maybe it does, but I wouldn't want to put work out there with my name on it without a full understanding of what it does.

There have been several incidents I've seen on X where someone built a whole app using the vibe coding approach, and deployed it without fully understanding it or its security vulnerabilities, and the app was hit with malicious attacks.

It's tempting to think you can bootstrap a SaaS in a weekend using the vibe coding approach, but as these folks found out, there's more to building an app than writing a bunch of code. You need to understand the security risks and other issues, and how to mitigate them to make sure you don't end up with a surprise $25,000 Vercel bill.

Personally, I don't think vibe coding is a practical way for a less technical person to build an app. There are too many gaps in knowledge, since the AI can only create what you ask it to. If you're in such a position, you're much better off using a no-code platform, something like Bubble, to build your full stack app.

If you are a technical person, though, I think this is a fine approach to throw together a proof of concept of something you want to build. If you really study and understand the code that's generated (and fix issues that you find!), it might even be a good starting point for a real-world app.

As AI models get more capable of writing code, I think it's only natural that we will start to use them more to build things. I think this is particularly true with front-end code (which has me a little nervous, since that's what I do!).

To answer the question posed by this post's title - no, I don't think vibe coding is the future. It's definitely another tool for the AI toolbox, but in my opinion you're asking for trouble if you use this approach to build and deploy an entire app without putting in the work to understand it, audit it, and make sure there aren't vulnerabilities.

Having said all that - it's damn impressive what I have seen Cursor's agent mode be able to do. Going back to my toast notification web component, I started with an empty directory and Cursor did the rest. If I get around to it, I might learn how it works, clean it up, and maybe I'll publish it one of these days.

Having AI generate some code based on a problem statement is impressive, but I think the real superpower is that it can iterate on the result. Found a bug, or don't like how it turned out? Just have a conversation and watch the code improve.

For another recent project I build, a tool called URL Scrub (check it out!), I used Vercel's v0.dev to design the UI. I have adopted v0 as my UI designer for most of the side projects I build now, but I usually end up still writing the code myself.

In summary - while I am a big proponent of using AI tools as part of my software development workflow, I don't see vibe coding as a good approach for building something production-ready to deploy in the real world. With time, maybe this will change, but as of now, in mid-2025, I think that's where we're at.

It was actually my second book; my first book was called Using Gatsby and Netlify CMS. This was a very niche book that covered one very specific stack (one that has, since, fallen out of favor. Gatsby is not as popular as it once was, and Netlify CMS lives on as Decap CMS). The book was a little too niche and barely sold at all.

Getting published

After publishing Modern CSS on Leanpub, it sold very little. I don't have much of a following online - back in 2020 it was even less than it is now - so I was trying to think of a way to get it in front of a wider audience.

I took a look at different publishers, and decided to look into possibly getting the book published with Apress. I was a first time book author and didn't know anything about the process of getting published; surely, they wouldn't be interested in an unsolicited book proposal from a relative unknown!

Luckily I was wrong. To my surprise, Apress was interested in publishing the book. I would take it down from Leanpub and rework the book for Apress's format. It only took a couple of months to rework the whole book. My first contact with Apress was in June 2020, and the book was out by October. It happened so fast, and it was all done over email!

Becoming an O'Reilly author

After a while, I started getting the itch to write again. My editor from Apress had moved on and now worked at O'Reilly Media. I had a rough idea for a book about the web platform, highlighting the different APIs and technologies available in modern browsers.

I reached out to my old editor and she put me in touch with another editor at O'Reilly to discuss the proposal. Once again, I was pleasantly surprised - they were interested in the book, and thought it would be a good for their "Cookbook" series of books. It was tentatively titled Web Browser API Cookbook, and I started working on it in February 2023.

The writing process with O'Reilly was fantastic. The book was written using Asciidoc, which is sort of like Markdown but with some more bells and whistles. The book content lived in a Git repository and I wrote it using Visual Studio Code.

Getting closer to publication, it was decided to rename the book to just Web API Cookbook. It rolls off the tongue a little better than Web Browser API Cookbook, I must admit. I finished writing almost a year later, in early 2024. Then, in April, the book was published. I couldn't believe that I was now an O'Reilly author and had my own book with an animal on the cover!

What's next

Despite the books not being best sellers, I enjoyed writing them and am very proud of them. I'd love to do another book when the time is right and when there's a good topic. (Got any good ideas for a book about web development?) Or, maybe there will be a second edition of Modern CSS or Web API Cookbook someday. There is certainly enough change in the worlds of CSS and browser APIs to provide enough new content!

Do you have an idea for a book you'd like to write? Pitch it to a publisher - you never know!

If you'd like to check out my books, you can find them on Amazon:

• Web API Cookbook

• Modern CSS

You can query based on the width of the device, its aspect ratio, orientation, and more. These all allow you to fine-tune your layout for the device being used.

You might not know that there are other media queries available that let you tailor your site or app based on the user's preferences rather than their device size and orientation.

User preference media queries

There are several media queries that deal with user preferences. You can use these to fine tune your app's experience for the user.

Automatic dark mode with prefers-color-scheme

Dark mode is everywhere these days. It seems like every site now has the sun/moon toggle button to switch between light mode and dark mode. You can take this one step further and use the prefers-color-scheme media query to automatically determine if the user's device is using a light or dark color mode.

Here's how it works: Define your CSS styles for light mode like you normally would. Then add the media query prefers-color-scheme: dark. In there, add CSS rules overriding your light mode colors:

.content {
  background-color: white;
  color: black;
}

@media (prefers-color-scheme: dark) {
  .content {
    background-color: black;
    color: white;
  }
}

Tip: Create themes with CSS variables

To make life a little easier, you can define all your colors in a theme, a set of CSS variables. Then inside your prefers-color-scheme: dark block, you only need to redefine the variables instead of re-adding your CSS selectors and rules:

:root {
  --main-background: white;
  --text-color: black;
}

.content {
  background-color: var(--main-background);
  color: var(--text-color);
}

@media (prefers-color-scheme: dark) {
  --main-background: black;
  --text-color: white;
}

Tone down animations with prefers-reduced-motion

Animations can enhance your app's experience, but animations may be difficult for users with vision or vestibular problems. To assist these users, some devices and operating systems have an option in the user preferences to reduce motion.

You can use the prefers-reduced-motion media query to detect when such an option is enabled for the user's device. You can then use alternate animations that are less intense (or turn them off altogether).

Here's an example of using prefers-reduced-motion to turn off an animation.

.content {
  animation: my-awesome-animation 250ms ease-in-out;
}

@media (prefers-reduced-motion: reduce) {
  .content {
    animation: none;
  }
}

One thing to note: If you turn off animations like this, make sure you don't have any code that relies on an animationend event. When you set animation to none, as shown above, this event will never be fired.

Keep in mind that you don't have to turn off animations when prefers-reduced-motion: reduce matches! Suppose you have a fancy reveal animation where the element bounces into view. When the user wants reduced motion, you could change this so it's a simple fade-in animation.

Adaptive contrast with prefers-contrast

Some users with vision difficulties may have increased contrast enabled on their device. You can handle such situations with the prefers-contrast media query.

If this media query matches, you can adjust your contrast to make things easier to see for these users.

.box {
  border: 1px solid gray;
}

@media (prefers-contrast: more) {
  .box {
    /* Make the border stand out more against the background */
    border: 2px solid black;
  }
}

Checking media queries with JavaScript

Suppose you're animating with JavaScript - for example, maybe you're using the Web Animations API. Since these animations aren't defined in the CSS, you can't turn them off with the prefers-reduced-motion media query.

Or can you?

Yes! You can use the window.matchMedia method to evaluate a media query from JavaScript. The media query is passed as an argument, and the method returns something called a MediaQueryList.

This object has a matches property, which is a boolean indicating whether or not this media query currently matches. Based on the value, you can decide whether or not to animate.

Here's a simple example showing how window.matchMedia can be used to conditionally call animate on a DOM element:

// Check to see if we should animate
const query = window.matchMedia('(prefers-reduced-motion: reduce)');
if (!query.matches) {
  someElement.animate(...);
}

Reacting to changes

A MediaQueryList even has a change event which fires if conditions change and the media query no longer applies.

Suppose you have some JavaScript code that you only want to run for large displays. If the user's screen size is small, you want to skip this code. You can do this by calling window.matchMedia using a max-width query or something similar.

Suppose that later, the user resizes the window, and now you want to run the large screen specific JavaScript code. Just listen for the MediaQueryList's change event, and you can check the event's matches property to see what the new value is.

Summary

These media queries can help you to better personalize your user's experience within your website or app. You can automatically apply a dark color scheme, and even fine-tune your animations and contrast depending on user preferences. They also help with accessibility, which is always a win.

It's still in an experimental stage, but you can also keep an eye out for the prefers-reduced-data query which will indicate whether the user's device has a requirement that is uses less data. This can be used to provide alternate content that uses less data. For example, you could skip non-essential images (or use lower-resolution versions).

To use git bisect, you’ll need to find a commit where the bug exists (a “bad” commit), and you’ll also need to find an older commit where the bug doesn’t exist (a “good” commit).

Once you identify these two commits, git bisect will guide you through a binary search of the commit history.

This can save you considerable time if there are a lot of commits between the bad commit and the good commit. At each step of the binary search, you perform a test to see if the bug exists. If the bug exists at this commit, you tell git bisect that this is a bad commit. If the bug doesn’t exist, you indicate that it’s a good commit.

Depending on whether the commit is bad or good, git bisect picks another middle point between the commit you identified and the bad commit. The process continues until Git has identified the first bad commit which introduced the bug.

Example bisect

Let’s walk through a short git bisect and see a visualization of each step.

First, to start the process, run git bisect start:

% git bisect start
status: waiting for both good and bad commits

Make sure you’ve checked out a commit or branch that exhibits the bug you’re investigating, and run git bisect bad:

% git bisect bad
status: waiting for good commit(s), bad commit known

Next, you’ll need to check out a known good commit and run git bisect good:

% git checkout <commit ID>
% git bisect good
Bisecting: X revisions left to test after this (roughly Y steps)

At this point, you’ve identified a good commit and a bad commit, and Git is pointing to a commit in the middle for you to check.

Run or test your code, and see if the bug exists here. If you can’t reproduce the bug, mark this as a good commit by running git bisect good. Now Git knows that the commits between the first good commit and this one are all good:

Now, Git will continue the binary search. It will pick the commit in the middle between the good and bad commits, and check it out for you to check:

Suppose that here, you are able to reproduce the bug. Mark this as a bad commit by running git bisect bad. Git will mark this commit as bad:

It will pick the next commit between the good and bad commits, and continue binary searching:

Let’s assume that this is a good commit, and you can’t reproduce the bug. Just as you did before, run git bisect good to mark this as a good commit:

At this point, Git has enough information to tell you the first bad commit.

Now you can look at the changes from that commit and, hopefully, determine what change caused the bug.

When you’re done, run git bisect reset to exit bisect mode and return to the commit you were at when you started bisecting.

Mixing up good and bad commits

git bisect can only work if the good commit is an ancestor of a bad commit. If you mark a commit as good, then check out an earlier commit and mark it as bad, you’ll get an error:

Some good revs are not ancestors of the bad rev.
git bisect cannot work properly in this case.
Maybe you mistook good and bad revs?

Automating git bisect

It might be tedious to manually test your code at each step of a git bisect, but you might be able to automate it. You can use git bisect run and give it the name of a script or other command to run. Git will check the exit code of the command at each step.

If the exit code is 0, it’s treated as a good commit. If you want the commit to be treated as a bad commit, your command should have an exit code between 1 and 127. However, there is one exception to this. Git reserves the exit code 125 to have a special meaning. If, for some reason, this commit can’t be tested, your command can return an exit code of 125 and it will skip that commit.

Summary

The git bisect command can help you quickly narrow down which commit introduced a bug or other undesirable behavior. It does this by performing a binary search on the commit history between a known good commit and a known bad commit.

If you have automated tests, you can even use git bisect run to automatically control the process of testing and identifying good and bad commits.

Using the Ollama tool, you can download and run models locally. In this post, I’ll guide you through the steps to run the Code Llama model using Ollama, and integrate it into Visual Studio Code.

Code Llama is an LLM from Meta that is focused on generating and talking about code. It’s based on their Llama 2 model, and supports many different languages.

Installing Ollama and the Code Llama model

Your first step is to install Ollama. Go over to https://ollama.com where you can download and install it. Once Ollama is up and running, you should have a new terminal command, ollama. To see if it’s installed correctly, open a terminal and run:

ollama -v

This should print the Ollama version. If you see this, then you’re good to go! Next, download the Code Llama model by running this command:

ollama pull codellama

This may take a while, depending on your Internet connection. The 7b version of Code Llama is 3.8 gigabytes. Go get a cup of coffee, tea, or your favorite beverage while Ollama downloads this model.

Setting up CodeGPT

CodeGPT has a Visual Studio Code extension where you can interact with models directly in the editor. In VS Code, go to the Extensions tab and search for “codegpt”. You’ll see several results, make sure to get the one with the blue check mark:

Once CodeGPT is installed, you should see a new CodeGPT icon in the editor’s sidebar. When you click on this, you’ll be taken to the CodeGPT interface. Click the dropdown menu at the top of this panel and select Ollama as the provider, and codellama as the model:

Once you’re up and running, you will see a text area at the bottom of this panel to start chatting. Try entering a prompt such as “Generate the code for a simple React component”.

Code Llama will start processing your request. Keep in mind that running a model locally is not as powerful, or fast, as an online service like Meta AI or ChatGPT. After a few seconds, you should have a result in the chat window.

Setting up completion

You can also use CodeGPT to suggest code completion, like GitHub Copilot and similar tools do. To set this up, in the CodeGPT Chat window, click the Menu button at the top left part of the screen. A menu will slide out with several options.

Select “Autocomplete” to set up code completion.

Code Llama has a code variation that you can use for code completion. It is a separate model, so you’ll have to make another large download. Select the codellama:code model from the “AI Model” dropdown:

Next, make sure to click the toggle switch to enable completion:

Now, as you type in your editor, Code Llama will make suggestions for you. For example, here it is filling in the PropTypes for a Greeter component:

If you like a suggestion, you can press the Tab key to accept it:

Have fun!

That’s really all there is to it. You now have AI chat and code completion integrated in Visual Studio Code!

An array is a collection or list of values. It could hold just strings:

const names = ['Luke', 'Leia', 'Han'];

Or a mix of different types:

const stuff = ['Hello', 42, true, 3.14];

Arrays are cool because you can iterate over them with a for loop or one of the array utility functions like forEach, map, or reduce.

What does length really mean?

Let's start with a normal, everyday case. If you have an array, you can check its length property to see how many items are in the array:

const values = ['one', 'two', 'three'];
console.log(values.length);

The console.log above will print 3, because there are three elements in the array.

What happens if you do this, though:

const names = [];
names[10] = 'Joe';
console.log(names.length);

There's only one name in this array, but the console.log will print 11.

Here's another one. You probably won't ever see this in real-world code, but it helps illustrate the point:

const names = [];
names[10] = 'Joe';

// You'd never do this in real life
names[12.5] = 'Bob';

console.log(names.length);

What do you think will be printed now? If you guessed 11 again, you're correct. By now you can see that the length of an array actually does not indicate the number of values in the array.

If you check the value at names[12.5], you'll see that Bob is, in fact, there:

console.log(names[12.5]); // 'Bob'

So what does length really mean?

The answer to this mystery lies in the ECMAScript Language Specification. It says:

The "length" property of an Array instance is a data property whose value is always numerically greater than the name of every configurable own property whose name is an array index.

So what constitutes an array index? In short, the specification says that it's an integer value.

That explains why, in the second example, setting names[12.5] to Bob did not affect the length property. 12.5 is not an integer value!

Array-like objects

JavaScript has a notion of array-like objects. These are objects that have properties indexed like an array, but aren't actually arrays. Array-like objects also have a length property.

Here's a contrived example of an array-like object:

const names = {
    0: 'Joe',
    1: 'Bob',
    2: 'Bill',
    length: 3 // don't forget the length!
};

You can use an array-like object in a for loop:

for (let i = 0; i < names.length; i++) {
  console.log(names[i]);
}

That's cool, but you can do more. Because this object fulfills the contract of an array-like object, you can use array methods like map with a little JavaScript trickery:

const uppercaseNames = Array.prototype.map.call(names, name => {
    name.toUpperCase());
});

In the above example, uppercaseNames will be an array (an actual array!) of the names uppercased: ['JOE', 'BOB', 'BILL'].

This isn't too useful for a weird array-like object you constructed by hand, but it can come in handy when working with the DOM.

For example, consider the document.querySelectorAll method. You might think this returns an array, but it actually returns a NodeList. This is an array-like object. It even has a forEach method, but it's missing other array methods like map or find.

You could use find on a NodeList to search for a node that meets a certain condition. Or, maybe you want to use map to transform the nodes into an array of their attribute values.

The incredible shrinking array

I'll leave you with one last array trick. Did you know that you can change an array's length property? That's right, the property is writable.

If you set the length to a smaller value, any remaining elements are removed from the array:

const names = ['Joe', 'Bob', 'Bill'];
names.length = 1;

console.log(names); // ['Joe']
console.log(names[1]); // undefined
console.log(names[2]); // undefined

Not only does this change the length of the array, but it gets rid of the extra elements, too.

Conclusion

If you've been working with JavaScript for any length of time, this array weirdness shouldn't surprise you. And if you are new to JavaScript (welcome!) consider this a sign of interesting things to come.

I hope you found this array trivia to be interesting, and maybe even a little useful!

1. Traditional CS education

2. Bootcamp

3. Completely self-taught

I have seen people become very successful taking any of these 3 paths. It's clear that a CS degree is no longer necessary to get a good tech job. Does that mean they're no longer worth it?

What I learned in my CS program

From 2000 to 2004, I went to UMass Lowell. The curriculum started with the class Computing 1, which was a few hundred freshmen in a big lecture hall learning C programming. Computing 2 moved to object-oriented C++, and later courses covered databases, operating systems, and Java.

At my current position, I use none of the above in my day-to-day work. Today I work mostly with JavaScript, which I didn't learn at all during my college years. Every skill I use today was self-taught.

However, data structures and algorithms, the fundamentals of computer science, have stuck with me and helped me to solve problems all the time. Even these, of course, can be learned outside of a college environment.

Back to the question

So, back to the question: are CS degrees still relevant? Well, I would say while they are in no way a prerequisite to being successful in this field, there is still a lot of benefit.

Of the three paths above, most people I have worked with (and myself as well) have followed a hybrid path combining two or more. In my case, it's a hybrid of a CS foundation with self-taught knowledge.

I have also worked with talented engineers who started with a bootcamp and are still on their learning journey, who are progressing all the time.

The most critical skill

Whatever path you choose for your adventure, the most critical skill to learn is how to learn effectively. This isn't the same for everyone - what helps me learn effectively may differ from what works for you.

The other important things to consider are what to learn and why. Don't just learn programming languages for the sake of learning more. Over the past 20 years, I have learned:

• Python

• Ruby

• PHP

• C

• C++

• Elixir

• Java

• JavaScript

• TypeScript

Of those, I only really know the last three today. I learned those other languages for the sake of learning them, thinking it would help me get ahead. But if you don't have a good reason for learning something, you won't use that knowledge and like an old cache entry, you'll lose it.

I have, pretty much, forgotten everything about Python, Ruby, PHP, and Elixir. C and C++ are a distant memory, and since I went to a JavaScript-only job in 2015, I'm starting to forget Java as well.

Conclusion

For me, a CS degree was a good path. Of course, this was in the early 2000s at a state school, at a time when college was much less expensive than it is now.

The bottom line is that you can follow any of the three paths, or a combination of them, to achieve success in a software development career.

So, yes, a CS degree is still relevant, but in my view it's not a must-have anymore.

There are many aspects of accessibility that you need to keep in mind, one of which is color contrast. Proper color contrast not only looks good, but it's critical for users with low vision.

Specifically, you need to make sure that there is enough contrast between your background color and text color. If the contrast is too low, the text is not easily distinguishable from the background and it's hard to read. Even for users without disabilities, this is problematic as it can lead to eye strain.

The Web Content Accessibility Guidelines (WCAG) provides some guidance on contrast ratios.

What is a contrast ratio?

The term "contrast ratio" refers to the difference, or ratio, in brightness between the background and text colors.

The WCAG guidelines formally define the contrast ratio as:

(L1 + 0.05) / (L2 + 0.05), where

• L1 is the relative luminance of the lighter of the colors, and

• L2 is the relative luminance of the darker of the colors.

How much contrast is enough?

The contrast ratios required by WCAG differ slightly depending on the size of the text.

Large text

Large text size is defined as follows:

• For bold text, 14 points or larger

• For non-bold text, 18 points or larger

Large text has a more relaxed contrast requirement since larger text is easier to read. For large text, the minimum contrast ratio is 3:1. This minimum is known as Level AA.

There is also a notion of enhanced contrast, known as Level AAA. For large text, AAA requires a minimum ratio of 4.5:1.

Normal text

Since smaller text is not as easy to read, it has stricter contrast requirements.

For Level AA, text must have a minimum contrast ratio of 4.5:1. The enhanced Level AAA contrast is a minimum of 7:1.

Non-text elements

Non-text elements, such as icons, have a minimum contrast ratio of 3:1 for Level AA.

Level AAA does not define a minimum contrast for non-text elements.

The following table summarizes the different minimum contrast ratios:

Checking contrast

The easiest way to check your color contrast is to use a tool. WebAIM has an excellent [Contrast Checker](https://webaim.org/resources/contrastchecker/). You can enter your foreground and background colors, and it will show you if the contrast meets AA and AAA standards.

The Chrome developer tools will also show the contrast ratio when inspecting an element:

Visualizing contrast

Here are a few examples of different color contrast ratios. Screenshots are courtesy of the WebAIM Contrast Checker.

1.4:1 (does not meet minimum standard):

4.51:1 (meets level AA standard):

7:1 (meets level AAA standard):

Conclusion

Using sufficient color contrast is good for everyone, but critical for accessibility. Of course, color alone is not enough to make an accessible experience. For other resources to make your UI accessible, check out:

• WCAG 2 Overview [w3.org]

• WebAIM [webaim.org]

You can create a chain of Promises by returning new Promises from a then handler. Here's a simple example that chains 3 promises together:

Promise.resolve(1)
    .then(id => {
        console.log(`Success: ${id}`);
        return Promise.resolve(2);
    }).then(id => {
        console.log(`Success: ${id}`);
        return Promise.resolve(3);
    }).then(id => {
        console.log(`Success: ${id}. Done!`);
    });

The output of this chain will be:

Success: 1
Success: 2
Success: 3. Done!

To handle any errors that may occur in the chain, you can add a call to catch at the end of the chain. If any of the Promises are rejected, this catch handler will run, and the rest of the chain is skipped.

Promise.resolve(1)
    .then(id => {
        console.log(`Success: ${id}`);
        return Promise.reject(2);
    }).then(id => {
        console.log(`Success: ${id}`);
        return Promise.resolve(3);
    }).then(id => {
        console.log(`Success: ${id}. Done!`);
    }).catch(id => {
        console.log(`Error: ${id}`);
    });

The output of this chain will be:

Success: 1
Error: 2

The weird parts

If you add more then calls after the catch, they will run!

Promise.resolve(1)
    .then(id => {
        console.log(`Success: ${id}`);
        return Promise.reject(2);
    }).then(id => {
        console.log(`Success: ${id}`);
        return Promise.resolve(3);
    }).then(id => {
        console.log(`Success: ${id}. Done!`);
    }).catch(id => {
        console.log(`Error: ${id}`);
    }).then(() => {
        console.log('Another then!');
    });

You'll get this output:

Success: 1
Error: 2
Another then!

Why does the chain continue after the catch? As it turns out, you can return another Promise from a catch handler. Here, the catch handler just prints to the console. The handler function, then, returns undefined. This actually returns a new Promise, fulfilled with the value undefined. You can verify this by adding the id argument to the last then:

Promise.resolve(1)
    .then(id => {
        console.log(`Success: ${id}`);
        return Promise.reject(2);
    }).then(id => {
        console.log(`Success: ${id}`);
        return Promise.resolve(3);
    }).then(id => {
        console.log(`Success: ${id}. Done!`);
    }).catch(id => {
        console.log(`Error: ${id}`);
    }).then(id => {
        console.log(`Success: ${id}`);
    });

And the output:

Success: 1
Error: 2
Success: undefined

Re-rejecting

This is a contrived scenario, but consider a function that does some asynchronous work and returns a Promise. Maybe it's a function that wraps the Fetch API, to return the JSON content. It has a catch for centralized request error logging:

function getJSON(url) {
    return fetch(url)
        .then(response => response.json())
        .catch(error => console.log('Fetch error:', error));
}

What happens if there's an error with the Fetch call? Before reading this post, the result might surprise you!

getJSON('http://invalid.fake')
    .then(data => console.log('Success!', data))
    .catch(() => console.log('Error!'));

Logically you might expect that Error! will be printed. But what actually happens is that getJSON logs the Fetch error but returns a fulfilled Promise. Your then handler will be executed and print:

Success! undefined

In order to get the result you want, the catch handler inside getJSON has to return a rejected Promise. You have to "re-reject" it:

function getJSON(url) {
    return fetch(url)
        .then(response => response.json())
        .catch(error => {
            console.log('Fetch error:', error);
            return Promise.reject(error);
        });
}

You could also throw the error, which will implicitly return a rejected Promise as well:

function getJSON(url) {
    return fetch(url)
        .then(response => response.json())
        .catch(error => {
            console.log('Fetch error:', error);
            throw error;
        });
}

Either way, now when you call getJSON and an error occurs, it will correctly return a rejected Promise.

Summary

Promise chains actually work a lot like try/catch blocks in JavaScript. If an exception is thrown within a try block, it jumps right to the catch block and skips the rest of the try - just like how catch() skips the rest of the Promise chain.

Also, if you have a function that catches an exception, you'll need to re-throw it if you want it to propagate back up to the calling function.

However, not all properties of an object are serializable. Functions, regular expressions, and Date objects are all examples of values that can't be translated to a string and back again.

Let's create a user object containing a Date property.

const user = {
    username: 'admin',
    lastLogin: new Date()
};

When we stringify this object, the Date becomes an ISO date string:

{
    "username": "admin",
    "lastLogin": "2023-04-27T01:46:16.100Z"
}

This is a good string representation. The problem is when we pass this string to JSON.parse, the resulting object's lastLogin property will still be a string - it won't be turned back into a Date.

Adding a reviver function

We can provide customized deserialization logic with a reviver function. This is a function that's called during the parsing process. The reviver function takes two arguments: a key and a value. It's called for each key/value pair in the object. For each invocation of the reviver, the value returned for a given key is used as the final value in the parsed object.

Finally, the reviver function is then called with an empty key, and the parsed object as its value. This allows you to make any final changes to the object before returning it from JSON.parse.

We can write a reviver function to convert this JSON string back to the original user object, Date and all.

function reviver(key, value) {
    if (key === 'lastLogin') {
        // pass the date string to the Date constructor
        return new Date(value);
    }
}

const parsed = JSON.parse(jsonString, reviver);

Adding a replacer function

What if we want to store the lastLogin date in a different format? Maybe instead of a human readable ISO string, we want to use a more compact timestamp format.

We can customize JSON.stringify by writing a replacer function. This function is similar to the reviver function for JSON.parse. It is called first with the object itself, then is called again for each key/value pair.

By the time it is called with the key/value pairs, the stringification of these properties has already been done. However, the original object can still be accessed via the this context (as long as it's not an arrow function!).

function replacer(key, value) {
    if (key === 'lastLogin') {
        // value is already a string here, but we can access the 
        // original property
        return this.lastLogin.getTime();
    }

    return value;
}

const json = JSON.stringify(user, replacer);

Now when we call JSON.stringify on the user, the lastLogin field will be a numeric timestamp.

Alternative: use a toJSON function

If an object being stringified has a toJSON function, the stringification is done on the return value of that function rather than the original object.

With our user object, this might look like:

function createUser(name) {
    return {
        name,
        lastLogin: new Date(),
        toJSON() {
            return {
                name: this.name,
                lastLogin: this.lastLogin.getTime()
            }  
        }
    }
}

JSON.stringify(createUser('admin'));

When we call JSON.stringify our toJSON function is called, and the return value is used for stringification.

Using replacer and reviver functions gives us greater control over the serialization of objects to JSON, and lets us persist more complex objects in local storage.

I thought it might be fun to explore some of the ways we can implement this new method using currently available language features. Of course, there is already a package on npm that polyfills this function, so this is mostly an exercise for learning purposes only.

Reversing a copy of the array

The most straightforward way to do this is make a copy of the array, and then call reverse on it. This has the end result of not mutating the original array, but it does mutate the copy, so this is a bit of a cheat.

Using slice

Array.prototype.slice will create a shallow copy of the array. This means that the references to each array element is copied into a new array. Reversing this copy mutates the new array by reordering items, but won't affect the ordering of the original array, or modify any of its elements.

const reversed = originalArray.slice().reverse();

Using array spread

We can use the spread syntax to create a copy of the array, then reverse it.

This is essentially doing the same thing as the slice approach. Make sure the .reverse call is outside the brackets, otherwise we'll be mutating the array then copying it.

// ✅ Copies the array, then mutates the copy
const reversed = [...originalArray].reverse();

// ❌ Mutates the original array, then copies
const reversed = [...originalArray.reverse()];

Using map

We can build the reversed array by mapping each element to the corresponding element at the other end of the array:

• element 0 becomes element n - 1
• element 1 becomes element n - 2
• etc.

The new element is calculated by subtracting the current index from the last index. For this we can call map on the array:

const reversed = originalArray.map((el, index) => 
  originalArray[originalArray.length - 1 - index]
);

Building the array in reverse order

This one, again, is a partial cheat if we want to avoid mutation since we are mutating the new array on each turn of the loop. In most cases, this is probably acceptable as long as the original array remains unchanged.

const reversed = [];
originalArray.forEach(el => reversed.unshift(el));

Using reduce

If we want to be purists and not mutate anything, we can use reduce to reverse the array. For small arrays it probably doesn't matter, but keep in mind that we are going to increase memory usage, since a new array is created each time through.

This is a good exercise for understanding how reduce works but probably not an ideal version to use in a production app.

const reversed = originalArray.reduce((result, el) => [el, ...result], []);

We start with an empty array. For each element in the array, we create a new array with that element at the beginning, and spread the previous result, creating a new array. When the loop is complete, we'll have the new reversed array.

Which to use?

For smaller arrays, analyzing differences between these approaches is probably an exercise in premature optimization. In such cases I usually prefer a more readable approach, such as the spread syntax:

const reversed = [...originalArray].reverse();

Fast forward to today, living in JavaScript Land, we now have const declarations. I ask the same question to JavaScript candidates and often get the same sorts of answers.

On the surface, these answers are more or less correct, but when I would ask follow-up questions about what exactly they meant by "constant" or "can't be changed", I was sometimes surprised by the answers I received.

This appears to be a question that can sometimes trip up beginners. Let's take a deeper look.

The const keyword

Back in the dark ages, we had var for declaring variables and that was it! ES2015 gave us two new tools: const and let.

We use const like this:

const name = 'Joe';

I have just declared name, which is a reference to the string 'Joe'. If I try to assign a new value to name, I get an error:

name = 'Liz'; // TypeError: Assignment to constant variable.

Great, so this is a constant value! I can't change the name assigned to name. This much, I think, is pretty clear.

What about an array?

A string is a primitive value. What if I use const for, say, an array?

const foods = ['apple', 'banana', 'pear'];

Indeed, I can't set a new array:

foods = ['bacon', 'chicken', 'turkey']; // TypeError: Assignment to constant variable.

I want to take banana out of my array. I might try to do that with Array.prototype.filter, but I run into the same problem:

foods = foods.filter(food => food !== 'banana'); // TypeError: Assignment to constant variable.

That won't work because foods is declared with const. Of course, this will work fine if I assign the result of foods.filter to another variable name, but let's pretend that for whatever reason the array referenced by foods has to have the banana-less array.

Instead of filtering, a value can also be removed from an array with Array.prototype.splice. But since foods is a constant that can't be changed, this will fail as well, right?

foods.splice(foods.indexOf('banana'), 1); // No error!
console.log(foods); // ['apple', 'pear']

This works! The array referenced by foods no longer contains banana. Why did this work if we used const?

The reference is the constant!

As it turns out, the constant is the reference itself, not the value it's pointing to. We can do anything we want to the foods array as long as we don't try to reassign a new value to foods.

So you see, explaining const by saying "it's a constant value" or "it can't be changed" is only true from a certain point of view.

Immutable data

What if we really, truly, want to lock down the foods array so we can't modify it? The reason we can still get away with this is because functions like Array.prototype.splice mutate the thing. This is just a fancy way of saying we are modifying its internal state.

Some values, like strings, are immutable, so for a string, our simplified explanation of const is accurate. But for objects and arrays, we still have a mutation escape hatch.

It's actually easy to achieve immutability for our humble array of foods. We can freeze it!

const foods = ['apple', 'banana', 'pear']; // At this point we can still mutate the array
Object.freeze(foods); // Not anymore!

Object.freeze essentially locks down our array. We can't do anything to it now:

foods.splice(foods.indexOf('banana'), 1); // TypeError: Cannot delete property '2' of [object Array]

foods.push('bacon'); // TypeError: Cannot add property 3, object is not extensible

Now our foods array is untouchable. Like before, we can still filter it as long as we assign it to a new name. Interestingly, the new filtered array is no longer frozen:

const noBananas = foods.filter(food => food !== 'banana');
noBananas.push('bacon'); // No error!
console.log(noBananas); // ['apple', 'pear', 'bacon'];

A note on Object.freeze

You may notice that the array threw exceptions when trying to add or remove elements after it was frozen. As we will see soon, this does not happen with other objects (unless in strict mode). When not running in strict mode, the mutation will fail silently.

Freezing objects

Let's take one more example, an array of users, and freeze it.

const users = [
  { username: 'obiwan', email: 'kenobi@gmail.com' },
  { username: 'yoda', email: 'yoda@coruscant.com' }
];

Object.freeze(users);

// This will fail with TypeError: Cannot add property 2, object is not extensible
users.push({ username: 'chewbacca', email: 'chewie@kashyykmail.com' });

To protect his identity, let's change Obi-Wan's username to ben (the Empire will surely think the last name is a coincidence):

users[0].username = 'ben';
console.log(users[0]); // { username: 'ben', email: 'kenobi@gmail.com' }

No error was thrown, and when we check the user object, it was updated (so it did not fail silently as we discussed above!)

What happened? Isn't the array frozen? Indeed it is, the individual items in the array are not. To achieve this, we need to freeze every item in the array:

  const users = [
    { username: 'obiwan', email: 'kenobi@gmail.com' },
    { username: 'yoda', email: 'yoda@coruscant.com' }
  ];

Object.freeze(users);
users.forEach(user => Object.freeze(user));

// Change Obi-Wan's name.
users[0].username = 'ben';

// No error, let's check the object
console.log(users[0]); // { username: 'obiwan', email: 'kenobi@gmail.com' }

Now that we've frozen each object in the array, we get the desired outcome. Array items can't be added, removed, or modified.

If we ran the same above code in strict mode, it would fail with an error:

TypeError: Cannot assign to read only property 'username' of object '#<Object>'

Recursively freezing objects

At any given level, Object.freeze will only freeze the top-level properties. For deeply nested objects, you will need to traverse all the way down and freeze at each level.

Fortunately, there is a simple package called deep-freeze that will do this in a single function call:

  import deepFreeze from 'deep-freeze';

const users = [
  { username: 'obiwan', email: 'kenobi@gmail.com' },
  { username: 'yoda', email: 'yoda@coruscant.com' }
];

deepFreeze(users);

This will freeze the array as well as all the objects in it. If those objects had nested object properties, those would be frozen as well. Since we are in an ES module (we're using import), this automatically puts us in strict mode, so attempting to change Obi-Wan's username will throw an error.

Summary

• const marks a reference as constant; it cannot be reassigned. However, the object pointed to by the const can be mutated.
• To make an object truly unmodifiable, you will need to freeze it.
• Object.freeze does not recurse into nested properties, but the deep-freeze package will.

Now you can crush this question on your next job interview!

Consider this getUserDetails function:

function getUserDetails(userId) {
  return new Promise((resolve, reject) => {
    fetch(`/users/${userId}/details`)
      .then(response => response.json())
      .then(data => resolve(data));
      .catch(error => reject(error));
  });
}

This function returns a Promise that will be resolved when the fetch call is complete and the JSON response is received.

We make the fetch call and extract the JSON in the first then handler. response.json() also returns a Promise, so we call then on that too. Once we have the JSON result, we can resolve our returned Promise.

If there is an error, we reject our returned Promise.

Here's a somewhat rough analogy, but bear with me here. Suppose you want to buy an item listed on eBay. The above code is sort of like if you purchased the item, and the seller shipped it to eBay. Then, once eBay received it, they shipped it to you. Sounds overly complicated, right?

Client code that calls getUserDetails looks like this:

getUserDetails(userId).then(details => {
  doSomethingWith(details);
});

We are calling then on the outer Promise that was returned from getUserDetails.

We can do better! If the asynchronous thing you are doing already returns a Promise, as fetch does, you don't need to wrap it in your own Promise.

The above function can be written much more simply:

function getUserDetails(userId) {
  return fetch(`/users/${userId}/details`)
    .then(response => response.json());
}

This function has the same net result! In both listings above, getUserDetails returns a Promise that resolves to the user details object.

To return to the eBay analogy: This approach is how eBay actually works: you purchase the item through eBay, eBay tells the seller, and the seller ships directly to you.

In the first example, we are creating our own Promise which wraps the asynchronous operation. The difference with the second example is that we are just returning the Promise that response.json() gives us.

When would I want to create my own Promise?

There are some cases where rolling your own Promise is unavoidable, for example when working with a callback or event based API.

Event based APIs

Let's make a quick and dirty image loader! This function will take an image URL and return an img element, but not until the image has loaded.

function loadImage(url) {
  return new Promise((resolve, reject) => {
    const image = document.createElement('img');

    image.addEventListener('load', () => {
      resolve(image);
    });

    image.addEventListener('error', error => {
      reject(error);
    });

    image.src = url;
  });
}

Because the image element doesn't provide a Promise itself, in this case we have to roll our own. Depending on which event listener is fired, we either resolve the Promise with the now fully loaded image, or reject it with the error encountered while loading.

This is easy to use:

loadImage('/logo.png').then(image => container.appendChild(image));

Callback based APIs

Some older APIs are still callback based. You might want to make a "promisified" version of such an API. For this, you will need to create a Promise.

Consider this simplified example of an API. It follows the typical Node.js callback pattern - it takes two callback function arguments. The first will be called if there is an error, and the second will be called on success. We use such an API like this:

db.findItem(123, error => {
  console.log('oops, an error:', error);
}, data => {
  console.log('got data:', data);
});

Callbacks can be a little painful to work with, so we can wrap this API with a Promise:

function findItemPromise(recordId) {
  return new Promise((resolve, reject) => {
    db.findItem(recordId, error => reject(error), data => resolve(data));
  });
}

This can actually be simplified a bit more. Since the resolve and reject handlers take a single argument, which matches the arguments of the error and data callbacks, we can just specify those functions themselves as the callbacks:

function findItemPromise(recordId) {
    return new Promise((resolve, reject) => {
      db.findItem(recordId, reject, resolve);
    });
}

Now we can use the findItemPromise API:

findItemPromise(recordId)
  .then(data => console.log('got data:', data))
  .catch(error => console.log('oops, an error:', error));

In fact, if you are working with Node.js, you don't need to do this wrapping yourself. The Node.js API includes a promisify utility function that does exactly this!

Summary

• If the async API you are working with already returns a Promise, you most likely don't need to wrap it in your own new Promise. Instead, you can just utilize the existing Promise.
• For event and callback based APIs, you will need to create your own Promise which wraps the API call, and calls the resolve and reject handlers accordingly.
• Node.js has a promisify utility function that will convert any callback-based function (that follows the Node convention of (error, success) callbacks) into a Promise based one.

What is a module?

A module is some piece of functionality that is nicely encapsulated. A module defines a public API that is accessible from any code that uses the module. In addition, the module has some private, internal state that is not accessible from outside of the module.

This means that we just need to interact with the module's public API. We don't need to know about how the module is implemented under the hood.

Modules can also have dependencies on other modules.

The example module

For each module type, we'll look at the same module implemented in different ways. This is, simply, a counter module. The public API consists of three functions:

• increment: Increments the counter
• decrement: Decrements the counter
• getValue: Gets the counter's current value

Note that the counter itself is not publicly accessible. It can only be manipulated by calling the increment and decrement functions.

Module types

Let's take a look now at the different types of modules used in JavaScript applications.

The "Revealing Module" pattern

This is the oldest module type in use today. JavaScript had no language support for modules, so this pattern relies on a function's scope to provide the private state only accessible from inside the module. These types of modules are typically initialized with an immediately invoked function expression (IIFE). This is, essentially, a function that immediately calls itself.

The return value of the IIFE call is usually assigned to a variable, or a global variable on the browser's window object. Inside the IIFE call, the module's internals are set up, and an object is returned containing the module's public API.

Here's what the counter module looks like as a revealing module:

const Counter = (function() {
  let value = 0;

  return {
    increment() {
      value++;
    },

    decrement() {
      value--;
    },

    getValue() {
      return value;
    }
  }
})();

The counter variable itself is defined inside the function, therefore it is not accessible outside of the module. We return an object containing the three functions of the public API.

We would use this module as follows:

Counter.increment();
Counter.increment();
console.log(Counter.getValue());

Asynchronous Module Definition (AMD) modules

AMD modules are most commonly used with tools such as RequireJS. Its name comes from the fact that modules are loaded asynchronously.

An AMD module is defined with a call to a function called define. The first argument to define is an array of other module names that the module depends on. The second is a function that takes the dependencies as arguments. The return value of this function is the module's public API.

Here is an example of an AMD module with dependencies on jQuery and Lodash:

define(['jquery', 'lodash'], function($, _) {
  // jQuery and Lodash can be accessed here
  // via the `$` and `_` arguments to the function
}

If an AMD module has no dependencies, the dependency array argument can be omitted.

Here is our counter defined as an AMD module:

define(function() {
  let value = 0;

  return {
    increment() {
      value++;
    },

    decrement() {
      value--;
    },

    getValue() {
      return value;
    }
  }
});

We would use our counter module from another AMD module like this.

define(['./counter'], function(counter) {
  counter.increment();
  console.log(counter.getValue());
});

CommonJS modules

CommonJS modules are typically used with Node.js. Each file is considered a module. To use functionality from another module, it is added to the current module by calling require, passing the module name. The module name can either be the relative path to another JavaScript file, or can be the name of a module installed from npm.

A CommonJS module's public API is declared by setting the module.exports property. Whatever is assigned to this will be the value returned when another module requires the module. There is an alternate syntax as well. CommonJS also exposes an exports property. Data and functions can be set on that property as well to define the module's public API.

That is, the following two are equivalent:

module.exports = {
  functionOne() { },
  functionTwo() { }
};

exports.functionOne = function() { };
exports.functionTwo = function() { };

Here is our counter module implemented as a CommonJS module:

let value = 0;

module.exports = {
  increment() {
    value++;
  },

  decrement() {
    value--;
  },

  getValue() {
    return value;
  }
};

The counter module can be used from another module by requiring it:

const counter = require('./counter');

counter.increment();
console.log(counter.getValue());

Universal Module Definition (UMD) modules

UMD modules are a kind of "catch-all" module. A UMD module will attempt to detect what kind of environment it's running in. The exact code varies from module to module, but the general steps are:

• The module itself is defined in a factory function which returns the module's public API.
• Check if we are running in an AMD environment, i.e. if define is defined and is a function. If so, call define and register the module, declaring its dependencies and passing the factory function.
• Check for the presence of an exports property. If it exists, we are probably running in a CommonJS environment. The factory function is called, and module.exports is set to the return value.

• Otherwise, call the factory function and assign its return value to the global scope.

  We can define our counter module as a UMD module by using the following rough code, adapted from David Calhoun's excellent blog post:

(function(root, factory) {
  if (typeof define === 'function' && define.amd) {
    // We're running in AMD
    define(factory);
  } else if (typeof exports === 'object') {
    // We're running in CommonJS
    module.exports = factory();
  } else {
    // Just set a property on the global object
      root.Counter = factory();
  }
})(this, function() {
    let value = 0;

    return {
        increment() {
            value++;
        },

        decrement() {
            value--;
        },

        getValue() {
            return value;
        }
    };
}));

By using the UMD format, a module can have wide support across different modules and applications.

ECMAScript (ES) modules

ES modules are the new standard, introduced in ES2015 (otherwise known as ES6). They introduce the import and export keywords to JavaScript language.

An ES module can have one default export and one or more named exports. The only real difference between these is the syntax to import them.

Default export

The default export is set by using the export default keyword. This can be an object, function, or even a single value. A module can only have one default export, but it isn't required. A default export is not bound to a name. A name is chosen for it when it is imported from another module (see below).

export default function add() {
  ...
}

Named exports

Named exports are bound to a name, but this name can be aliased when imported from another module. A named export is created by simply placing the export keyword in front of an object, function, or value.

export const pi = 3.14;

Importing

A module is used by importing its default export or named exports.

When importing the default export, you assign it any name you want. Here's an example of the syntax:

import add from './addModule';

To import a named export, the syntax is slightly different:

import { pi } from './math';

You can alias the named export:

import { pi as piValue } from './math';

In the above example, the pi named export will be bound to the name piValue.

You can also import multiple named exports, which can be a mix of objects, functions, and values:

import { pi, squareRoot } from './math';

console.log(pi);
console.log(squareRoot(9));

Lastly, you can import all named exports together under a namespace:

import * as math from './math';

The counter module

For completeness's sake, here is the counter as an ES module:

let value = 0;

export function increment() {
  value++;
}

export function decrement() {
  value++;
}

export function getValue() {
  return value;
}

The module is used as follows:

import { increment, getValue } from './counter';

increment();
console.log(getValue());

Compatibility

Because AMD, CommonJS, UMD, and IIFE modules are all based on functions, they have very wide support. With the right tools they can be used with any runtime or browser.

Because ES modules involve the addition of new keywords, they aren't as widely supported. All modern browsers support ES modules natively, but they are not supported at all in Internet Explorer.

Fortunately, with tools like Babel or TypeScript, you can use the ES module syntax and the code will be transpiled into a form the browser will understand.

Summary

In this article, we looked at several types of JavaScript modules:

• IIFE/Revealing Module
• AMD
• CommonJS
• UMD
• ES Module

They all have pros and cons so make sure to choose what makes the most sense for your project.

That said, for greenfield projects you should probably be using ES modules as that is where things are going.

I hope you found this helpful!

Quick CSS animation refresher

A CSS animation is defined by creating a set of keyframes. These keyframes define what CSS properties are applied at different points during the animation. When the animation is performed, the browser gradually transitions these properties between keyframes, creating an animation. Here's a simple example that makes an element spin:

@keyframes spin {
  0% { transform: rotate(0deg); }
  100% { transform: rotate(360deg); }
}

These keyframes define the animation, and they are applied by using the animation CSS property on an element. This is a shorthand property that allows you to set multiple animation-related properties, such as animation-name and animation-duration, in a single line.

Let's apply the spin animation to an element:

.box {
  margin: 50px;
  width: 200px;
  height: 200px;
  background: red;
  animation: spin 1s infinite;
}

Here is the result:

Animating with Tailwind

Now that we remember how animation works with CSS, let's do it the Tailwind way. Tailwind ships with a few built-in animations, such as:

• spin
• ping
• pulse
• bounce

These animations can then be applied to an element by adding the class animate-<animation name>, e.g. animate-spin.

Let's say we want to do a fancier animation than the ones that are built in. Let's add a roll animation that moves and rotates the element. We can extend Tailwind to add new animation classes to do whatever we want.

To do this, you will need to edit your Tailwind configuration file. This is where the custom keyframes and animations are defined. These are set by specifying or extending the keyframes and animations properties in the theme.

First, let's define the keyframes:

module.exports = {
  theme: {
    extend: {
      keyframes: {
        roll: {
          '0%, 100%': { transform: 'translateX(0) rotate(0deg)' },
          '50%': { transform: 'translateX(20rem) rotate(385deg)' }
        }
      }
    }
  }
};

As you can see, Tailwind lets you combine keyframes if they have the same CSS properties. The keyframes we've defined here have the element in its original position with no rotation at the beginning and the end of the animation. At the halfway point of the animation, the element is moved 20rem to the right and rotated 385 degrees.

Next, we have to define an animation that uses these keyframes, under the animations property:

module.exports = {
  theme: {
    extend: {
      keyframes: {
        roll: {
          '0%, 100%': { transform: 'translateX(0) rotate(0deg)' },
          '50%': { transform: 'translateX(20rem) rotate(385deg)' }
        }
      },
      animations: {
        roll: 'roll 3s ease-in-out infinite'
      }
    }
  }
};

These changes will cause Tailwind to define a new class called animate-roll. All we have to do now is apply that class to an element, along with a little extra Tailwind styling, and we're done!

<div class="p-20">
  <div class="animate-roll bg-blue-600 border-2 border-blue-700 text-white px-8 py-2 rounded-md text-center w-40 font-bold text-xl">
    Hello Tailwind!
  </div>
</div>

The final result can be seen in this Tailwind Play playground.

Couldn't we already do that?

You might be thinking - we already could map keys to values in JavaScript!

const map = {};

map[key1] = value1;
map[key2] = value2;

You would be correct. Prior to ES2015, you could absolutely use JavaScript objects to map keys to values. However, there was an important limitation. When mapping with a JavaScript object, only strings may be used as keys. Consider the following:

const map = {};

const key1 = { foo: 'bar' };
const key2 = { baz: 'qux' };

map[key1] = 100;
map[key2] = 200;

Here we are taking two JavaScript objects and mapping them to some numbers. This is perfectly valid JavaScript; you won't get any errors when running this code. Let's see what happens when we try to retrieve these values:

console.log(map[key2]); // prints 200

So far, so good. Now let's look up the first key:

console.log(map[key1]); // also prints 200

Why does this print 200, when in the above code we mapped key1 to the value 100? Let's investigate by looking at all the keys in the object map:

console.log(Object.keys(map));

This will print out an array with a single key:

["[object Object]"]

What's going on here?

It turns out, if you use a non-string key in a JavaScript object, the key is converted to a string by calling toString on it. For a plain JavaScript object, this results in the key '[object Object]'.

So when we set the first key in our map object, it was converted to that string, and everything would have worked as expected up to that point. However, when we added the second key, that was also converted to the same string value, so it overwrote the previous mapping. This is why the result will always be 200.

Map to the rescue

The ES2015 Map can solve this problem for us. Like a plain object, it can map keys to values. Unlike plain objects, a Map can have non-string keys.

Creating a Map

Let's use the same example as above, only using a Map instead of a plain JavaScript object.

const map = new Map();

const key1 = { foo: 'bar' };
const key2 = { baz: 'qux' };

map.set(key1, 100);
map.set(key2, 200);

console.log(map.get(key1)); // prints 100
console.log(map.get(key2)); // prints 200

Now the mapping works as expected, because a Map can use objects as keys.

For more information about Map, see the excellent MDN documentation.

What is Flexbox?

Flexbox is the more commonly used name for the CSS Flexible Box Layout Module. It has very wide browser support. According to CanIUse.com, it is fully supported in all modern browsers. It even has pretty decent support in IE11, though it can be buggy.

Flexbox is a one-dimensional layout. The flex items inside a flex container are laid out either in a horizontal row or a vertical column. There are several CSS properties that are used to fine-tune flexbox behavior when it comes to placement, sizing, and alignment.

Concepts

A quick note on concepts: I will describe the flow of flex layouts from left to right and top to bottom. This is usually how it works, but some locales flow text from right to left and so the default direction will be different. Make sure to keep this in mind when learning these concepts.

Main axis

The main axis is the direction of the flex container. In a row flexbox container, the main axis is the horizontal axis, along the direction that the flex items are placed.

Cross axis

The cross axis is the direction perpendicular to the direction of the flex container. In a row flexbox container, the cross axis is the vertical axis.

Creating a flexbox layout

It's very easy to create a flexbox layout. Just set an element's display property to flex. This will make the element a flex container. Any direct children will become flex items and will be laid out along the main axis.

To specify whether the flex container should be a row or column, set the flex-direction property to row or column, respectively.

The flex items will be flush against each other - by default, there is no spacing between them. Space can be added in two ways. The first, more widely supported way, is to just add margin to the flex items. There is another way to set uniform spacing of all flex items, by using the gap property. However, the gap property is only currently supported for flexbox in a few browsers.

Let's create a quick flex container. Here's the HTML:

<div class="container">
  <div class="item">1</div>
  <div class="item">2</div>
  <div class="item">3</div>
  <div class="item">4</div>
</div>

And the accompanying CSS:

.container {
  background: lightgray;
  display: flex;
  flex-direction: row;
  width: 20rem;
  border: 1px solid black;
}

.item {
  background: skyblue;
  font-size: 3rem;
  width: 3rem;
  border: 1px solid red;
  text-align: center;
}

Here's the result:

You'll notice that the flex items are bunched together at the beginning of the main axis within the flex container.

flex-grow

There are a few things we can do to change this behavior. First, we can specify a value for the flex-grow property on a flex item. When flex-grow is set, the item will grow to fill available space. The value is relative to the flex-grow value of other flex items.

If flex-grow is set to 1 across all items, they will grow equally:

If we set flex-grow to 1 across all items but set it to 2 for one of the items, that item will grow twice as much as the other items:

.item {
  flex-grow: 1;
}

.item2 {
  flex-grow: 2;
}

As you can see in the screenshot above, item 2 grows more than the other items. Twice as much, to be precise.

The justify-content property

The justify-content property is set on the flex container. It specifies how the flex items are laid out along the main axis. The default value for this property is flex-start; it results in the behavior we've already seen. The flex items are bunched together at the beginning of the main axis.

There are several other useful values we can set for justify-content:

center

The flex items are bunched together at the center of the main axis.

flex-end

The flex items are bunched together at the end of the main axis.

space-between

The first flex item is flush with the beginning of the main axis, the last item is flush with the end of the main axis, and the remaining items are spaced evenly between them.

space-around

An equal amount of space is used between each flex item. On the inner flex items, this space "doubles up".

space-evenly

Equal spacing is used between all flex items.

The align-items property

align-items is similar to justify-content, except it specifies how items are aligned along the cross axis of the flex container.

flex-start

The flex items are aligned to the start of the cross axis.

flex-end

The flex items are aligned to the end of the cross axis.

center

The flex items are centered along the cross axis.

The holy grail: Absolute centering with flexbox

The old joke of "How do you center a div?" is finally solved with flexbox. Simply set its container to be a flex container, and set both the align-items and justify-content properties to center:

<div class="container">
  <div class="item">Item</div>
</div>

.container {
  background: lightgray;
  display: flex;
  flex-direction: row;
  width: 20rem;
  border: 1px solid black;
  height: 20rem;
  align-items: center;
  justify-content: center;
}

.item {
  background: skyblue;
  font-size: 3rem;
  width: 8rem;
  border: 1px solid red;
  text-align: center;
}

The item div is centered horizontally and vertically inside its container:

Further learning

The best resource you'll ever find for flexbox is A Complete Guide to Flexbox on CSS-Tricks. You'll find the properties we covered in this article along with many others to better tweak your flexbox layouts!

I hope you found this introduction to flexbox helpful.

If you don't need to support Internet Explorer 11, you can absolutely use Custom Elements today, as they are supported by all modern browsers.

What is a custom element?

HTML has lots of built in elements, but Custom Elements allows you to create your own HTML elements with custom behavior. For example, I'm working on Atomical, a custom element that displays a calendar.

In this article, we'll create a simple Click Counter element. It will render a button which displays the number of times it has been clicked.

Anatomy of a custom element

At its core, a custom element is simply a JavaScript class that extends from the HTMLElement class. It contains some lifecycle callback methods, which we'll get into in a moment.

Finally, that class is registered with the browser's CustomElementRegistry (which you can find under the customElements property of the window object). The class is registered with a given element name. One rule: the element name must contain a hyphen, to prevent it from clashing from current (and future!) HTML elements.

Another rule is when using custom elements, they must have a start and end tag, even when there is no child content - they cannot be self-closing.

Lifecycle callbacks

There are a few lifecycle callbacks in a custom element. These are methods that are called by the browser at different points in the custom element's lifecycle. Here are the most commonly used lifecycle callbacks:

• connectedCallback - Called when the element is added to the DOM. Usually used to render the initial HTML, add event listeners, etc.
• disconnectedCallback - Called when the element is removed from the DOM. Used to perform cleanup.
• attributeChangedCallback - Called whenever an attribute of the custom element has changed.

The ClickCounter custom element

Let's create our click counter.

The component class

The first step is to create our component class. In the connectedCallback, we'll create the button and add a click event listener to increment the counter. This is a simplified implementation; we aren't doing any cleanup in a disconnectedCallback, which we'd want to do in a real-world custom element. Let's keep it simple for now.

class ClickCounter extends HTMLElement {
  constructor() {
    super();
    this.clickCount = 0;
  }

  connectedCallback() {
    const buttonEl = document.createElement('button');
    buttonEl.innerHTML = this.clickCount;

    buttonEl.addEventListener('click', () => {
      this.clickCount++;
      buttonEl.innerHTML = this.clickCount;
    }
  }
}

Register the custom element

Now that we've created the custom element class, let's register it with the CustomElementRegistry:

customElements.define('click-counter', ClickCounter);

Use the element

The last step is to use the click-counter element in our HTML:

<h1>Click Counter</h1>
<click-counter></click-counter>

This will render a button with a label of 0. Every time you click the button, the counter on the button's label will increment.

Live code

Here's a CodePen containing this example code that you can play with:

Emojis are everywhere nowadays - SMS messages, Slack messages, even Git commit messages! But what makes these little smileys (and other icons) work?

📜 A little history

Emojis were predated by so-called "emoticons". These were sequences of characters that resembled faces with different expression, such as :-) for a smiley face. The emoticon first originated in electronic communications by Scott Fahlman on September 19, 1982, but their usage in printed text pre-dates even that. As early as the late 1800s (and possibly even earlier), sequences of print characters were proposed to represent different emotions.

There are several claims as to who invented the first graphical emoji characters, but they originally grew in popularity in Japan. Cell phone manufacturers began work to introduce their own emoji sets in the early 2000s.

Unicode is an industry standard for encoding of text. During the 2000s, Unicode gradually added emoji characters. Later that decade, it was suggested that Unicode consider creating a standard set of emojis that could be used across different platforms. Then, in 2009, the Unicode Technical Committee produced a proposed Unicode Emoji standard. Unicode 6.0 was the first version with a uniform set emojis.

⚙️ What makes an emoji?

Under the hood, emojis are just sequences of Unicode code points. For example, the "face with tears of joy" emoji (😂) is the code point U+1F602. The most basic emojis are single Unicode code points.

🎨 Why do emojis look different on different operating systems?

The Emoji standard defines what code point sequences stand for what emojis, but doesn't dictate how they should look. Each operating system vendor creates their own images for these emoji characters and puts them all into the system font as glyphs.

👍🏼 Skin tone variations

Unicode 8.0 added support for skin tone variations on human emojis. This is supported via a set of five modifiers based on the Fizpatrick scale for measuring human skin color. These modifiers are themselves also Unicode code points, starting at U+1F3FB and ending at U+1F3FF.

To create a skin tone variant of an emoji, a sequence is used consisting of the main emoji code point followed by the skin tone modifier. So for example, a dark skinned thumbs-up emoji (👍🏿) would be represented by the sequence U+1F44D U+1F3FF.

👨‍🚀 Complex emoji sequences

Some emojis don't have a single code point, but rather are expressed as sequences of other emoji code points - compound emojis, if you will. Here's an example: the male astronaut emoji (👨‍🚀). This is actually a combination of the man emoji (👨, U+1F468) and the rocket emoji (🚀, U+1F680).

But how does the system distinguish between an astronaut and a man followed by a rocket?

Enter the Zero Width Joiner (ZWJ).

The ZWJ, sometimes pronounced "zwidge", is not an emoji itself but is used in emoji sequences. Its code point is U+200D. It is an invisible character with, as its name implies, zero width.

The ZWJ is used as glue to attach different emoji code points together to create compound emoji sequences. Going back to our example of the male astronaut emoji, the sequence for this emoji would be U+1F468 U+200D U+1F680.

This can even be combined with a skin tone modifier to create a medium-skinned male astronaut (👨🏽‍🚀): U+1F468 U+1F3FD U+200D U+1F680. Note that the skin tone modifier, U+1F3FD, does not use a ZWJ.

👁‍🗨 Variation Selector 16

There is another special emoji code point, called Variation Selector 16, with a code point of U+FE0F. Some emojis also have a plain text presentation, which means they usually appear as a solid shape. For example, the heart emoji (❤️) has a plain text presentation (❤).

By default, these emojis will appear with the plain text presentation. The heart emoji code point is U+2764. This code point alone will result in the solid heart (❤).

To display these characters as their colorful emoji presentation, they are followed by Variation Selector 16. So to get the red heart, you would use the sequence U+2764 U+FE0F.

Some emoji sequences can have one (or more!) ZWJs and Variation Selector 16 characters. Take the example of the "eye in speech bubble" emoji (👁‍🗨). This is a complex sequence, U+1F441 U+FE0F‍ U+200D U+1F5E8 U+FE0F:

• U+1F441 eye
• U+FE0F Variation Selector 16
• ‍U+200D Zero Width Joiner
• U+1F5E8 left speech bubble
• U+FE0F Variation Selector 16

🖖 Wrapping up

There are some further emoji topics - additional modifiers, fully qualified vs. unqualified sequences, and more, but in the interests of time I won't cover those here. Maybe in a future post!

I hope you found this informative and that you learned something new about emojis! Think about this complexity the next time you send an emoji in a text message.