Superpowers of Browser's Web API

Rate this content
Project website

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!

25 min
15 Nov, 2023

AI Generated Video Summary

Today's talk covers Web API, including exotic and not commonly used APIs that can enhance web applications. The IntersectionObserver API allows for lazy loading images and infinite scroll lists. The Screen Wake Lock API prevents devices from locking, ensuring uninterrupted usage. The Wake Lock API is useful for various scenarios, but browser and device support varies. Background Sync and Broadcast Channel APIs enable offline functionality and communication between contexts. Lastly, the impact of code on the planet is highlighted, emphasizing the need for more efficient web development.

1. Introduction to Web API

Short description:

Today's talk will cover Web API, which is a collection of built-in interfaces that allow developers to interact with web pages and provide fancy functionality. JavaScript's single-threaded nature and the event loop play a role in how setTimeout behaves. WebAPIs, provided by browsers, offer a wide range of APIs and interfaces for web development. Let's explore some exotic and not commonly used APIs that can give our web applications superpowers. I'm Nikola Mitrović, and these are my Web APIs highlights for today.

Hello React Summit US! I wish you a warm welcome to today's talk. Today we're going to talk about something called Web API. But before we do that, we will need to take a small step back and go through some JavaScript basics.

If we see this example, and I ask you the question, what the order of the logs would be in the console, probably most of you would say 1, 3, 2. And that is correct. But how do we know that? How do we know how setTimeout behaves?

As we know, JavaScript is a single thread language. Let's visualize this a bit. There is a call stack, we execute the first function which is synchronous, and then we log the 1 as a value immediately. But then the second one is asynchronous, and it needs to go somewhere else, not to block that single thread. And it goes to the queue once the timer is finished. In the meantime, the call stack continues with executing the functions, then event loop checks if the call stack is empty, and pushes back the callback with the value of 2. But the main question is, where does the setTimeOut wait while we continue with the execution of our code?

If we Google this function, the first result we get is this one. So there is MDN documentation where we can see some stuff about setTimeOut function. And here we can see that it's under a tab WebAPIs. If we click that, we can see that basically WebAPIs is a collection, a list of APIs and interfaces which we may use right out of the box when developing web applications. Basically, it's a functionality provided by a runtime environments. In this case, our browsers. And if we scroll a bit, we can see that there are a lot of APIs, a really, really long list of APIs. And here we can maybe observe that there are some quite commonly known and used APIs, like WebRTC, session storage, local storage, file upload API, a DOM API, and so on. But looking through this list, I was wondering, what are the some of the exotic and not so commonly used APIs that we may use which can give us our web application certain superpowers in certain use cases? So basically, we're here to find out that today. And like we established, the answer to this question about set timeout is Web API, which is basically a collection of built-in interfaces that allow developers to interact with our pages and provide some fancy functionality.

I'm going to quickly introduce myself. When I was in high school, I always wanted to study psychology. Now I work my dream job at Wega IT based in Noišac, Serbia, where I work as a development which means that I teach people soft skills, how to communicate with the clients, how to deal with stress, how to do presentations like this, why not, and so on. My name is Nikola Mitrović and these are my Web APIs highlights for you for today. OK, now we go to our first example for today. Let's say we have a page like this and there is nothing there but the background, but once we scroll a bit down we can start observing that there is something in the bottom left corner. It's a small astronaut, which when fully visible says, hello world. Once we scroll a bit up and the astronaut is not fully visible, the message goes away. We scroll again a bit down and again, once the astronaut is fully visible again he says hello world.

2. Using the IntersectionObserverAPI

Short description:

The IntersectionObserverAPI is an API that determines if an element is visible on a page. In React, we can create a hook called useVisible to observe elements. The hook accepts the reference of the object and configuration options like the root and threshold. By using this API, we can lazy load images, create infinite scroll lists, and defer animations. It's important to consider browser support, but this API is fully supported by major vendors.

So how did we manage to do this? There is an API called IntersectionObserverAPI which basically figures out if the element is visible on a page or not. If we would build a hook in React for this, we would probably call it useVisible and that hook would accept two parameters.

It would accept the reference of the object that we are trying to observe and we have certain configuration options. One of those options is root. If we pass null, then we assume that we are observing the element according to the whole document. Basically it means we can have smaller containers with smaller scrollable areas and we can observe some elements there, but if we pass null we look according to the whole document. We can have a margin around that root, so we can catch that intersection a little bit earlier if needed. And we have a certain threshold, meaning that if we pass this value we need 100% of visibility for the element, so we can adjust this accordingly. Then we would have a state called isVisible, and then we instantiate the IntersectionObserver object. In the callback we get the Entry object, which has a property called isIntersecting. This property holds the information about the visibility of an element, and then we can set that to our state. So now what's left to be done is just to call observe method on that reference and return that state. And that would be it.

The example with the astronaut was nice and cute, but you're probably now wondering what are some real-life use cases where we can use this API. We could lazy load images, right? So we load the initial content for the page and everything below the fold, what is not needed initially, we can defer and lazily load. And once we scroll to a certain section, then we start downloading images and other assets. We could create infinite scroll lists. For example, we don't need library for this. We could have a list out of 10 elements. We could have a separator at the end of that list. And once we scroll back and that separator is visible, then we trigger the next request. We could defer animations. So we don't need to run animations if something is not... If the certain element is not visible on that page. And by doing so, we can save some computer power. So we don't need to run some JavaScript if the element is not visible in the viewport. One thing to always consider when using some of these APIs is browser support. If we look at the major vendors, we can see that this API is fully supported. So great news, we can safely use this in all browsers. OK.

3. Screen Wake Lock API Example

Short description:

In this example, I demonstrate how the Screen Wake Lock API can prevent a device from locking. I set up my laptop and phone to turn off after one minute of inactivity. However, thanks to the Screen Wake Lock API, my phone's screen stayed on while I was cooking. This API is a useful tool to ensure uninterrupted device usage.

Now we go to another example for today. Now, I'm going to do something with my personal preferences. I'm going to say that, first note that my laptop is not on the charger. And then, if it's not on a battery, I'm going to say, if my laptop is inactive for one minute, it will turn off. Also, I have my phone connected next to me, which has the same setting. And we're gonna have the same application. So note by the URL that we have the same application and the same code running behind these two examples.

Now, I'm going to restart the timer for the both of applications at the same time, hopefully. Okay, and here I'm going to click this toggle, but for the mobile version, I'm not. You may notice at the very beginning, I didn't talk much about myself, but now we have a minute to spare and it's my time to shine. Well, I like to travel, and when I do, Italy is one of my favorite destinations to go to. The architecture, the people, the wine, pasta, it's all amazing for me. So, it's inspired by that. Recently, when I get home, I like to prepare food for myself. So, I go to some cooking recipes website. My phone is next on the counter next to me and I'm preparing that food. But after a minute, something happens. And we're just going to wait for a few seconds. Okay. After one minute, my phone turns off. And now, with sticky fingers, I have to unlock my phone again. Note that the timer went to the zero seconds here, but went to one second on my phone. It's simply because my phone turned off. And we have lost the connection with my phone. Once I touched it again, my phone turned on. But again, we need to unlock it and use the phone again properly. Here it didn't. Because we have the most awesome feature, which says, basically, hey, I'm cooking. Do not turn off my screen. So how did we manage to do this? There is an API called Screen Wake Lock API, which prevents the device from locking.

4. Using the Wake Lock API

Short description:

In React, we create a hook called Use Wake Lock to request a Wake Lock Sentinel function. This function is a promise and needs to be put in a reference to preserve the previous state. We return if we have the lock or not and release it by calling the release method on the reference. Use cases include reading e-books, presenting to an audience, following a recipe, map navigation, or scanning a QR or barcode. Browser support varies, with Chromium-based browsers supporting the feature, Firefox not supporting it, and Safari being experimental. Device support also varies.

Although our personal preferences said something different. And it can only work if the document is visible on our page.

If we do this in React, we will make a hook called Use Wake Lock and it looks something like this. We pass that toggle Boolean, which is turned on or off, right? And if it's turned on, then we call a request Wake Lock Sentinel function. That function, I will call on a navigator, we have Wake Lock object and a request method with the parameter screen. And that function call is a promise. It's a promise because it can fail in certain use cases. For example, if our battery is way too low and now the situation is a little bit trickier than in the previous example, because we need to put this in a reference. We need to do that because if we put it in a state, then we will lose the previous state and this function returns a certain value. We need to clear that value exactly that value in memory afterwards when we release the lock, otherwise it won't work. That's why we need to put it in a reference. Then we return if we have the lock or not. And when we release, once we toggle back off, then we need to call the release method on that very reference and we need to clear that reference. Those are all necessary steps to be done, otherwise the lock will remain in memory.

Again, some of the use cases for this, reading an e-book, presenting to an audience, following a recipe, map navigation, or scanning a QR or barcode. Again, if we look at browser support for this API. Now we can see that the situation, again, is a little bit different. Chromium based browsers support this feature, Firefox doesn't. And this sign means that it's in experimental phase for Safari. So they have some work in place but not fully. One more thing to notice about this API is that there's a certain device support. So some of the devices support this feature, some not. For example, I have an iPhone and whatever I did, I couldn't make this feature working although I use Chrome. I think this has to do with the fact that the Chrome is just the skin for the iPhone and it's basically Safari under the hood. It uses WebKit engine to run the code, but that's something we have to deal with when using this API.

5. Background Sync and Broadcast Channel APIs

Short description:

In this last example, we explore, a futuristic app that communicates with NASA's API to retrieve a list of habitable planets. We can search and choose vacation destinations, even with offline connectivity issues. The Background Sync API allows us to run tasks in a service worker, ensuring requests are sent once back online. Browser support for this API is still limited. Additionally, the broadcast channel API enables communication between same-origin contexts.

And moving on to our last example for today. Here we have an example of which translated to English means spaceman. Svemirko is a little bit futuristic app, a few thousand years in the future, where in the backend, we're communicating with the NASA's API which retrieves us the list of all habitable planets.

Now we can search through that list and choose where we want to go on vacation. But in the future as well, we have some offline connectivity issues. If we go offline and if I tell you that hovering over this explore button will trigger the request, you would probably expect that request happens in the network. But if we are offline, that network request would fail, of course. We may notice that there is nothing going on in the network. But in the Applications tab under Background Sync, there is something else going on. If we click, we will see the loader. Basically, our request hasn't gone yet. And here in the Background Sync, we can see that there is something called RegisterEvent. RegisterSync. Once we go back online, then we have this PepsSync event. Our request went on. And if we wait a bit, once that request is finished, then we will have the third event, which is called SyncCompleted. Now we have the list of our planets. And we can search and decide where we want to go to the vacation.

How did we manage to do this? There is an API called Background Sync API, which basically provides a way to do the fire task it to a service worker, which we can run in the background. If we build this example in React, we have that link. Once we hover, there is on a navigator, inside of a service worker, there is a ready object, which is basically the registration for the background sync. And after that, we need to call sync and register method and pass a tag of a task. We do that because we might have multiple tasks running in the background while we are offline. And inside of our service worker, what's left to be done is just to compare the name of that tag. And once we get that event, then we can continue with our request. Of course, some of the use cases are offline UX and maybe we want to send an email, but we went offline that very moment, we can recover for that and run that task in the background which will be continued once we go back online. Again, checking the browser support for this API. Not so well at the moment, but we'll wait a bit for this because this is quite an awesome feature.

In the previous example, if you have wondered how did we manage to pass the data from the service workers to our component. Well there is an API called broadcast channel API, which is basically a channel for the communication between same contexts, which means, if we have the same windows, tabs, frames or iframes, which are on the same origin, then we can communicate between those origins.

6. Broadcast Channel API and Other Highlights

Short description:

In our previous example, we connect to a channel in the service worker and send information to our component. Use cases include detecting user actions from another origin and synchronizing actions across multiple tabs. There are several other APIs worth exploring, such as the beacon API, web speech API, page visibility API, network API, web share API, background fetch API, and web authentication API. These APIs provide standardized code and eliminate the need for passwords, offering a more secure and efficient web development experience.

And it goes both ways. In our previous example, in our service worker, we need to connect to a channel. We create a new broadcast channel and connect to it. And we, through the post message, we can send certain information to our component. In our component, we subscribe to that very same channel and on a message event, we will get, as a parameter, we will get the data that we send from a service worker.

Again, some of the useful use cases are to detect user action from another origin. Or if we have multiple tabs open for the same application, if we log out in one, we want to log out user in all tabs. Browser support in this case says all cool, all good. We can safely use this API.

Unfortunately, because we don't have too much time, we have to stop here for today, but I'm going to give you some bonus points and I hopefully, inspired you enough to go and search some of these APIs on your own. But here are some more of my highlights. There is a beacon API, which basically is used when you want to send a request, but you don't care about the response. Useful for analytics. There is a web speech API. Page visibility API, if you want to track the visibility of the whole document and certain elements. There is a network API which gives you your network system information. There is a web share API which can share information, share files between different devices. There is a background fetch API. Basically if you want to download a huge document but then you go offline, you can continue with the download once you're back online again. And of course one of the probably most exciting and new ones are web authentication API, which is basically a way for the passwordless experiences. We won't need passwords anymore. In the future we could just authenticate with our Touch ID with our face or with our USB key or some other devices. So really really exciting to see how this API will turn out. And at the end some of the takeaways. We have seen that some of these APIs have no browser support at this very moment. Some of that support is in the experimental phase. We have to watch for the device support in some cases and there is a certain TypeScript support that is lacking. But why should we use this API and adopt this mindset? Because it's standardized code, it's standardized code, it's standardized code. I probably cannot stress enough how important this is, especially in today's Web development where we have a new framework, new library each week. This is like a single source of truth.

7. The Impact of Our Code on the Planet

Short description:

By using these APIs, we can increase performance and build features on our own. Our code has an impact on our planet, as the internet consumes 21% of all electricity. Use the Website Carbon Calculator to check your website's carbon footprint. Let's take action and join forces to make a difference.

This is standardized code, we can use it in all browsers. So it's really, really important. Most of these APIs are really easy to learn and by adopting this mindset and using some of the built-in functionality in our browsers, and not using the libraries too much, we can have the, we can increase performance as a side effect. Of course, I'm not saying that we shouldn't use libraries and shouldn't reinvent the wheel in certain use cases, but in some use cases, we can probably build some features on our own with the help of these APIs.

And that brings me to my point, that with great power comes great responsibility. So I felt like this is my responsibility to say this to you. I wanted to talk a bit about our planet. If you're having a 404 facial expression, like not found at the very moment, like what, what does the, our code has to do with our planet? Well, it kind of does. We build our React application. We run a build. There is an output for that build. We deploy that, our HTML, CSS and JavaScript files to some cloud providers, which are distributed across the world. They are in the data centers. Those data centers have a lot of computers, are basically essentially a lot of computers next to each other, and they're all plugged into electricity. In fact, so much that the internet is consuming 21% of all electricity in the whole world, which is really staggering information for me, if you ask me.

But luckily for us, there is a very cool application called Website Carbon Calculator, which can check out the carbon footprint, our website traffic, energy intensity, and data transfers. So I would highly advise you to use this application and go and check how green you are. This is super important because we have only one planet. This planet is our home and if we're not kind to it, one day is going to be too late. So what we can do is all of us can take action, join forces, and in that sense we can provide big, big results all together.

Thank you so much for coming today and for hearing me out. If you want slides to recap and to go over them again, this is the QR code. You can scan it. You can write me. This is my email. You can go to my GitHub and revisit all examples that I've built. Thank you.

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

React Advanced Conference 2021React Advanced Conference 2021
39 min
Don't Solve Problems, Eliminate Them
Humans are natural problem solvers and we're good enough at it that we've survived over the centuries and become the dominant species of the planet. Because we're so good at it, we sometimes become problem seekers too–looking for problems we can solve. Those who most successfully accomplish their goals are the problem eliminators. Let's talk about the distinction between solving and eliminating problems with examples from inside and outside the coding world.
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 Day Berlin 2022React Day Berlin 2022
22 min
Jotai Atoms Are Just Functions
Jotai is a state management library. We have been developing it primarily for React, but it's conceptually not tied to React. It this talk, we will see how Jotai atoms work and learn about the mental model we should have. Atoms are framework-agnostic abstraction to represent states, and they are basically just functions. Understanding the atom abstraction will help designing and implementing states in your applications with Jotai
React Day Berlin 2022React Day Berlin 2022
29 min
Fighting Technical Debt With Continuous Refactoring
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 Remote Edition 2020React Summit Remote Edition 2020
32 min
AHA Programming
Are you the kind of programmer who prefers to never see the same code in two places, or do you make liberal use of copy/paste? Many developers swear the Don't Repeat Yourself (DRY) philosophy while others prefer to Write Everything Twice (WET). But which of these produces more maintainable codebases? I've seen both of these approaches lay waste to codebases and I have a new ideology I would like to propose to you: Avoid Hasty Abstractions (AHA). In this keynote, we'll talk about abstraction and how you can improve a codebase applying and creating abstractions more thoughtfully as well as how to get yourself out of a mess of over or under-abstraction.
React Summit US 2023React Summit US 2023
21 min
The Epic Stack
Modern web development is fantastic. There are so many great tools available! Modern web development is exhausting. There are so many great tools available! Each of these sentiments is true. What's great is that most of the time, it's hard to make a choice that is wrong. Seriously. The trade-offs of most of the frameworks and tools you could use to build your application fit within the constraints of the vast majority of apps. Despite this, engineers consistently struggle with analysis paralysis.Let's talk about this, and a solution I am working on for it.

Workshops on related topic

React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2022React Summit 2022
136 min
Remix Fundamentals
Featured WorkshopFree
Building modern web applications is riddled with complexity And that's only if you bother to deal with the problems
Tired of wiring up onSubmit to backend APIs and making sure your client-side cache stays up-to-date? Wouldn't it be cool to be able to use the global nature of CSS to your benefit, rather than find tools or conventions to avoid or work around it? And how would you like nested layouts with intelligent and performance optimized data management that just works™?
Remix solves some of these problems, and completely eliminates the rest. You don't even have to think about server cache management or global CSS namespace clashes. It's not that Remix has APIs to avoid these problems, they simply don't exist when you're using Remix. Oh, and you don't need that huge complex graphql client when you're using Remix. They've got you covered. Ready to build faster apps faster?
At the end of this workshop, you'll know how to:- Create Remix Routes- Style Remix applications- Load data in Remix loaders- Mutate data with forms and actions
Vue.js London Live 2021Vue.js London Live 2021
169 min
Vue3: Modern Frontend App Development
Featured WorkshopFree
The Vue3 has been released in mid-2020. Besides many improvements and optimizations, the main feature of Vue3 brings is the Composition API – a new way to write and reuse reactive code. Let's learn more about how to use Composition API efficiently.

Besides core Vue3 features we'll explain examples of how to use popular libraries with Vue3.

Table of contents:
- Introduction to Vue3
- Composition API
- Core libraries
- Vue3 ecosystem

IDE of choice (Inellij or VSC) installed
Nodejs + NPM
JSNation 2023JSNation 2023
174 min
Developing Dynamic Blogs with SvelteKit & Storyblok: A Hands-on Workshop
Featured WorkshopFree
This SvelteKit workshop explores the integration of 3rd party services, such as Storyblok, in a SvelteKit project. Participants will learn how to create a SvelteKit project, leverage Svelte components, and connect to external APIs. The workshop covers important concepts including SSR, CSR, static site generation, and deploying the application using adapters. By the end of the workshop, attendees will have a solid understanding of building SvelteKit applications with API integrations and be prepared for deployment.
React Summit 2023React Summit 2023
106 min
Back to the Roots With Remix
Featured Workshop
The modern web would be different without rich client-side applications supported by powerful frameworks: React, Angular, Vue, Lit, and many others. These frameworks rely on client-side JavaScript, which is their core. However, there are other approaches to rendering. One of them (quite old, by the way) is server-side rendering entirely without JavaScript. Let's find out if this is a good idea and how Remix can help us with it?
Prerequisites- Good understanding of JavaScript or TypeScript- It would help to have experience with React, Redux, Node.js and writing FrontEnd and BackEnd applications- Preinstall Node.js, npm- We prefer to use VSCode, but also cloud IDEs such as codesandbox (other IDEs are also ok)