Daily Tips & Tricks for Web Enthusiasts

Get new tips and tricks in your inbox every week!

You can also follow @CoreAssistance on Twitter (where I tweet about each day's tip), subscribe to the RSS feed, browse the archive, or start with the first tip.

Quickly Bypass Your Web Browser’s Cache

Browsing the Web •

Web browsers cache resources from web pages, including HTML, CSS, JavaScript, images, and other assets so you don’t have to download everything from scratch every time you load a page. Most of the time this is a good thing because it makes browsing the web a lot faster.

However, sometimes (like when you’re working on a website) the cache can get in your way by showing you an older version of the page from the cache instead of downloading the new stuff you just changed.

If this happens to you there’s a quick way to bypass your web browser’s cache: just hold Shift when you click on the Reload button and your browser will ignore its cache and get a fresh copy of the site from the server.

Let’s Encrypt

Resources & Links •

Let’s Encrypt issues digital certificates you can use to enable HTTPS (SSL/TLS) on your website for free.

I know, it sounds too good to be true, but Let’s Encrypt really does provide 100% free certificates with no downside. They’re a non-profit established for the public good and are supported by a combination of donations and corporate sponsors comprising some of the most important companies on the web, including Mozilla, Google, The Electronic Frontier Foundation, Cisco, and many others.

The certificates Let’s Encrypt provides are just as secure as any other SSL/TLS certificate, even the ones that cost money. These certificates can be used to secure traffic to and from your site for a variety of purposes, from e-commerce to simply giving your visitors peace of mind. I use Let’s Encrypt here at Core Assistance, as well as on other projects, and they’ve worked wonderfully.

Many web hosts have support for Let’s Encrypt built right in. Enabling HTTPS on your website might be as easy as flipping a switch in your web host’s control panel.

If your web host doesn’t support Let’s Encrypt, ask them to!

When the web was new, no website was secure. The desire to sell things online drove the creation and adoption of secure connections to websites. These days some sites are secure and some aren’t, but we’re heading for a future where every website is secure. More and more services and systems require a secure connection, secure websites rank higher in search results, and new features are being designed and built for HTTPS only. One example is Mozilla requiring secure contexts for new features, which means that advances in HTML, CSS, and JavaScript will only work in Firefox if the connection to the website using them is secure.

With Let’s Encrypt providing completely free certificates, there’s no good reason your website should be insecure.

Use What You Build

UX & Accessibility •

Have you ever come across something that didn’t work well because the person who built it didn’t actually use it? Don’t be that person. Use what you build.

Use it on your computer. Use it on someone else’s computer (preferably one with a different operating system and web browser). Use it on your phone. Use it on someone else’s phone. Use it on a tablet. Walk into an Apple Store and use it on a bunch of different devices.

Don’t just take a quick look. Use it. Actually use it. Find the rough edges. Figure out what’s broken. Take notes. Now prioritize the problems, get to work, and make what you built better for everyone.

Tips for Naming Variables

JavaScript •

One of the hardest problems in programming is naming things. Today, I’m going to give you a few tips for picking useful names for your variables in JavaScript. Don’t worry, future tips will cover naming other things.

The most important thing to keep in mind when choosing names for your variables is who you’re naming them for. Many people have the misconception that the computer cares about the name of your variables, or that different variable names have some kind of performance impact. This is not true. Decades ago, when memory was incredibly scarce, programming was brand new, and every byte mattered, keeping your variable names short actually did have an impact. Thankfully, those days are now well behind us.

Another common fallacy is thinking that as long as your variable names make sense in the moment, you’re fine. Maybe you think you’ll never need to come back to this code in the future (chances are you will), or that you’ll be able to pick things back up quickly and easily. Nothing could be further from the truth.

When you’re writing code, you’re thinking about the entire program. You have some version of it running in your head. You have context. Naming a variable a or temp or aThing might make perfect sense in the moment, but you have to remember that your current coding mindset is temporary. If the names of your variables aren’t clear, it will be incredibly hard to remember what you were thinking in two weeks, let alone two months or two years from now.

You don’t name variables for the computer, and you don’t name them for the you of today. Your target audience when naming variables is Future You, and anyone else who might need to understand your code later.

The trick to naming variables correctly is twofold:

  1. Keep Future You, and other people, in mind.
  2. Walk the line between too short and too long.

One way to tell if your variable names are conveying what they need to convey is to try reading your code like a sentence. If you come up with something like, “This function takes A and add B and C to it and then returns the result,” that’s a bad sign. You want to aim for something like “This function takes a price and adds tax and shipping to it.”

On the other end of the spectrum, I’ve seen variable names like thePriceWithTaxAndShippingAdded and postsAfterFilteringHTML. In some situations names like these might be warranted (when in doubt, Future You will appreciate more verbosity instead of less), but names like these usually point to bigger problems in the code, like a lack of clarity and context in the surrounding functions, comments, and/or methods.

If you find yourself being overly verbose with your variable names ask yourself why you feel the need for that level of detail. Has your code gotten away from you? Are you not adding in proper comments? Find and fix those underlying problems first, then try naming your variables again.

When all else fails, ask yourself this question: “If I look at this code six months from now, will the name of this variable sense?”

Watch Out for Trailing Commas in CSS

HTML & CSS •

When writing code there are a lot of situations where you need to provide a comma-separated list of things. Here’s how you create an array in JavaScript, for example:

var array = [foo, bar, baz];

This array contains foo, bar, and baz.

Some people, for clarity or just preference, will write that same code across several lines, like this:

var array = [
    foo,
    bar,
    baz
];

In JavaScript, the order of the items in an array matters. If you wanted to move baz up to the second position in the array you couldn’t just move that line up, because the commas wouldn’t be in the right places anymore.

In order to avoid this comma problem, and make it both easier and less error-prone to move things around, many people add a trailing comma to the last item, even though there’s nothing that comes after it, like this:

var array = [
    foo,
    bar,
    baz,
];

That makes it easy to move the items in the array around just by moving lines up and down. This is a common practice in many programming languages, and many people have developed a habit of placing a trailing comma after the last item in a comma-separated list like this.

Now, in CSS, you’ll also run into comma-separated lists of things. One of the most common things you’ll see is a list of selectors separated with commas, like this:

h1, h2, h3 {
    color: blue;
}

If you’ve picked up the habit of adding a trailing comma after the last item from another programming language you might be tempted to write something like the following (or you might see this in some CSS someone else wrote):

h1,
h2,
h3,
{
    color: blue;
}

Unfortunately, this CSS won’t work. Adding a comma after the last selector in CSS is not allowed, so adding the comma after the h3 selector will invalidate this selector list.

Furthermore, one of the interesting things about CSS is that any invalid selector in a list of selectors invalidates all of them. Thus, the comma placed after the h3 selector above will prevent the entire ruleset from working, so color: blue; won’t be applied to anything.

So, if you have some CSS that’s not working and you can’t figure out why, make sure you don’t have a trailing comma after the last selector!

Don’t Revise as You Write

Writing •

Writing and editing are two seperate processes. You write, then you edit. Trying to do both at the same time leads to frustration and subpar copy.

Why?

Writing something down transforms it from an ephemeral thought into real, tangible words. Concepts in your head are in a constant state of flux. They’re living, slippery things that are all but impossible to get a firm grip on. That’s why writing them down is so powerful.

If you write something down and then immediately try to revise it what you’re really doing is trying to compare concrete words on the page with a wiggly, dynamic thought in your head. It’s like comparing apples and oranges. No, it’s like comparing an apple sitting still on a table with an orange that’s being blended into a smoothie.

The only real way to avoid making these unfair comparisons is to write everything down first, then go back and edit. That’s the only way to know that you’ve truly picked the best words to convey your thoughts.

Only Break Rules You Understand

Design •

If you’re tempted to break a rule, convention, default, or best practice (as we all are, from time to time), make sure you understand the spirit behind the rule first. There are often important motivations behind every rule, and you’ll need to take those into account when bending or breaking them.

A great example is the temptation to remove the default outline styles most web browsers apply to focused elements. These outlines are visually distinct, and you may not like the way they look. Removing them may seem like a harmless design decision, but those default styles are there for an important reason. If you don’t know the motivation behind those default style rules, and don’t take the consequences into account when you override them, your choices will have unforeseen consequences for people visiting your site.

There are times when breaking rules is the right decision, but a deep understanding of those rules is required to keep you from making things worse.