In our previous article about JavaScript APIs, we reviewed some APIs designed to enhance a variety of areas: virtual reality, real-time communication, web and service workers. Now let us concentrate on the JavaScript language and web applications.

Firstly, we will have a look at development languages such as Elm and ECMAScript, before focusing on web application thinking. This last chapter compiles some concepts, technologies and techniques (service workers, communication from client to server via Fetch, Promise, UI/UX, etc.) for creating Progressive Web Applications which are reliable, fast and engaging — almost like a natural app.

Welcome to a brand new world where native apps and web apps are complementary!



Elm is a purely functional and immutable language that compiles to JavaScript, written in Haskell. It is typed, recursive, and quite easy to test.

It is also an architecture, a framework which uses a virtual dom and provides a very fast JavaScript.


• Type checking and functional / immutable programming: higher quality code and static types are an excellent way to document systems.

• Virtual dom & Elm-html : Elm reshapes web programming. Such a package gives you access to HTML and CSS and, therefore, to the creation of new abstractions. HTML and CSS constitute the basic building blocks for nicer abstractions. Demo here

• By default, Elm includes some of the main React packages (Redux, Flux…).

• Easy install and easy use: NPM comes with its own package manager. Compiler is friendly, and provides detailed solutions to existing problems.

• There are Elm syntax highlighters for popular text editors and IDEs.

Elm-reactor: a built-in tool to create and test Elm components and applications rapidly.

• Easy to integrate into existing code: all your components can be compiled into one single bundle. Plus, there are three different ways to embed components and applications.

• Modularity: with Elm, you can ensure that people write code in the right way, since its core strategy is to hide implementation details. When creating a widget, Elm allows you to expose the exact API you want.


• Not that popular yet, leading to limited bug reports and fixes.
• No stable version: the underlying architecture of libraries might change with every new release.


You can give this benchmark a try.

It allows you to select the framework / pseudo language you want to benchmark. Furthermore, duration and memory allocation are rated. Scripts are run as keyed and non-keyed.


As an original inspiration for Redux, Elm is a very interesting language. It offers the componentized view and reactiveness of React.js. It is also functional and strongly typed.

You should definitely examine this framework. Thanks to its interoperability with JavaScript, you can even use it in the completion of existing projects.


ECMAScript is a specification aimed at standardizing JavaScript.

The 8th edition of the ECMAScript language specification brings several improvements to the language. Indeed, it introduces Async Functions, Shared Memory and Atomics along with minor language and library enhancements, bug fixes, and editorial updates:

Async functions improve the asynchronous programming experience by providing syntax for promise‑returning functions.
Shared Memory and Atomics introduce a new memory model that allows multi‑agent programs to communicate using atomic operations that ensure a well‑defined execution order even on parallel CPUs.

Some methods have been added to Object and String :

• String padding : String.padStart / String.padEnd

Among these techniques, Async function is probably the most interesting feature. Promises and generator functions operate together: when an async function is called, it returns a Promise. Generators give us the ability to pause a function, wait for an asynchronous operation to end, and then jump back in to continue execution.

The Babel JavaScript compiler already supports a certain part of these features.

Quick reminder: Babel compiles JavaScript in order to have a script using last developments of this language and in order to have a script running by all browsers.

Finally, ECMAScript 2017 is fully supported by browsers and by Node.


A new way to deliver amazing user experiences on the web”— as defined by Google

This sentence and the term “Progressive Web App” (PWA) — a term Google coined —  encapsulate what PWA is all about: building truly large applications with web programming languages.

Here, some keywords essential to defining PWA :

Mobile-first: The mobile user’s needs and context are considered separately from a desktop user. By using mobile design patterns, PWAs are truly mobile-first (and not just responsive).
Reliable & offline-first: PWA loads instantly, even in uncertain network conditions. This way, offline mode ensures that users can stay and use your PWA at any time.
Fast: Thanks to smooth animations and no basic scrolling, user interactions are very fluid.
Engaging: PWA provides with a more immersive experience than a classic website. Web push notifications can engage users in real time, based on their behavior or location (geofencing). For an ecommerce app, these benefits lead to higher conversions.

One can safely assume that PWAs are the next evolution for apps and browsers.

Unfortunately, the current app ecosystem comes with some disadvantages:

• Detour via an app store to access apps.
• Large-sized files often consume on-board device storage.
• Many apps stealing personal data and/or running up data charges without permission.
• Difficulties to find apps in the app stores.
• Creating and maintaining an iOS + an Android app is more expensive than a PWA (which uses the same programming language, for the same team).

In contrast, it offers many advantages: fast performance, offline use, push notifications and other specialized functionalities.

Finally, PWA could merge the best of both worlds.

Here, you can see all features available in your current browser.

There are some concepts and methods to know about before building a PWA and particularly its interface.


It is a design approach where the basic shell of an app UI is loaded first, right before its content. With this model, app UI and content are cached separately. Application shell improves the user’s perception of the performance and usability of the app. An app shell means minimal HTML, CSS and JavaScript, aiming at powering the user interface.

Original source

An application shell architecture is founded on Service Workers.

This architecture is particularly attractive for web apps characterised by a lot of dynamic content requiring frequent updates.


Offline is a non-threatening reality in which some aspects of an app will necessarily stop working. But many others won’t such as communication, access to information, data aggregation, etc. The latter must be managed through the app in case the user is offline.

But what is the end goal of this offline-first feature?

Use at any time, all the time, an app which works faster with cache, no data loss for the user, etc.

To manage offline state, you will need to cache static (js /ttf / css / …) and dynamic (json / csv / …) assets. Preparing UI is also very important.

This schema ultimately summarizes the running:

Original source

As ever, Service Workers constitute a vital part of the whole offline architecture.


In UX / UI, design patterns are a collection of interface elements. Familiar to users and reusable in many design problems, they are divided between structural, creational and behavioral patterns.

Color match, utilization of space, compatibility with different screen sizes, and progressive presentation are the key design points to focus attention on.

Here are some common web application design patterns:

• Navigation (label / carrousel / list / etc.)
• Form (login / registration / search / …)
• Table & List (grouped rows / editable table / cascading lists / …)
• Search, classification and filtering (autocomplete / saved and recent / search form / etc.)
• Graphics (charts / datapoint / zoom / etc.)

Here are few resources for design patterns.

A pleasant design tool can achieve maximum results with little effort. Consequently, the use of a web app when offline should result in a better, less frustrating and more empowering experience.

Requesting data, managing cache, making a PWA visible on the home screen of a mobile device; all these features require the use of some APIs.

Please find below a list of the fundamental APIs to build a PWA:


The Fetch API aims at replacing XMLHttpRequest as the foundation of communication with remote resources. It provides a fetch() method defined on the window object. As seen above, this method returns a Promise. Fetch delivers the hindsight, and is much saner and simpler to use than XHR, in addition to being more asynchronous.

However, this API is much more than fetch() method.
You can explicitly configure request objects (that is, from a previous one with different use case). Headers objects can be manipulated explicitly, and you can access (read-only) the response headers.

Moreover, you can also create a Response object (useful for offline mode, where Service Workers intercept HTTP Requests from the browser and supply with response that will be locally built).

Here is the browser support for Fetch API, and here is the polyfill.


Asynchronous storage APIs such as IndexedDB, WebSQL or localStorage are required to manage offline storage. In order to achieve this need of data storage in browser, one should use Local Forage API, a wrapper (IndexedDB, WebSQL, localStorage) that provides a simple and powerful API by loading and managing drivers. The best driver is chosen depending on the browser used for PWA.

WIth the very simple localStorage syntax, the API unifies asynchronism and blob support from IndexedDB and WebSQL. The inclusion of these last APIs allows the storage of more data than localStorage alone would allow for web applications.

More about the project on the official page.


WIthout Service Workers, it is simply impossible to build a true PWA.

We have already covered this topic in our article about JavaScript APIs, with a dedicated chapter that you can read here.


The aim here is to install web apps to the mobile’s home screen with a native install banner.

To achieve this, two basic requirements are needed:

1. A manifest.json file, with two mandatory fields:

a. Short_name: text on the home screen.
b. Name: in the PWA install banner.

2. A meta is required on all pages that encompass your PWA :

<link rel= »manifest » href= »/manifest.json »>

Subsequently, you can set a start URL with string parameters, customize the icons and specify the initial orientation of the page.

Here is the complete reference to the web app manifest.



The following examples will enable you to get a better idea of its full potential:

Financial times: Posts and comments from the Financial Times.
JW Showcase: Video website builder (html5 video).
Land Lines: Landlines to write and save, run offline.
Dscova: Find new experiences in your local area, through a collaborative approach.
Trivago: Search and compare hotel prices.


The emergence of Progressive Web Applications goes together with evolution of the Internet. New web APIs, design patterns, marketing fluff, etc have been designing the future of apps, with web apps running everywhere with known technology stack.

The phenomenon is also very exciting for UI / UX designers. As a matter of fact, PWA (as with the native application) arouses considerable users’ expectations while creating a striking design with design patterns is not that easy. Never forget your mission: reach maximum results (web conversion, user experience) with little effort, and empathize as much as possible with your users.

For offline-first, what is crucial is to specify what should be put offline. For instance, content can be too voluminous to be preemptively cached. In addition, displaying data chronologically (like on online chats) does not make so much sense. Indeed, the most recent data transmitted is not necessarily the newest.

PWA can operate most things mobile applications do. However, it is still in development stage, and then presents a light risk. And yet (fortunately), web developers have never awaited for things to be totally secured for an official green light.

All of the tools listed above are already available. Service Workers are supported by Chrome, Firefox, Chrome for Android, Opera (not Opera Mini though) and partially by Android browser.

This whole new perspective is full of exciting expectations, on which rely the future of the Internet — even if it may not be instantly ready for a large-scale website steering. Moreover, the PWA approach in a large project (publication / data visualization / messaging / intranet / etc.)  also requires the division and regroupment by bricks of all needs.

With PWA, the process contains three progressive stages: from a large ecosystem, to little bricks (PWA), to catering for final users.


Well, after all… What do we need?

We need to publish content, share and visualize data, communicate within a team, etc.

And what do we want ?

We want to drive the web forward, contribute to innovative projects for all. We want it to be fun of course, but also a source of learnings and growth.

All the tools we have introduced here: app shell, UI / UX for web applications, background task (Web, Share and Service Workers) — now, JavaScript developments enable you to tread this promising path.

With interesting stack and precaution, we have the power to build web applications for both traditional and innovative needs. All APIs and tools are available while the language will logically follow next. Browsers and devices are becoming less and less of an issue.

Our final words? Let’s build our bricks!