Serg Hospodarets Blog

How often have you applied the JavaScript or CSS solution considered as an optimization, and after couldn’t find an easy way to measure how effective it was?
Of course, you have the performance timeline recording, but in most cases, it provides the retrospective data, not the life-updated.
For this and other performance-measuring techniques, Chrome DevTools added the “Performance Monitor” tab which represents the real-time app performance metrics:

Since the Promises were added in JavaScript, one of the biggest concerns was the absence of an ability to easily apply some code after the Promise is fulfilled (after both success and reject actions). There are many examples of such a need: showing a loader when the request to the server is in flight or even a simpler case- when we just want to log the completion of the operation regardless of how it finished.

Previously we had to include the function in both “on-success” and “on-reject” sections, which resulted in the code overhead and clearly showed the need of something like other libraries have, so meet the Promise.prototype.finally!

Overview of CSS Custom Properties syntax, their abilities and use cases.

A practical guidance of the different approaches of using CSS variables, interaction with JavaScript and migration options.

In one of my previous articles Native ECMAScript modules: the new features and differences from Webpack modules we attempted to detect if the browser supported ES modules. We needed this to determine either, to execute a bundled (classic) file or a script which uses the native ECMAScript module features.

We managed to achieve this, but in reality how it was achieved isn’t ideal. The community have since come together to propose an alternative, the nomodule script attribute.

In the previous article Native ECMAScript modules: the new features and differences from Webpack modules we understood the differences between ES modules and their implementation in bundlers/compilers like Webpack/Babel. So far we found couple gotchas and know how to use the import \ export declarations and which caveats we may have using them in JS.

But JavaScript went asynchronous many years ago, and it is a good practice is to use non-blocking Promise-based syntax for modern Web applications. ECMAScript modules are static by default: you have to define static import/exports on the top level of the module. It is very helpful to apply JS engine optimizations but doesn’t allow developers to apply the best practices of asynchronous module loading.

Meet the dynamic import() operator, which adds the missed functionality and follows the best practices of Promise-based API.