Category: JavaScript

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing JavaScript code.

Compress Built Files

We should compress built files with gzip, Brotli, or other compression methods so that users don’t have to download as much data.

The less code users have to download, the faster the loading time will be.

Limit Library Dependencies

We should limit the libraries that we use.

There’re smaller alternatives and we can remove the ones that are built into the JavaScript standard library.

Minify our Code

Before putting our code on production, we should minify them so that the size of the files are smaller.

There’re many tools to let us do this.

Frameworks have tools that use Webpack to minify files without doing any work.

There’re also other libraries like Parcel to do the same thing.

Add Post-Load Dependency Managers

Webpack also lets us manage our dependencies.

This include non-JavaScript files like CSS files and images.

They can be loaded as modules with Webpack for example.

They can also track JavaScript dependencies.

This way, nothing is loaded twice and avoid other issues.

Cache as Much as we Can

Caching reduce the number of requests that have to be made to get assets.

They’ll only be downloaded again when the cache expires.

This will speed up loading times.

We can also use content delivery networks to speed up delivery to users.

Mind our Event Handlers

Some event handlers like mousemove or resize run every time those actions are taken.

This means they’ll run many times in quick succession.

An event handler shouldn’t take more than 2 to 3 ms to run.

If it takes longer, then we need to optimize our code.

Replace click with mouseup

Mouseup fires before the click event provide a performance boost by ensuring no interactions are missed if users make multiple mouse clicks in quick succession.

Use Reference Types Responsibly

If we use reference types, then they can be passed around into different parts of the code.

They’re passed by reference into functions.

This can let us cut down on the number of DOM traversals needed.

Primitive values are always passed by value into functions so a copy is made everywhere.

Comparing references if always faster than comparing strings.

Favor Native Functions and Constructs

If something is available in the JavaScript standard library or available as a language feature, then we should use it.

This lets us reduce the number of dependencies that we use.

Prefer async and defer

We should use the async and defer attributes to load scripts asynchronously.

async load scripts asynchronously without regard to order.

defer load scripts asynchronously one after the one as listed in the code.

They can let us load other things while waiting for the scripts to load.

Animate with requestAnimationFrame

requestAnimationFrame fixes the rendering at 60 FPS.

Therefore, if our animation is running slow, we can use requestAnimationFrame to get them up to speed.

Conclusion

We can minify our code to speed them up.

Also, there’re ways to improve animation speed.

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing JavaScript code.

Don’t Bundle Everything Together

We shouldn’t bundle everything together into one big package.

HTTP/2 no longer has bi overhead when making multiple HTTP requests.

Therefore, there’s no advantage to bundling everything up.

Browser caching is also hard with this approach since any change will invalidate the cache.

This will force users to download everything again.

That results in lots of wasted bandwidth.

HTTP/2 is supported by 95% of the clients worldwide, so we can assume that we don’t need to bundle everything together.

Best Way to Bundle Items

Separate vendor and client code is the best approach

This solves the issue where a small change will force the user to download everything again.

If our own code changes, then only the client code is changed.

The vendor code remains the same since we didn’t change the library code.

This saves us lots of bandwidth.

With Webpack, this requires extra code-splitting config to tell Webpack where the vendor code lives.

They should live in the node_modules folder.

So in the built index.html file, we get:

<script src="vendor.[hash].min.js"></script>
<script src="index.[hash].min.js"></script>

We can improve this further.

The vendor file can be split into smaller pieces.

For example, we can write:

<script src="vendor.react.[hash].min.js"></script>
<script src="vendor.others.[hash].min.js"></script>
<script src="index.[hash].min.js"></script>

to split the React files from the rest of the library files.

This is because the React libraries change slower than the other ones, so we can keep them cached separately.

Public CDN

We shouldn’t keep all our dependencies in the bundles instead of having some in the CDN.

The code is downloaded once per domain and the cache is sandboxed because of privacy implications.

This is because of the partitioned cache feature that separates the caches for users from different domains.

Also, using CDN means that we need to do all the request stuff for every domain.

DNS resolution, initial connection, and SSL handshake all required to be done.

Hitting the CDN means that we have to do those things for one more domain.

So having everything in the same domain will reduce the overhead.

Vendor versions would also be fragmented since the library versions on different CDNs are different.

If we browse from one site that uses one CDN and another that uses a different one, then they’ve to be downloaded again.

CDNs can also have other issues like malicious code injected into them.

Privacy may also be a concern since some people may harvest data from 3rd party requests.

And CDNs are a single point of failure.

The Best Way

Therefore, the best way is to use packages for all our dependencies and then build them into vendor and index JavaScript files.

Then we can put them behind our own non-shared CDN so that they can be downloaded by users and cached until we deploy the next set of changes.

They can be smaller because of HTTP/2 caching and fast performance when making multiple requests.

Conclusion

We should bundle our files into chunks consisting of one or more with 3rd libraries and another with our own code.

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing JavaScript code.

Declare All Variables First

To make finding variables easier, we can declare them at the top.

For example, instead of writing:

function foo(){
  let i = 100;
  console.log(i);
  let j;
}

We write:”

function foo(){
  let i = 100;
  let j;
  console.log(i);
}

This way, we won’t have a hard time looking for variable definitions.

We also don’t have to worry about hoisting when using var or function declarations.

Be Careful Using typeof

We’ve to know that typeof null returns 'object' .

So we can’t use it to check for null .

Also, typeof NaN returns 'number' , which is probably not what we expect.

So we shouldn’t use them to check for those.

Treat parseInt With Care

parseInt also have some quirks we’ve to think about.

It returns all of the number characters it finds converted to the number.

So if we have:

parseInt("11");

It’ll return 11.

And if we have:

parseInt("11james");

This will also return 11.

And if we have:

parseInt("11.22");

This also returns 11.

We should take note of these quirks so that we won’t get unexpected results when we try to convert non-numbers to numbers with parseInt .

Also, if the number starts at 0, it’ll assume that it’s an octal number.

So if we have:

parseInt("08");

then it’ll return 0 in older browsers.

However, in modern browsers, it should be converted as a decimal number.

Do Not Use Switch Fall Through

In each case clause of switch statements, we should have a break or return statement at the end of the clause.

For example, we write:

switch (val) {
  case 1:
    console.log('One');
    break;
  case 2:
    console.log('Two');
    break;
  case 3:
    console.log('Three');
    break;
  default:
    console.log('Unknown');
    break;
}

so that the JavaScript interpreter won’t run code below the case clause that’s matched.

Avoid For…In Loops

for-in loops should be avoided for arrays.

It doesn’t guarantee iteration order and it’s slower than the standard for loop.

It’s intended for iterating through an object’s noninherited and inherited properties.

This means the following loops aren’t equivalent:

for (let i = 0; i < arr.length; i++) {}

for (let i in arr) {}

If we want to iterate through an array in a shorter way, we can use the for-of loop:

for (let a in arr) {}

a is the array entry.

Avoid Reserved or Special Words

We shouldn’t use reserved words to define our own identifiers.

This may be allowed if strict mode is off.

For example, we may define functions like:

function foo(arguments){}

which is allowed if strict mode is off.

If it’s on, then we’ll get an error.

This is one good reason to turn on strict mode.

We can avoid defining our own identifiers that have the same name as a reserved word.

Be Consistent

We should be consistent with our code styling.

This can be done easily with ESLint.

It’s good at fixing these styling issues for us so we won’t have to worry about them.

Conclusion

We can reduce headaches by following some easy to follow rules.

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing JavaScript code.

Use the Module Pattern to Encapsulate

We can use the module pattern to encapsulate our code.

This lets us keep private variables in any JavaScript code.

For example, we can write:

(function(){
  let x = 123;
  console.log(x);
})();

We have the variable x that’s only available inside the function.

It’s also useful when classes or constructors don’t make sense.

Namespace Our JavaScript

If we need to refer our JavaScript code else, we should namespace them to make them easy to find.

For example, we can write:

let MyNamespace = MyNamespace || {};

MyNamespace.MyModule = () => {
    // ...
}

our namespace has properties, which include objects we use as a module.

Anonymously Scope JavaScript

We should scope our JavaScript if we aren’t calling it anywhere.

For example, we can write:

(function(){
  let x = 123;
  console.log(x);
})();

to scope the JavaScript to be inside the function only.

This makes our variables available only inside the function.

And we can’t modify them accidentally.

Focus on the Big Things when Optimizing

The big performance improvements can come from a few places.

DOM operations are expensive so we should do them as little as possible.

Anything that forces a page to re-rerender isn’t optimal.

Events that are fired all the time like resizing and scrolling can also be denounced or throttled.

If we have lots of HTTP requests, we can also reduce them.

These are problems we can address to increase responsiveness.

Lazy Load Assets that aren’t Immediately Required

If we have assets that aren’t shown to the user immediately, then we should lazy load them.

This way, they’re only loaded when they’re needed to be shown.

unbind() All Event Handlers Before Binding

We should unbind all event handlers so that we don’ t have multiple event handlers bound to elements.

For example, we can write:

$("a.some-link").unbind(handleClick).click(handleClick);

to unbind the existing event listeners and then attach a new click listener to the a link.

This ensures that it’s only bound once.

Since we need this everywhere, we can create a helper function to help us do this everywhere.

Don’t Treat JavaScript Like a Classical OOP Language

We shouldn’t treat JavaScript like a classical OOP language.

Even though the class syntax exists, it’s just syntactic sugar on top of its prototypical inheritance model.

This has never changed.

So even though JavaScript has classes, it’s not a classical OOP language.

Don’t Abuse Inlining of Functions and Object Literals

Deep nesting is definitely bad.

They make code hard to read.

The deeper the nesting, the harder it is to follow.

For example, no one wants to read something like:

var myFunction = function() {
  $('form#my-form').submit(
    function(event) {
      event.preventDefault();
      $.ajax(
        '/some_service', {
          type: "POST",
          data: {
            name: name,
            name: company
          },
          success: function(data) {
            onSuccess({
              response1: data.value1,
              response2: data.value2
            })
          },
          error: function(data) {
            onError({
              response1: data.value1,
              response2: data.value2
            })
          }
        }
      );
    }
  );
};

We should make this easy to read by reducing nesting.

Inlining everything also makes functions and variables impossible to reuse.

Conclusion

We can create modules to separate values.

Also, we unbind event handlers with jQuery before attaching them.

And don’t abuse inlining and treat JavaScript as a classical OOP language.

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing JavaScript code.

Variable and Function Naming Conventions

We should have variable and function names that are clear.

In JavaScript, names are usually camelCase except for constants and constructors.

For example, we can write:

const firstName = 'james';

We name constants with:

const MAX_RETRIES = 50;

And we name constructors and classes with PascalCase:

class Dog {}

Using Global Variables

We want to avoid creating global variables.

They’re accessible everywhere so they can be modified by anything.

That leads to hard to trace issues.

So we should share variables with other ways like modules.

Functions

Functions should do one thing at a time.

If it has to do more, then we should separate it into a helper function.

Progressive Enhancement

We shouldn’t assume that everyone has JavaScript enabled.

To display something to users that don’t have JavaScript enabled, we can put stuff in the noscript tag for them.

Don’t Change Variable Type After Init

To make our lives easier, we shouldn’t change the variable type after a variable is initialized.

For example, we shouldn’t write:

let status = "Success";
status = 1;

Changing types makes debugging harder.

Instead, we can assign values with different types to different variables.

Use Inline Commenting

We can add inline commenting in our code for comments.

We should keep them short and to a single line.

For example, we can write:

addtoCart(order) // add to cart

Control Variable Scope

To control variable scope, we can use let and const .

They’re all block-scoped so there won’t be any confusion as to where they’ll be available.

For example, we can write:

for (let i = 0; i < 10; i++) {
  console.log(i);
}

We use let to define i so that it’s only available within the loop.

JavaScript is Case-Sensitive

We should remember that JavaScript is a case sensitive language.

So foo is different from Foo .

This applies to everything.

So we should make sure our code has the right case.

Traverse an Array From the Right End

We can traverse an array from the right end with the array instance’s slice method.

For instance:

const arr = ['a', 'b', 'c', 'd', 'e', 'f'];
console.log(arr.slice(-1));

returns ['f'] and:

console.log(arr.slice(-2));

returns ['e', 'f'] and so on.

slice doesn’t modify the array is called on.

Substitute Loop with map()

If we want to map array entries from one thing to another, we don’t have to use a loop.

Instead, we use the map instance method.

For example, we can write:

const itemsIds = items.map((item) => {
  return item.id;
});

to get the IDs from items in the items array.

Replace All Occurrences of a String

We can call replace with the g flag to replace all occurrences of a string.

For example, we can write:

const str = "foo foo bar baz";
console.log(str.replace(/foo/g, "qux"));

Then ‘qux qux bar baz’ is returned.

Conclusion

There’re many tricks we should be aware of to improve our JavaScript code.