As I promised previously I’m writing this blog post about errors handling with async/awaits. This one will be just a short note to show an idea of how Promises and async/awaits can work together. Actually, errors handling is a huge topic in software development, but let’s remember only the most popular ways to handle errors in JavaScript:

• Passing error object in callbacks
• try...catch statement in general cases and for async/awaits
• .catch() when using Promises

As we’re working with async/awaits and Promises, let’s took only the last two.

Sometimes I hear an opinion that if you decided to move from Promises to async/awaits to simplify your code and there was a Promise.catch you have to use try...catch statement to convert this. But that’s not actually true, you can mix these approaches to leave your code free from ugly try...catch statements.

I think I have a good example to demonstrate this. Let’s look onto a new Node.js Promises file system API. There is a function access to check if a file is accessible by the current process. It returns a Promise which resolves if it is possible to access a target file and rejects otherwise. If we will try to use that with async/await it’ll look like this:

async function isAccessible(path) {
    let result;

    try {
        await fs.access(path);
        result = true;
    } catch (err) {
        result = false;
    }

    return result;
}

That one doesn’t look nice. But what if we’ll try to add a Promise error handling approach here?

async function isAccessible(path) {
    const result = await fs.access(path)
        .then(() => true)
        .catch(() => false);

    return result;
}

So how that could be possible? We know that returned Promise from access resolves and rejects depending from the check result, so I think it’s a nice idea to convert this behavior to the values we need: true or false.

Moreover, there’s no need to make this function async and add await to get a result. Actually, it’s possible to simplify it further.

function isAccessible(path) {
    return fs.access(path)
        .then(() => true)
        .catch(() => false);
}

// Usage

if (await isAccessible('/etc/passwd')) {
    console.log('The passwd file can be read by current process.');
} else {
    console.log('The passwd file can\'t be read by current process.');
}

Here is a really handy function isAccessible which returns Promise and it always resolves true or false and never rejects.

So what we got here? We should always keep in mind that Promises and async/awaits are tightly connected in JavaScript and use this knowledge to keep the code as clean as possible.

That’s it, thanks for reading this. Hope this note was helpful.

See also

1. Promise.catch MDN article with nice examples and comprehensive description
2. Node’s promises FS API documentation

I don’t want to dive deep into details about generators and other approaches which were predecessors of async/await but I want to show how to easily migrate from Promises to async/awaits in your project and when you should pay attention with async/awaits.

Promise

First of all, let’s remember what is the Promise? As it is written in MDN

Promise is an object which represents the eventual completion (or failure) of an asynchronous operation, and its resulting value.

In other words, Promise is an unknown result of some operation which will be known in the future. Usually, we can meet Promises in JS when we’re working with remote HTTP requests.

async/await

I like a definition that async/await in JS is just a syntax sugar for Promises.

Proposal of this feature exists quite long and it is already on stage 3, so browsers widely support it. If you don’t need to support ancient browsers (or if you’re already using Webpack) you can freely use async/await.

So why async/await is better than Promise? From a syntax side, async functions are really easier to read. But I think this is a slightly wrong question because async/awaits and Promises are different things and we shouldn’t compare them in this way. I believe that async/awaits and Promises should be used together to unleash the power of asynchronous operations and simplicity of code.

Well, let’s look at the Promise-based example of code:

const fetchGitHubReposCount = username =>
    fetch(`https://api.github.com/users/${username}`)
        .then(response => response.json())
        .then(result => result.public_repos);

The function returns Promise which will resolve repositories count of a specified user. How do we usually use such kind of functions?

fetchGitHubReposCount('tc39')
    .then(count => console.log(count));

Looks pretty easy. But what if we need to process this result somehow and send it to another URL? Every time we would need another .then(...) for that. Well, that looks not so nice and we can improve this with async/awaits.

const count = await fetchGitHubReposCount('tc39');
console.log(count);

Better, isn’t it? The code now looks plain and it is still asynchronous. But what if we need to fetch info about two users simultaneously? Probably you’ve already heard about Promise.all() and yes, for async/await you should also use Promise.all() in such cases.

const [countTC39, countMe] = await Promise.all([
    fetchGitHubReposCount('tc39'),
    fetchGitHubReposCount('alexey-detr'),
]);

The example above is a nice example of how async/await can be used with Promise together. This is what I meant speaking that we shouldn’t compare them.

Please note. It is a common mistake when developers forget about simultaneous tasks processing. You shouldn’t blindly write async/await code and expect that it will magically process simultaneous cases. If something can run in parallel you should use Promise.all or other tricky constructions to achieve optimal performance.

async function

Above we used an await keyword only, but every time there was an async prefix which is also usually used in conjunction with function. So what is the async function? First of all, it is a function which handles awaits inside of it and always returns a Promise.

That’s a nice fact about returning a Promise because we can combine old style Promise-based code with a new one and migrate to async/await smoothly.

In a real world, you can’t just write await outside of async function as we did before (it works in browser consoles because they have a special wrapper for that). Let’s rewrite an example above so it would work in a real world.

(async function () {
    const [countTC39, countMe] = await Promise.all([
        fetchGitHubReposCount('tc39'),
        fetchGitHubReposCount('alexey-detr'),
    ]);
})();

The code is wrapped by an IIFE (Immediately Invoked Function Expression). It is necessary to do so when you’re going to use await on the root level of a module. But it wouldn’t be an issue with nested functions, they can be async or not.

So how async functions work

Just a few words to describe a program flow inside of async functions. When a program reaches an await keyword, it interrupts processing of current function and continues it after awaited Promise is resolved or rejected. There is no any special magic, the logic is exactly the same as if you would write it with Promises. Just imagine that all your then(...) constructions turned into awaits.

In the end

So we found out how to change an approach from Promise-based to async/await-based without getting into deep details. But there is also a big domain called an error handling. I’m going to write about errors handling in async/awaits and Promises next time.

That’s it, see you next time.

The previous time I wrote a post about WebP image format, a modern image compression technology. I want to continue the topic about modern Web and today I’m going to tell something about new ECMAScript features and check if lodash is really necessary nowadays.

lodash

Why lodash became popular? The answer is really simple. Because it solved a lot of common tasks in JavaScript development. But let’s look closer at this library.

Advantages

Lodash has a lot of handy functions to work with JavaScript objects, arrays, and even functions. If you have to do something (array sorting, object mapping, function currying, etc), lodash will likely help you with that.

The next advantage is a null-safety (resistance to undefined). What’s that? Have you ever seen a TypeError: Cannot read property 'prop' of undefined? I bet you have. To avoid them you need to wrap your code into conditions:

let obj;
let result;
if (obj) {
    result = obj.prop;
}

But you can stop doing so with lodash because you can just write let result = _.get(obj, 'prop') and it will be an equivalent of a code above. This is one of the simplest cases when null-safety is handy.

Disadvantages

Today we’re living in a world where smartphones are beating desktops by usage stats. We should be prepared for users with very weak devices. Lodash has a performance impact. A code written in a pure JavaScript is much faster than its lodash equivalent. Moreover, lodash adds some extra kilobytes to your JavaScript bundles.

Another 3rd party library jQuery was like a plague. Do you remember the time when almost all websites were using jQuery? Developers used jQuery for everything, they learned how to program their websites with jQuery, not JavaScript. I’m afraid lodash is something like a next jQuery now.

The popularity of lodash became its weak side. Obviously, it is nice when every JavaScript developer knows the library. But if you’ll look on the NPM’s Most depended-upon packages list you’ll find that lodash is in the top of that. That means that lodash is used by the incredible amount of other packages. But do they actually need lodash? I definitely want to check it.

Investigations

There is a nice list of popular packages (thanks to npmjs.com) which depend on lodash. I wrote a simple script to clone this list. Finally, I got the 30 most popular packages that are using lodash, this should be enough for the research. Here they are:

Inquirer.js
ant-design
async
cheerio
elasticsearch-js
enzyme
eslint
eslint-plugin-flowtype
eslint-plugin-import
generator
grpc-node
grunt-contrib-watch
gulp-template
gulp-uglify
html-webpack-plugin
http-proxy-middleware
jshint
karma
knex
node-archiver
node-restify
react-dnd
react-native
react-redux
redux-form
sequelize
stylelint
webpack-bundle-analyzer
webpack-manifest-plugin
webpack-merge

I think you are already familiar with some of them. Actually, most of them will never be used on the client-side and should be installed as devDependencies. But anyway, all of them are using lodash for some reasons.

So what lodash functions are most popular in these libraries? I tried to fetch them in the following way:

grep -E "\s(_|lodash)\.\w+\(" -oh -r . | \
    sed -E "s/.*(lodash|_)\.([a-zA-Z]+).+/_.\2/" | \
    sort | uniq -c | sort -r | head -10

This shell command searches lodash functions and makes stats. That’s how I got a top 10 most used lodash functions in a top 30 most popular packages which are using lodash:

 123 _.map
 112 _.each
  98 _.get
  97 _.extend
  84 _.assign
  80 _.defaults
  80 _.clone
  74 _.template
  54 _.forEach
  49 _.bind

First column is an amount of corresponding lodash function usages. That’s look interesting, let’s check if all of them are so necessary.

The top 10 lodash functions

_.map

Collections mapping is a very common action in the JavaScript world. This lodash function can work with objects and arrays. Usually, we’re using it for mapping array of objects into another array of values, processed somehow. ECMAScript also has this for arrays. So we have a nearly easy way to write identical code using native methods:

const data = [
    {id: 1, name: 'Bob'},
    {id: 2, name: 'John'},
    {id: 3, name: 'Sarah'},
];
data.map(item => item.name);
// ['Bob', 'John', 'Sarah']

But what if data is an object. We can work with that in a very similar way:

const data = {
    1: {name: 'Bob'},
    2: {name: 'John'},
    3: {name: 'Sarah'},
};
Object.values(data).map(item => item.name);
// ['Bob', 'John', 'Sarah']

Remember I told you about null-safety? We can add it either.

const data = Math.random() >= 0.5 ? undefined : {
    1: {name: 'Bob'},
    2: {name: 'John'},
    3: {name: 'Sarah'},
};
Object.values(data || {}).map(item => item.name);
// ['Bob', 'John', 'Sarah'] or []

Of course you don’t need to think about data type you have with lodash, you can just always write _.map and it will work. But a native way also looks not bad.

_.each, _.forEach

_.each is just an alias for _.forEach.

This method iterates over arrays and objects. ECMAScript’s forEach function works only for arrays. If we want to migrate our code from lodash to native JavaScript, approaches would be nearly the same as we used for _.map.

But actually, there are some more differences between _.forEach and native forEach. Lodash version supports breaks, we can break the loop by returning false from its callback function. If you need to make a break in a native JavaScript, use a for...of statement

const data = Math.random() >= 0.5 ? undefined : {
    1: {name: 'Bob'},
    2: {name: 'John'},
    3: {name: 'Sarah'},
};
const dataArray = Object.values(data || {});
for (const user of dataArray) {
    if (user.name === 'John') {
        break;
    }
    console.log(user.name);
}
// 'Bob'

for...of usage is even better because you don’t need extra callback functions and your code would run in the same function block.

_.get

I believe this one should be on the first place by usage frequency, I don’t know why it isn’t so. This handiest lodash function allows accessing nested object properties safely. It is interesting fact, but ECMAScript already has an alternative for that, a TC39 optional chaining proposal. Let’s write some code using this new feature.

Optional chaining is on stage 1 and unfortunately it is not possible to run this code on any JavaScript engine, but we can use a Babel transpiler for that. To use it I created a simple sandbox project.

mkdir optional-chaining && cd optional-chaining
npm init -y
npm i --save-dev @babel/core @babel/cli @babel/plugin-proposal-optional-chaining
echo '{ "plugins": ["@babel/plugin-proposal-optional-chaining"] }' > .babelrc

And added some code into index.js

const data = [
    undefined,
    {id: 1, name: 'Bob'},
];
data.forEach(item => {
    console.log(item?.name);
});

Let’s run it

npx babel index.js | node
// undefined
// Bob

There was no TypeError: Cannot read property 'name' of undefined while accessing a property name of undefined. That’s how null-safety helps us in cases when we aren’t sure about data type we have.

Setting up Babel is a little complicated, but it allows to achieve null-safety in ECMAScript nowadays. In addition, if you’re already using Babel in your project, you can just add this plugin and be happy with this neat feature.

_.extend, _.assign, _.defaults

I put these methods together because they are very similar. All of them are used for merging objects in various ways. The difference between _.extend and _.assign is that _.extend enumerates own and prototype object properties. When we are talking about prototypes in JavaScript, we are usually talking about inheritance. You can read about JavaScript inheritance in this comprehensive article by Axel Rauschmayer. I believe that _.extend is an old-school inheritance-like method, and it would be better to use a modern class...extends statements today. Using extension of classes in JavaScript is an explicit way to show intents of your code. In practice, there is no drop-in replacement of _.extend method.

So what’s about _.assign and _.defaults. In the real world, their behavior is almost the same but they have a different arguments order. In fact, _.defaults has more details in its implementation, but usually, it doesn’t matter.

As I said before these group of methods are used for different ways of objects merging. ECMAScript already has a native way for basic objects merging. It is possible with spread operator, this operator is already a part of ECMAScript 2015 standard. Let’s imagine that we have some settings we want to use by default and some settings to override these defaults:

function applyDefaultSettings(settings) {
    const defaultSettings = {flag: false, option: 2, value: 'on'};
    return {
        ...defaultSettings,
        ...settings,
    };
}
const settings = {option: 5};
const preparedSettings = applyDefaultSettings(settings);
console.log(preparedSettings);
// {flag: false, option: 5, value: 'on'}

Using spreads in this way is a native alternative for both of _.assign and _.defaults methods.

_.clone

Lodash clone creates a shallow copy of various data types. But what does shallow mean? It means that nested non-scalar properties of a value would not be copied actually. So if you are trying to make a copy of a value which is an object/array and it has nested objects/arrays, those nested values would not be copied. Let’s check it.

const bob = {name: 'Bob', has: ['cat', 'dog', 'house']};
const bobsClone = _.clone(bob);
console.log(bob.has === bobsClone.has);
// true
console.log(bob === bobsClone);
// false

bob.has and bobsClone.has are just references to the same array but bob and bobsClone are different objects. So bobsClone is a shallow copy of bob.

What’s about ECMAScript? Does it have an alternative for the shallow copy? Yes, it has. We can do this with the same spread operator, which we used in previous section. The equivalent of example above in native JavaScript:

const bob = {name: 'Bob', has: ['cat', 'dog', 'house']};
const bobsClone = {...bob};
console.log(bob.has === bobsClone.has);
// true
console.log(bob === bobsClone);
// false

Pretty simple isn’t it? Spread operator works for arrays as well. I beleive we don’t need a lodash _.clone for shallow copying.

_.template

Well this one doesn’t have alternatives in a native JavaScript because it’s a part of lodash / underscore template engine. Let’s just skip it.

_.bind

Binding context to function is a common practice in JavaScript. It even can bind function arguments, but let’s look at basics. So what does binding mean? Let’s check this example:

const utils = {
    getName() {
        return this.name;
    }
};

Here is the utils object with the getName method. This method works in some context (this) and fetches a name field from the context. By default, the context will be the utils object itself.

If we will run this method we would get undefined because the utils context doesn’t have a name property.

But there is a way how to substitute a context for function with bind. This function creates a new function which always runs in a specified context.

Well, I just described what’s the function binding in JavaScript but didn’t tell anything about how to use lodash _.bind and native bind. Actually, usage of native and lodash binding functions are really similar:

const context = {name: 'Sarah'};

const nativeBoundGetName = utils.getName.bind(context);
nativeBoundGetName();
// Sarah

const lodashBoundGetName = _.bind(utils.getName, context);
lodashBoundGetName();
// Sarah

So we have a good alternative for lodash _.bind method.

Conclusions

Whew, this post turned out quite large. But I believe this little research was important because we found that (probably) lodash is not necessary nowadays. We still need Babel for this sometimes, but it is better to use Babel instead of 3rd party libraries because this is the future of JavaScript language. When new features become a part of ECMAScript standard, they are starting to work without Babel transpiler and JavaScript engines would probably get some native optimizations for them.

Also if you’re developing client-side applications for browsers lodash adds extra 24 KB to your JS bundles. Of course, you can add some changes into your code to enable tree-shaking, but if you are using another libraries which depend on lodash you will meet some issues.

That’s all guys, I think it’s time to end this post.

lodash/fp

In the end, I just wanted to say a few words about lodash/fp. You don’t need it either. If you’ve ever used lodash/fp you probably noticed how bad lodash/fp documentation is. But if you want to use functional programming approaches you would definitely need a library for that. I can recommend using Ramda, it has good documentation and it is smaller than lodash. Yet.

See also

1. The script I used to download popular NPM packages.
2. Nice recent article The Cost of JavaScript by Addy Osmani. If you didn’t read it you should do it soon. It contains very important stats about the performance of modern devices and how JS and CSS bundle sizes affect the average user.
3. A really nice project I found while writing this blog post. Its name You don’t (may not) need Lodash/Underscore. There are many code snippets with native alternatives of some lodash functions.

WebP

The main reason I’m writing this post is my recent experience with WebP format on my Node.js project.

Probably you’ve heard something about this format before and know what it is, but I have to tell a few words anyway. WebP is a modern image format developed by Google and its main feature is a size efficiency in various conditions. Why it is important? Let’s remember all the cases when we should use different image formats.

PNG. A transparent image with alpha channel. It is lossless and PNG files are usually huge. However this format supports 32-bit color (24-bit for RGB and 8-bit for alpha channel), so images can be of high quality.

JPEG. A good old format for photos. But it isn’t so efficient as modern WebP and HEIF. Moreover, it doesn’t support transparent images.

GIF. A 31 years old format for animated images compression. It’s widely supported by browsers. GIF supports only 256 colors. It also supports transparency, but usually, the quality is awful because of 256 colors.

Sounds depressing, isn’t it? Don’t upset, there is a hope when WebP will be supported by all major browsers, we will forget this as a terrible nightmare. Currently, Blink is the only browser engine, which supports WebP image format. However if we will look at relative usage we will see that 73% of global Internet users can see WebP in their browsers. WebP surely worth it.

Convert to WebP

There are thousand ways to convert your existing images to WebP. To do it manually on MacOS you can run following commands:

brew install webp
cwebp -q 90 image.png -o image.webp

But it really depends on your platform and image library. I can’t name all possible options. For my web service, I’m using Node.js and ImageMagick for this.

nginx

On this step, I’ll help you configure a nginx web-server in the easiest way to support WebP.

First of all, you should put your new WebP images near to your old JPEG/PNG/GIF images, they should have the same name but with .webp extension. Then let’s change a nginx configuration. We need to change http section, usually, you can find it in the /etc/nginx/nginx.conf file, add the following config there:

http {
    # ...

    map $http_accept $webp_ext {
        default "";
        "~image\/webp" ".webp";
    }

    map $uri $file_ext {
        default "";
        "~(\.\w+)$" $1;
    }

    # ...
}

Also, we should make a location for our images in a server section. Usually you can find a server section in the /etc/nginx/conf.d/default.conf file, but it can depend from your basic nginx configuration.

server {
    # ...

    location ~* "^(?<path>.+)\.(png|jpeg|jpg|gif)$" {
        try_files $path$webp_ext $path$file_ext =404;
    }

    # ...
}

And finally please ensure that your /etc/nginx/mime.types file contains the following line:

image/webp webp;

If not, you should put it there manually. So nginx will know which Content-Type header it should send for files with .webp extension.

And that’s all. Now you can point any of your images normally. If it has corresponding WebP version and a current browser supports WebP nginx will return the WebP version. In any other cases, the legacy format version will be used.

How it works

It works really nice, but what’s under the hood? For every request nginx creates two variables $webp_ext and $file_ext

1. $webp_ext equals .webp if current browser sends image/webp in the Accept header. Or it equals empty string otherwise.
2. $file_ext equals file extension (e.g. .png) of current URI if current URI has it. Or it equals empty string otherwise.
3. In the location for images, the $path without extension is captured from incoming URI. And after that nginx tries to find a WebP version by concatenating $path and $webp_ext variables. If the file doesn’t exist nginx will try the next $path and $file_ext.

You will see a legacy file extension in the URI whether it’s WebP or not, but browsers are okay with that because nginx sends correct Content-Type for WebP files.

That’s the secret.

I would be glad if this post helped you with the basic concept of how to make your website WebP ready and keep it compatible with all browsers. In my case, the main page of my website decreased from 1,6 MB to 900 KB. That’s a significant difference. People with bad Internet connection will be happy.

Useful links

1. The official WebP website
2. JPEG vs WebP and PNG vs WebP comparison.
3. Browser support