Serg Hospodarets Blog

Serg Hospodarets blog

Front-End frontiers
Serg Hospodarets
Posts tagged ‘Browsers’.
Show all posts
Finally the Promise.prototype.finally() is available

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!

...
Read full post  >
Native ECMAScript modules: nomodule attribute for the migration

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.

...
Read full post  >
Native ECMAScript modules: dynamic import()

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.

...
Read full post  >
Web Share API brings the native sharing capabilities to the browser

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.

...
Read full post  >
Native ECMAScript modules: the new features and differences from Webpack modules

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.

...
Read full post  >
Native ECMAScript modules - the first overview

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.

...
Read full post  >
Node.js debugging with Chrome DevTools (in parallel with browser JavaScript)

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.

...
Read full post  >
Progressive Web Apps: How to migrate to HTTPS

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).

...
Read full post  >