Serg Hospodarets Blog

All the modern browsers support native JavaScript modules, and it’s a perfect time to start using them, which will change the way we are bundling the JavaScript using Webpack, Rollup, and other bundlers, and how the code is executed.

We will take a look how they work, what is the level of support in the browsers and Node.js, plus main findings and gotchas on the way of publishing and using them in production.

Looking into examples, we will understand the native modules features, performance details and lazy loading JS modules techniques.

Today CSS Custom Properties are supported in all the major browsers.

Now it’s time to do the next step- to have an ability to register new Custom Properties from JavaScript and setup the browser how to work with them (e.g. real CSS polyfills). They should work with the same performance as the native CSS properties, being animatable and aligned with CSSOM.

Custom Properties can be used as a bridge between CSS and JavaScript. Houdini Task force introduces specs and JavaScript Worklets to expose the interaction with previously fully internal browser rendering mechanisms (during Paint, Layout, Composite stages).

All this brings Front-End development to the next level, parts of which are already available for the developers.

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!

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.

All the major browsers shipped the native JavaScript modules support out of the box:

which means, the time we can use them without module bundlers/transpilers has come.

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.

Recently Paul Irish described how you can debug Node.js applications with Chrome DevTools.

Since that time Chrome DevTools have evolved and the step, where you had to open the separate page with a specific URL to debug the Node.js code, was removed.

It means, today you can debug your browser JavaScript files and Node.js ones in the same DevTools window in parallel, which makes the perfect sense.

Let’s take a look how it works.

This is the first of articles where I want to describe how to migrate/extend your web app to being a Progressive Web App

Main points of a Progressive Web App are:

• it’s secure (uses HTTPS)
• app install banners give users an easy way to add the app to their home screen/launchpad
• service worker makes the app load nearly instantly and work offline
• application is responsive (phones, tablets and laptops)
• ability to send users web push notifications
• smooth and great user experience

Let’s start from the first item and add security (HTTPS).