By Aurelio De Rosa

3 New JavaScript APIs You May Want to Follow

By Aurelio De Rosa

If you’re a frequent SitePoint reader and perhaps a follower of mine, you’re aware that I’ve written a lot of articles about HTML5 and JavaScript APIs. So far, I’ve published articles discussing APIs that you can start using today, even if with the use of a polyfill.

Today I’ll break this habit by giving you a preview of some APIs that are still at a very early stage. To give you an idea of how cutting edge these APIs are, consider that 2 out of 3 were announced just few days ago. Because of this, the bad news is that none of them can be used right now. However, if you’re interested in what they do, you may want to follow the development of the specifications and maybe provide your feedback.

Without further ado, let’s start!

Web Alarms API

The Web Alarms API provides access to the device alarm settings, which can schedule a notification or for an application to be started at a specific time. The typical use case for this API involves applications like alarms, calendars, or any other software that needs to perform an action at a specific time.

Starting from last year, this API is a W3C Working Draft. So, the specifications are at the first stage of the process to become a W3C Recommendation. This API is exposed through the alarms property of the window.navigator object. The alarms property offers three methods:

  • getAll(): Retrieves all the alarms added to the device as an array of Alarm objects.
  • add(): Registers an alarm based on a Date object and returns an AlarmRequest object.
  • remove(): Removes a previously added alarm based on the unique ID (unique within the application origin).

Just to give you an idea of how you could ideally call these methods, here is an example that adds an alarm (remember that at the moment this code won’t work in any browser):

var alarmId;
var request = navigator.alarms.add(
    new Date("June 29, 2012 07:30:00"),

request.onsuccess = function (e) {
    alarmId =;

request.onerror = function (e) {

Then, if you want to remove the same alarm, you can write:

var request = navigator.alarms.remove(alarmId);

request.onsuccess = function (e) {
    alert("alarm removed");

request.onerror = function (e) {

If you want to learn more about the Web Alarms API, take a look at the specification.

Presentation API

The aim of the Presentation API is to make secondary displays such as a projector or a connected TV available to the web, and takes into account displays that are attached using wired (HDMI, DVI or similar) and wireless technologies (MiraCast, Chromecast, DLNA, AirPlay or similar). What this API does is to enable an exchange of messages between a requesting page and a presentation page shown in the secondary display.

Please note that the specifications aren’t a W3C Standard, nor on the W3C Standards Track. This API is exposed through the presentation property of the window.navigator object. The property provides one method, called requestSession(), and two events, present and availablechange. requestSession() is used to launch or resume a presentation on a secondary screen. It returns a session object which represents a handle to the current presentation session. When the content denoted by the url passed to requestSession() is loaded, the page on the presentation screen receives the present event. Finally, availablechange is fired when the first secondary display becomes available or the last secondary display is removed.

An example, taken from the specifications, that employs this API is shown below:

<button disabled>Show</button>

var presentation = navigator.presentation,
    showButton = document.querySelector('button');
presentation.onavailablechange = function(e) {
  showButton.disabled = !e.available;
  showButton.onclick = show;
function show() {
  var session = presentation.requestSession('');
  session.onstatechange = function() {
    switch (session.state) {
      case 'connected':
        session.onmessage = function() { /*...*/ };
      case 'disconnected':

In case you want to learn more about the Presentation API, take a look at the final report.


Standby API

The Standby API allows you to request a screen wake lock on a top-level browsing context. This prevents the device from entering a power-saving state (e.g, turning off the screen). This ability is crucial for several web applications. For example, imagine you’re driving your car and you’re using a web-based navigator (not a native application) on your smartphone. If you don’t interact with the screen, unless otherwise specified in the settings, the screen of your device will turn off. In such cases, however, you do want your screen to stay awake. This is exactly where this API comes into play.

The Standby API is exposed through the wakeLock property of the window.navigator object. It provides two methods:

  • request: Causes the underlying platform to keep the screen in active state.
  • release: Releases the wake lock, so the screen will no longer be kept awake.

Both these methods accept just one argument that can be either "screen" or "system". The former is used to target the device screen, while the latter to target other device resources like the CPU or the radio (but not the screen).

An example that shows how to use this API to request the screen to stay awake is shown below:

    function successFunction() {
        // do something
    function errorFunction() {
        // do something else

To allow the screen to turn off, we can write the following statement:


If you want to learn more about the Standby API, take a look at the unofficial draft.


In this article I’ve introduced you to some brand new JavaScript APIs. Once again I want to highlight that because they are all in a very early stage, no browsers support them. Therefore, we can’t play with them. However, being so new you have the chance to follow their development and even contribute to the specifications.

The future of web development is bright, be part of it!

  • Sjors van Dongen

    Finally some API’s I didn’t knew about, very cool!

  • Nice post!

    • Aurelio De Rosa

      Thank you :)

  • Venkata Panga

    Excellent Introduction on new API(s), thanks for sharing!

  • excellent Introduction, thanks for sharing!

    • Aurelio De Rosa

      Hi William, I’m glad you liked it.

  • CTN

    do not like

  • Thanks for Sharing…

  • Good stuff. Now get it up on HTML5-API-Demos! :) (for anyone that hasn’t seen it).

  • Nik

    “For example, imagine you’re driving your car and you’re using a web-based navigator (not a native application) on your smartphone.”

    This is not a good example, no one should drive and operate a smartphone simultaneously.

    • Tchael Clark

      People use GPS on their phones to drive all the time. You set your target destination, start it, and leave it on a stand. You are not operating it while driving, you took care of that beforehand. The problem with this is that the phone will go to sleep, requiring the user to interact with the App. Making it dangerous to use. The API proposed would allow the browser to tell the phone to not go to sleep, because it is still doing something. This means the driver won’t have to interact with the phone, making it safer to use.

      This isn’t an issue if you use a native app, such as Google Maps on Android. The App will keep the phone from entering a sleep state – but not everyone wants to use Google Maps, perhaps even for privacy concerns. So they might turn to a web alternative that doesn’t have a native app. Then you have the problem listed above.

    • Tom

      That example is probably referring to having a map open on your phone. Having a GPS app on while driving is not really a bad thing. And this API would prevent the user from needing to interact with the screen every few minutes, which makes it safer.

  • Aurelio De Rosa

    Thank you for mentioning my repo :)

  • These JS API intro articles are very awesome! Keep up the good work!

  • Falak

    JS giving more control on devises !! very useful. thanks for sharing

  • Dug

    You state the Standby API methods accept just one argument that can be either “screen” or “system”. However, the examples that followed used “display” as arguments – I believe those examples are incorrect.

    • Aurelio De Rosa

      Thank you for the feedback. I’ve notified the editor to fix the error.

Get the latest in JavaScript, once a week, for free.