The complexity of Front-End applications grew past years extensively. That’s the reason big monoliths started being split to separate UI and modules working with different API. After years of using custom solutions and confusion around Micro Front-Ends, we are in the new era of the native support of Module Federation in Webpack 5, and tools, such as Storybook components system, SPA, and others switching to the common standard.

But this gives the tool to build apps which can work with specific microservices, and behind there are different topics- which use cases micro apps are useful for, what about coordination of shared modules interaction, their promotion and deployment of the newer versions, how they scale, how teams and work can be organized.

In this talk, the above areas will be discussed, and together with the live demos, you’ll learn about the current state of the art.

Talk recording is here

Here is the presentation deck

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.

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.

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