Superpowers of Browser’s Web API

Rate this content

When writing code for the Web, there are a lot of capabilities that are offered out of the box by our browsers. If you ever wrote a File Upload component, used timers and intervals, interacted with the DOM, or stored something in the Local/Session Storage, you had to go to the MDN’s Web API docs, to find some relevant information on how to implement that code.

In this session, we will delve into the exciting world of browser Web APIs that are not so commonly used (although they should be) and explore their incredible capabilities 🚀

All these features offer new opportunities for creating immersive web experiences that can help businesses grow and connect with customers.

So if you are the kind of an engineer who wants to stay ahead of the curve when it comes to web development, learn how Intersection Observer, Background Sync API, Screen Wake Lock API (and many more) can help you create better web applications that will keep users engaged and coming back for more!

23 min
23 Oct, 2023

AI Generated Video Summary

Today's Talk explores various Web APIs and their functionalities, including the Intersection Observer API for element visibility, the Network API for connection detection, and the Background Sync API for offline capabilities. The Broadcast Channel API enables communication between components and the Beacon, Web Speech, Web Share, Screen Awake Lock, Page Visibility, Background Fetch, and Web Authentication APIs offer additional functionalities. These standardized APIs work across browsers and can improve performance while reducing electricity consumption.

1. Introduction to Web APIs and Astronaut Example

Short description:

Today we're going to talk about Web APIs and their functionalities provided by the browser. We can leverage these built-in interfaces to enhance our web applications. Let's explore some new or not-so-well-known APIs that offer superpowers. I am Nikola Mitrovic, a Development Lead and Software Engineer at Vega IT. In our first example, we have a page with a small astronaut who displays a message when fully visible while scrolling.

Hi React Advanced London! Welcome to today's talk. I wish you a warm welcome. Today we're going to talk about something called Web APIs. But before we do that, we need to take a small step back and go to some JavaScript basics.

Probably this is a classic interview question and if I ask you what is the answer most of you would answer the order of these logs would be 1, 3, 2, right? But how do you know that? How can we know that? So let's visualize this example a bit and check it out.

So as we know, there is a call stack. Our engine starts to execute line by one. Console.log is asynchronous and it's executed immediately, but the set timeout is asynchronous, so it needs to go around a bit. It waits for a number of milliseconds that we put in a callback. It goes in the queue. We wait for the call stack to be free again, and then event loop kicks with the value that we put inside of the callback. But the question is, where does setTimeout wait for those number of milliseconds? And the answer is, WebAPI. If you're a curious engineer as I am, you might ask at that point, OK, what is the WebAPI? And if we Google a bit, we can find out that there is MDN documentation about WebAPI, and the setTimeout is under the tab, WebAPI. If we check there, there we can see that there are a number of available functionalities that browsers offers us out of the box. And if we explore a bit there, we can find a lot of well-known APIs. Like, for example, if you ever built a file upload component, if you ever used geolocation, if you ever communicated with a DOM alters on DOM elements, if you local storage, session storage. So all of those APIs are functionalities that are provided by the browser. Of course, there are some well-known APIs and some well-known functionalities that you're using in day-to-day work. But I was wondering what are some of the new or not-so-well-known APIs that we can leverage in our web applications and really use these super powers? So we can conclude that WebAPI is a collection of those built-in interfaces that we can use just by using the browser.

First, I will just introduce myself quickly. My name is Nikola Mitrovic. I work as a Development Lead and Software Engineer at Vega IT, based in Novi Sad, Serbia. And these are my WebAPI highlights for you for today. We go to our first example for today. So let's say we have an application like this. We have a page. When we scroll down a bit, then we start noticing that there is a small astronaut at the bottom, in the corner. And if we scroll a bit more, once the astronaut is fully visible, he says, Hello World. If we scroll a bit up and the astronaut is not fully visible, the message goes away. If we scroll down a bit again, he again says, Hello World.

2. Using the Intersection Observer API

Short description:

The Intersection Observer API helps determine if an element is visible on the page by checking if it intersects with the viewport. In React, we can create a hook called UseVisible to observe elements. This hook takes a reference to the element and a configuration object for the Intersection Observer. We can set the margin and threshold for intersection. By setting the threshold to 1, we observe when the element is fully visible. The hook returns a state variable, isVisible, which indicates if the element is visible or not.

Okay, how did we manage to do this? There is an API called Intersection Observer API, which basically figures out if the element is visible on the page or not, if it's intersecting the viewport. If we're doing this inside of a React, we would probably build a hook, lets call it Use Visible and the code looks like this. The hook accepts two parameters, one is the reference of an element that we're trying to observe and there is a configuration object for the Intersection Observer. That configuration object may have the ancestor of the target, if we pass the null, then we are assuming that we are using the viewport as a parent element. We can set up the margin around that element and call that intersection a little bit earlier, and there is a threshold which is a number from 0 to 1. Because we set it to 1, we observe when an element is fully visible, so we can intersect let's say at a half of the visibility. We would have some state isVisible of course, and then we instantiate an intersection observer object. Inside of a callback we would get entry object, and that entry is having a property called isIntersecting. So basically, based on that, we can figure out if element is visible or not, that value would be true or false. What's left to do is just to observe that element. And then at the end, of course, we set the state and returning it back, and we would get from that hook just true or false state.

3. Real-Life Use Cases and Browser Support

Short description:

We can use the Intersection Observer API in real-life use cases such as lazy loading images, creating infinite scroll lists, and deferring animations. It is important to consider browser support, but in this case, all major vendors support this API.

This example with Astronaut was cute and fun, but you're probably wondering how can we use this API in some real life use cases. We could use it to lazy load images. So for example, we can only load what's important to load initially for the app. And we can offload and lazy load images. Once we scroll back to some certain section that contains images.

We could create infinite scroll lists. So we don't need a library for this. For example, we can have a list of 10 elements and we can have the end of the list element. And once we scroll and that element is visible, it means that we came down to the end of the list and then we can trigger the next request. We could defer some animations. We don't need to run some animations if they are not visible on the screen, and in that sense, we can save some computer power.

One of the things that we should always consider when using some of these web APIs is browser support. So all major vendors support this standard of web APIs, but not all of them are implementing, have that implementation in place. But in this case, we can see that all major vendors support this API, so we're good to go and we can use this and leverage this inside of our web applications.

4. Using the Network API and React Hook

Short description:

In the next example, we have an app called that communicates with NASA's API to provide a list of habitable exoplanets. We can search for a planet and reserve a flight. The Network API helps us detect system connection changes and react accordingly. By creating a hook called UseNetwork, we can check the connection type and return the state. We can also track network changes and execute state changes. Use cases include user notifications and preloading resources. Chrome-based browsers support this API, but Firefox and Safari do not.

Now we move on to the next example. Here we have a little bit futuristic app called which translated to English means spaceman. It's an app that if we go to in the backend we're communicating with the NASA's API which is returning us the list of all possible exoplanets, habitable exoplanets. And then we can go and search for a planet which we want to visit for a vacation or to enjoy ourselves and for example there is this TOI-1136G, that sounds amazing, we always wanted to go there and then we can click to reserve a flight to that planet. After some time the flight is reserved, but what if we have some connectivity issues? So we try to reserve a flight and that request is taking a bit long. After some time we can display a message to have some better UX or something and once the fast connection kicks in we can move that message away. So note that it's not just about the time of the request, it's also about reacting to the network changes. So how can we do this? There is an API called Network API of course which provides information about the system connection and also detects connection changes that we just seen. If we are building this in React, we would probably make a hook called UseNetwork. We would have the state which represents if the network is fast or not. Then we check for the connection object inside of a navigator. I'm going to get back to this why this is important but if there is a connection object, there is an EffectiveType object on that connection object and then we can check the value of that EffectiveType. The possible values of that EffectiveType are Slow2G, 2G, 3G, and 4G. Then we can assume if it's 4G then, okay it's a fast network, if it's something otherwise, we consider it as a slow network. And we just return that state from the hook. As we noted before, we can also react to the changes to the network. So again we go to the connection object inside of a navigator and add EventListenerChange so we can track those network changes. Once there is a change we can again execute a state change. What are some of the use cases? Of course, some notifications to the users or preloading large resources. This is important for the performance, so we can check if the network connection is fast. If it's fast, then we can preload some bigger resources. Again, if we look at the browser support for these ones. Okay, now here the situation is a little bit different. Chrome-based browsers support this API, but Firefox and Safari are not there yet, so we will have to wait a bit for this API to use it in all browsers.

5. Offline Application and Background Sync

Short description:

In the next example, we explore the scenario of an offline application. When trying to access a page that triggers a request to the NASA's API, nothing happens if we are offline. However, in the application tab, there is a background sync feature that registers an event when we go back online. This event triggers the request and returns the list of habitable planets.

Okay, moving on to the next one. Again, we have an example with, but in the previous example, we didn't cover one of the most essential use cases when using today's web applications, and that is what if our application goes offline? I know this is an app a few thousand years in the future, but let's say we still have connectivity issues sometimes. And if we try to go to that page, once we hover over this button, we're triggering the request to the NASA's API. But if we go to the network tab, there's nothing happening. So in normal circumstances, I would expect that there is a network request stunt, which failed, and I would see a red request here that failed. But here we can see that nothing happens. If we try to go to that page, we can see that there is a loader still loading the data, but we know that we're still offline. Interestingly, inside of the application tab there is something called background sync, and once I hover that button, you may notice that there was an event triggered here, and that is a registering event. Once we go back online, there is a dispatch event, and then we trigger the request to the NASA's API. Once the request has finished, then we have a third event called sync completed event, and now we get the list of all habitable planets that we had before.

6. Background Sync API and Offline Capabilities

Short description:

There is an API called background sync API that allows us to defer tasks in the background while offline. By registering a sync event based on a tag, we can continue with our request once the Service Worker receives the event. This API is useful for offline capabilities and tasks like sending emails. However, Firefox and Safari have limited support for this API.

Okay, how did we manage to do this? There is an API called background sync API, which provides a way to defer some tasks in the background while we are offline into a Service Worker. This is the component that we have on our first page with the link, and once we hover over the link, then we can register that background sync. Inside of a navigator there is a Service Worker object and there is a ready property. Once we get to that registration, then we can register that sync event based on a tag.

Now, this tag is important because we might have multiple events, multiple tasks running in the background while we are offline. And inside of a Service Worker, we just wait for the sync event and we check that tag name. If it's the same, then we continue with our request. Some of the use cases for this API, of course, offline capabilities or maybe if we want to send an email while we are offline, we already clicked the button. Browser support in this case, again, the same as before. We would have to wait a bit for Firefox and Safari to keep up with this.

7. Communication with Broadcast Channel API

Short description:

To communicate between a Service Worker and our components, we use the Broadcast Channel API. This API allows communication between the same browsing contexts, such as windows, tabs, frames, or iframes. We open a channel, connect to it, and use the postMessage method to send messages. Inside our component, we subscribe to the channel and listen for the onMessage event. This API has various use cases, such as detecting user actions and logging out in all tabs. It is supported by all browsers.

If you're wondering how did we manage to communicate between a Service Worker and our components, in the example before, so once we have established the connection, we would fetch our habitable planet. That would be a request to the NASA's API, and we extract the body from that response. And how did we manage to get that list to the component, to a React component? There is an API called Broadcast Channel API, which basically allows communication between the same browsing contexts, which means same window, tabs, frames, or iframes. The important part is that they are all on the same origin. And it goes two ways, that communication. How can we do that? We open a channel. We connect to a channel based on a name, and then there is a postMessage method on that object to send the message. And we can send any kind of structure or objects. Inside of our component, we subscribe to that very same channel, and there is an onMessage event, which will get us that data. Use cases for this API. We can detect some of the user action, or maybe we can log out in all tabs if we log out in our application. Browser support, in this case, is we're all good.

8. Cool Web APIs and Their Impact

Short description:

Today we explored some cool APIs like Beacon, Web Speech, Web Share, Screen Awake Lock, Page Visibility, Background Fetch, and Web Authentication. These standardized APIs work across all browsers and can improve performance by reducing the bundle size. It's important to consider browser and device support when using these APIs. Additionally, using web APIs instead of libraries can contribute to a greener web by reducing electricity consumption. Thank you for joining us today!

So we can use this feature inside of all browsers for all users, which is amazing. And since we have a limited time today, unfortunately, we would have to stop. But I'm going to give you some bonus points and I hope I intrigued you enough to investigate some of these cool APIs on your own.

So here are my highlights. There is a Beacon API which basically we use if you want to send a request, but you don't care about the response. The use case is some analytics. There is a Web Speech API, which can figure out our talk and even give us some diagnostics about certain words. There is a Web Share API, which helps us to share data between different devices. There is a Screen Awake Lock API, which prevents us from locking screen on our devices, despite of the personal preferences of that device. There is a Page Visibility API, which figures out if the whole browser, if the whole tab is visible or not. There is a Background Fetch API, which is basically similar to Background Sync, but if we are downloading some large resources and we go offline. And of course, there is a Web Authentication API, which is a brand new, shiny web API for password-less authorization and authentication, of course.

And some of the takeaways. We've seen that with some of the APIs, there is nonexistent existing browser support. So we still may have some challenges when using some of these web APIs. Some of them have experimental browser support, so they have some implementation in place, but it's maybe not production ready. Some of them have a device support, for example, like Screen Away Clock API. So there are some challenges, and we should be careful when using some of the APIs. But why should we do this, and why should we take this approach? Because it's standardized code, it's standardized code, it's standardized code. Probably I could not stress enough how important this is, especially in today's web development where we have a new library or new framework each week. This is kind of like a single source of truth. These APIs are standardized, and they work across all browsers the same from the code perspective. So that code is pretty much standardized and should not break anytime soon. Most of these APIs are easy to learn, they're not super complicated or something. And they can increase performance because if we adopt this mindset to use the APIs and not so many libraries, or build something on our own based on some of these APIs like we have seen for the infinite scroll lists, the bundle size of our app will be smaller. And that brings me to to my next point, why is that so much important, especially with the performance and bundle sizes. I wanted to talk a bit about our planet. If you're having 4 or 4 facial expressions right now, like, what? What are you talking about? Actually, when we build our application, we get a certain bundle of JavaScript, which we push somewhere to some server, those servers to some cloud providers, which are spread across the whole globe, and all those servers use a lot of electricity. In fact, so much that the internet is consuming 21% of all electricity on the world. Luckily for us, there is a website called Website Carbon Calculator, which figures out all of this stuff for us. Basically, it checks how green is our website. This is super important because I would really hate if we had to use to run for our lives and not to you know go to a vacation or enjoy ourselves. So, please be kind to our planet and using some of the web APIs and not using the libraries and increasing the bundle sizes are one of the many ways we can do this. If we join forces together, it doesn't have to be a big effort, but if we all join forces just a bit, we can all produce a big, big result in this regard. So, thank you so much for being with us today, I hope you like this talk. If you need a refresher, there is a QR code, which is the link to the slides themselves. At the bottom, there is a link to my GitHub, where you can check all the APIs, all the examples for yourself, run them locally, maybe tweak them a little bit. Let me know if you have some improvements, of course. And that would be it.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

TechLead Conference 2023TechLead Conference 2023
35 min
A Framework for Managing Technical Debt
Let’s face it: technical debt is inevitable and rewriting your code every 6 months is not an option. Refactoring is a complex topic that doesn't have a one-size-fits-all solution. Frontend applications are particularly sensitive because of frequent requirements and user flows changes. New abstractions, updated patterns and cleaning up those old functions - it all sounds great on paper, but it often fails in practice: todos accumulate, tickets end up rotting in the backlog and legacy code crops up in every corner of your codebase. So a process of continuous refactoring is the only weapon you have against tech debt.In the past three years, I’ve been exploring different strategies and processes for refactoring code. In this talk I will describe the key components of a framework for tackling refactoring and I will share some of the learnings accumulated along the way. Hopefully, this will help you in your quest of improving the code quality of your codebases.

React Summit 2023React Summit 2023
24 min
Debugging JS
As developers, we spend much of our time debugging apps - often code we didn't even write. Sadly, few developers have ever been taught how to approach debugging - it's something most of us learn through painful experience.  The good news is you _can_ learn how to debug effectively, and there's several key techniques and tools you can use for debugging JS and React apps.
React Advanced Conference 2022React Advanced Conference 2022
22 min
Monolith to Micro-Frontends
Many companies worldwide are considering adopting Micro-Frontends to improve business agility and scale, however, there are many unknowns when it comes to what the migration path looks like in practice. In this talk, I will discuss the steps required to successfully migrate a monolithic React Application into a more modular decoupled frontend architecture.
React Advanced Conference 2023React Advanced Conference 2023
22 min
Power Fixing React Performance Woes
Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️
React Summit 2023React Summit 2023
24 min
Video Editing in the Browser
Video editing is a booming market with influencers being all the rage with Reels, TikTok, Youtube. Did you know that browsers now have all the APIs to do video editing in the browser? In this talk I'm going to give you a primer on how video encoding works and how to make it work within the browser. Spoiler, it's not trivial!

Workshops on related topic

React Summit Remote Edition 2021React Summit Remote Edition 2021
87 min
Building a Shopify App with React & Node
Shopify merchants have a diverse set of needs, and developers have a unique opportunity to meet those needs building apps. Building an app can be tough work but Shopify has created a set of tools and resources to help you build out a seamless app experience as quickly as possible. Get hands on experience building an embedded Shopify app using the Shopify App CLI, Polaris and Shopify App Bridge.We’ll show you how to create an app that accesses information from a development store and can run in your local environment.
JSNation 2022JSNation 2022
41 min
Build a chat room with Appwrite and React
API's/Backends are difficult and we need websockets. You will be using VS Code as your editor, Parcel.js, Chakra-ui, React, React Icons, and Appwrite. By the end of this workshop, you will have the knowledge to build a real-time app using Appwrite and zero API development. Follow along and you'll have an awesome chat app to show off!
GraphQL Galaxy 2021GraphQL Galaxy 2021
164 min
Hard GraphQL Problems at Shopify
At Shopify scale, we solve some pretty hard problems. In this workshop, five different speakers will outline some of the challenges we’ve faced, and how we’ve overcome them.

Table of contents:
1 - The infamous "N+1" problem: Jonathan Baker - Let's talk about what it is, why it is a problem, and how Shopify handles it at scale across several GraphQL APIs.
2 - Contextualizing GraphQL APIs: Alex Ackerman - How and why we decided to use directives. I’ll share what directives are, which directives are available out of the box, and how to create custom directives.
3 - Faster GraphQL queries for mobile clients: Theo Ben Hassen - As your mobile app grows, so will your GraphQL queries. In this talk, I will go over diverse strategies to make your queries faster and more effective.
4 - Building tomorrow’s product today: Greg MacWilliam - How Shopify adopts future features in today’s code.
5 - Managing large APIs effectively: Rebecca Friedman - We have thousands of developers at Shopify. Let’s take a look at how we’re ensuring the quality and consistency of our GraphQL APIs with so many contributors.
JSNation 2023JSNation 2023
57 min
0 To Auth In An Hour For Your JavaScript App
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool.
We will enhance a full-stack JS application (Node.js backend + Vanilla JS frontend) to authenticate users with One Time Passwords (email) and OAuth, including:
- User authentication – Managing user interactions, returning session / refresh JWTs- Session management and validation – Storing the session securely for subsequent client requests, validating / refreshing sessions
At the end of the workshop, we will also touch on another approach to code authentication using frontend Descope Flows (drag-and-drop workflows), while keeping only session validation in the backend. With this, we will also show how easy it is to enable biometrics and other passwordless authentication methods.
JSNation 2023JSNation 2023
87 min
Build a Collaborative Notion-Like Product in 2H
You have been tasked with creating a collaborative text editing feature within your company’s product. Something along the lines of Notion or Google Docs.
CK 5 is a feature-rich framework and ecosystem of ready-to-use features targeting a wide range of use cases. It offers a cloud infrastructure to support the real-time collaboration system needs. During this workshop, you will learn how to set up and integrate CK 5. We will go over the very basics of embedding the editor on a page, through configuration, to enabling real-time collaboration features. Key learnings: How to embed, set up, and configure CK 5 to best fit a document editing system supporting real-time collaboration.
Table of contents:- Introduction to the CK 5 ecosystem.- Introduction to a “Notion-like” project template.- Embedding CK 5 on a page.- Basic CK 5 configuration.- Tuning up CK 5 for a specific use case.- Enabling real-time editing features.