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!

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.

For many years the Web is moving towards the parity with the Mobile native applications and adds the missed features. Today browsers have most of them, from the offline mode and enhancements with the Service Workers to Geolocation and NFC.

The one huge ability, which is still missed, but highly used in the mobile applications- the ability to share a page, article or some specific data.

The Web Share API is the first step to fill the gap and bring the native sharing capabilities to the Web.

In the previous article Native ECMAScript modules - the first overview I described the history of the JavaScript modules and the current situation with the native ECMAScript modules implementation:

For now, we have 2 available implementations, which we tried and compared to the bundled module.

The main takeaways, so far, are:

1. To execute a script or load an external file and execute it as a module use <script type="module">
2. .js extension cannot be omitted in the import (the exact URL should be provided)
3. the modules’ scope is not global and this doesn’t refer to anything
4. native modules are in the strict mode by default (not needed to provide 'use strict' anymore)
5. module scripts are deferred by default (like <script type="text/javascript" defer />)

In this article, we are going to understand other differences with the bundled modules, abilities to interact with the module scripts, how to rewrite Webpack modules to native ES ones and other tips and tricks.

The 2016 year was incredible in terms of the browser and Node.js applying the ECMAScript 2015 specification. Now we are facing the situation when the support amongst them is close to 100%:

But the standard actually introduced also ECMAScript modules (today also often named ES or ES6 modules). It’s the only part which took (and still taking) the most time to implement as none browser published it yet in the stable version.

Safari and Chrome shipped the native implementation out of the box, Firefox and Edge have it behind a flag, so the time we can use this without module bundlers is coming.

To understand better how we come to this point let’s start from the JS modules history and then take a look at the current Native ES modules features and implementations.

Scrolling effects are increasingly popular these days.

Scroll snapping is used widely for a better separation of the provided content (vertical full height pages) or, for example, to emulate galleries behavior.

There are many popular plugins (fullPage.js, jQuery.panelSnap, jQuery Scrollify etc.) which provide such functionality.

Can you imagine how easy would be creating such effects using CSS only?

Meet the CSS Scroll Snap Points specification!

Demo

Recently the ability to record a Filmstrip was added to Chrome.

Now it’s available in Canary and Dev Channel versions of the Chrome Browser as DevTools experiment and is supposed to be enabled by default in one of the next versions of Chrome.

To enable it:

• Open chrome://flags/#enable-devtools-experiments page in Chrome and activate the “Enable Developer Tools experiments” flag
• Reload Chrome
• Open the DevTools Settings
• Select the “Experiments” tab
• Press “SHIFT” button 6 times 😉 to show hidden DevTools experiments
• Check the “Filmstrip in Network and Timeline Panel” checkbox
• Reload (open/close) the DevTools
• In the “Timeline” check the “Screenshots” checkbox

The idea

Once I needed to add component to show controls like the following:

The number of sections in it had to be configurable. To do it usually you can add two config variables: one in Sass, one in JavaScript.

But I wanted to have config only in one place and reuse it in the second. That’s how the idea to pass data from Sass to JavaScript came to me.

Demo

Frequently we want to add scrolling to some part of the page or box. E.g. to highlight something or just scroll to an anchor.

To provide better UX and feeling usually smooth scrolling is used.

Previously to implement it we had to use plugins like “jQuery.scrollTo” or similar solutions.

But dreams came true- there is a specification for native smooth scroll behavior API.

Demo

Google Analytics is the most popular website statistics service. It is used for many purposes: from tracking visitors and sessions to campaigns and events.

Ability to track any events provides us possibility to send and track any data in Google Analytics. One of the most useful in that case for web developers might be errors analytics.

So far Google proposes 2 ways of tracking events:

1. Classic ga.js with the for tracking like _gaq.push(...)
2. Newer analytics.js has syntax ga('send', ...) and is part of the new Universal Analytics

Let’s provide JavaScript, AngularJS and jQuery errors checking.

In short, Fetch API- it's a new Promise- based standard for doing AJAX requests.

Syntax for XHR was provided more then 10 years ago (XMLHttpRequest2 - about 4 years ago).
Many things changed, we got HTML5, CSS3, also close to start using EcmaScript 6.
From jQuery Deferred, $q and Native JavaScript Promises people became familiar and like promises in JS.
It’s time for new laconic API to do AJAX-requests and interact with them.
And time is come!

About CSS filters

The CSS filter property provides the way to modify rendering for elements in the browser. You can use it to apply visual effects like blur or shifting colors. There are many ways to use it- from providing Instagram/PhotoShop- like filters to the site themes.

Demo