Yes, Your Browser Can Do That (Probably) — A Look At Modern Web APIs You Might Not Know

Thanks.

Yes, so I'm going to talk about web APIs, but before I get started, I want to get a little bit of context on why I think this matters at all, to start with.

So this talk started a couple of years ago when I was pretty Part of a then product team where we kept repeatedly getting into those situations where either the PMs or we as developers ended up saying, oh, we can't build that, or if we want to build that, we have to go native.

So what Ben touched on, and more often than not, it wasn't true.

So there's a couple of things that I learned from that.

One was, just realizing how far browsers and web APIs have come in the last 5 to 10 years.

I still remember the days, and I'm gonna sound old, but I still remember the days where we had to use stuff like Flash to just do simple things like copying text to the clipboard or building a UI to upload files.

So we're way past that now.

It also made me realize how underappreciated those, those browser improvements are.

The other thing that I realized is how often we just skip the part where we think about progressive enhancements.

And this is the definition of MDN, or from MDN, which I think is pretty spot on.

Progressive enhancement is a design philosophy that provides a baseline of essential content, essential content and functionality to as many users as possible while delivering the best possible experience only to users of the most modern browsers.

And for me, the key words here are a design philosophy that gives everyone the essential functionality, but the best possible functionality to everyone that we can ship it to.

And this is the essence of my talk, so I want you to watch all the APIs that we're going to go through that lens of how can we use those APIs to actually enhance the user experience in a way that it doesn't destroy the functionality of the app for everyone who can't access those APIs.

With that out of the way, to actually showcase these APIs, I built a little demo app.

It's called stopme.io.

It's an actual thing, so you can go to stopme.io or scan the QR code.

It's a SASS app.

SASS obviously stands for Stopwatch as a Service.

And it's really just that.

It's a timer.

And I'm gonna go through those APIs pretty rapidly, so stick with me.

But we're gonna use this to put the APIs in a real life context and see why they are useful and how they can be used.

And let's start with two APIs that you are probably already aware of, that you do know.

But I do want to mention them for, a few reasons.

It's, first of all, the resize observer, which allows you to, essentially keep track of the size of an element on the page, or multiple elements on the page, and get notified when the size changes.

People keep saying the new CSS container query is to replaceResize Observer, I personally somewhat disagree with that.

Yes, a lot of the use cases for the Resize Observer are now replaced.

And we can use CSS instead.

But I think it's worth just acknowledging how much more powerful these Observer APIs are than just pure CSS.

So in my opinion, there will always be use cases for things that you want to do when things resize that are beyond just styling changes.

The second one is the IntersectionObserver API.

So that allows you to get notified when elements on the page enter or leave the viewport.

And this is just super useful and powerful in general if you want to have enter animations on your website or, parallax scrolling effects and stuff like that.

But it's also still a very fundamental part of a lot of modern frameworks.

So if we think about stuff like QUIC, which is a framework that's very heavy on code splitting, you can use intersection observers there to only start loading the JavaScript chunks once the component related to it actually enters the viewport.

So we avoid loading a lot of JavaScript for stuff that the user never sees or never interacts with.

So I think it was, it's worth mentioning those APIs in the beginning because it's interesting how relevant they still are, or even getting more relevant as time goes on.

But we can observe more than just our own page.

We can observe a lot of stuff on the user's devices.

So the next API is the Network Information API.

To start with, we get like very basic information that's actually supported on all browsers.

Whether or not the user is online.

So that's a simple attribute that we get on the navigator.

And it allows us to keep track, and an event listener on the window, and it allows us to keep track of the network status from that end.

And that's already useful to just show when a user loses network, show them a notification or something like that.

The network information API, only supported on Chromium browsers, but that's exactly where we get to the progressive enhancements, so use it, but don't rely on it.

But it gives you a lot more information on that just beyond the online status.

So you can see the type of network, so are they on Wi Fi, are they on mobile, mobile connection, the speed of the network, so you get downlinks, maximum downlinks, round trip times, and you get, And finally, the boolean, whether or not the user activated safe mode on their device.

And again, this can be really useful to just know, okay, the user wants a safe network, so maybe we serve, lower resolution videos and images and stuff like that.

In our stopwatch, the example is what I mentioned in the beginning.

When the user goes offline, some of the functionality might not work, so you can easily just listen to that event and show, a banner at the top of the page.

Next one.

Is fully supported in all browsers, which is cool.

Page Visibility API.

Most of these APIs are really well named, so they do exactly what they say they do.

In this case, we have, again, an attribute on the document that tells you whether or not the current page, or, more specifically, the current tab, is actually visible or is in the background and not visible to the user.

And this can be useful for various things.

If you have computation heavy stuff, say you have an API that you're polling because you want to have real time information on your dashboard.

You probably don't need to do that or want to do that when the tab is in the background anyway and the user doesn't see it.

So you can listen to those events and just stop and restart polling as needed.

What we can do in our stopwatch app is we can say, Okay, maybe somebody starts a timer, but they then go and do something else.

Let's just change the title of the document and put the current timer there so they don't need to come back to our tab to see where the timer is currently at.

So there's little nice touches and quality of life improvements that you can do with information like that.

Next one, Battery Status API.

Again, only Chromium browsers.

There's a trend that's going to sneak throughout this talk.

Battery Status, again, pretty straightforward.

It does what it says.

It's an API on the navigator that allows you to access information about the battery.

So that includes whether or not the battery is currently charging or discharging.

And it can also include more details on if it's currently charging, how long till it's fully charged.

If it's discharging, how long till the battery is empty.

That's, those numbers are not always super accurate, so I wouldn't rely too much on them.

But the general information about it, okay, is it currently discharging and how close to empty is it, can be super useful if you have like longer running things in your application.

So you know a certain process takes 20 minutes to complete.

You can warn the user about hey, your battery is about to run out.

You might want to charge it or you're not going to see the end of it.

And that's, for our stopwatch, that's a good use case.

So if you put a timer on, two hours, but we know your battery won't last that long.

We can easily show another warning notification at the top to just warn the user about that.

And, again, just the quality of life.

The user could live without it, but if they see it, it's a nice touch.

All right.

Enhancing your components.

So especially when, like Ben said, you have a UI Framework that you're using, maybe even internally, you have a design system.

There's a lot of things you can use the platform for to enhance those individual components and improve them from a user experience perspective.

First one for me, personally, I think this is really important.

Stuff like haptic feedback, within your application, can be super powerful to help users understand what's happening in the application.

So the Vibration API has been around forever.

It's still not supported by Firefox.

But it basically allows you to have the device vibrate on demand.

And you can either pass in a number and then it just vibrates for that duration, or you can pass in an array and it vibrates in a pattern of those durations.

And I would definitely not overuse it.

There's no permission tied to that API, by the way.

You can just start vibrating.

It is tied to, the user has to have interacted at some point with your website.

So any scroll, any click on the website, will then give you access to that API.

But what you can do is, again, just haptic feedback.

So the best example for me was one of the bank apps that I used ages ago started introducing it for their, they had a fake keyboard on the home page to put in the pin, and they just used simple vibration API, to basically give you the same haptic feedback that you would get on the normal virtual keyboard, which I thought was pretty cool.

And there's whole websites around just listing popular songs, popular, Morse codes, whatever.

People literally dedicated their life to that, which is pretty cool.

But it also means, for our stopwatch, we could obviously use it when the timer runs out.

So if somebody puts on a timer and they're cooking or something, so they don't actually watch it, the phone would vibrate and they would notice when the timer runs out.

And if you put in something else, like a specific name for your timer, we could have Easter Eggs, where we actually use those patterns from the web, to, for Chewbacca we're playing the Star Wars theme, and yeah, it vibrates, trust me.

The next one I think is super cool, it's again just Chromium, but it's the eyedropper API, and it's again doing exactly what it says it does.

It allows you to use the OS native color picker.

This one is one of the APIs that need to be triggered by an active button click to trigger it.

It needs to be on a click event handler.

But then you can basically call the eyedropper, call open, it returns a promise, and if the device has a native color picker, it basically pops up and it allows you to pick a color from anywhere on your screen.

So it's even outside of the browser.

It's really powerful if you have stuff like brand settings in your application, and you want people to be able to just have their preferences brand PDF open and they can literally just go pick the color from the PDF and move on.

It's also a really cool example.

I might be spreading rumors here because I keep saying that in this talk.

I've been told that Canva had a huge influence in getting this API into the browsers.

So it's a good example of like actual products driving how much or how we can put more, power into the platform itself rather than relying on frameworks.

And then there's stuff, this is the few things that actually triggered this talk.

So there's a few things where I always thought oh, I have to go native to get like access to this functionality.

Where there's these APIs that are actually really cool and they're in the browser.

First one is the WebShare API.

So that allows you to actually trigger the native share functionality.

So you can give it kind of the information that you want to share.

So say we have a title and some description text, and then you can share an URL or potentially even files.

So those can be image files, video files, whatever.

That's the part that Firefox doesn't support, so that's like an in between.

But you can basically define that information and then pass it on to the WebShare API.

And if the platform supports it, if the OS supports it, what it will do, it will pop up the native share model, and the user can pick from any of the apps that they do have installed.

To trigger a share.

And then the apps themselves just decide how they want to handle that object that you defined.

And this can be really powerful.

This basically replaced for us, the usual, Facebook button that's just a URL, where in the URL parameters you say what you want to share.

This is much more flexible.

It gives you the, possibility to attach files.

And it allows the user to pick what app they want to choose.

So I thought that was pretty cool.

The other one, less supported, unfortunately, but arguably just as powerful.

Again, personally, I come from the background where we build a lot of SaaS apps and, management dashboards, where people often just need to add contacts or invite contacts or something.

And the web has something called the contact picker API.

Very similar to the web share.

So we define what fields we actually care about from the contacts.

So that can be name, email, phone number, the avatar.

I think there's a couple of more fields.

And then we can define whether we want to allow the user to pick one or multiple contacts.

And all it does in the end is, again, check whether or not the platform supports has the ability to, show a contact picker, and if so, it will pop up the native UI for that.

And again, this is, you don't have to build anything for that, users are familiar with that, and it gives you the benefit of, actually, they can access the contacts they already have on their phone, they don't need to look it up, scan their phone while they're putting something into, the, desktop.

It's just neat and it's such a quality of life improvement if you just have it as a separate button as an alternative to manually adding contact details in your application.

The last one that I'm going to go into detail on, is the one that I'm personally most excited about, even though it's still, I think, slightly away from fully production ready.

So it is production ready in the sense it's there, and it's supported by Chromium browsers again.

And the WebOTP, OTP, one time password, I think most of us are pretty familiar with that concept of you're logging into an application, it sends you an SMS with a code, usually like a number code, and then you put that in to confirm that you are who you say you are.

WebOTP API basically allows you to hook into that whole flow.

And it says if you run that on your phone, you can define the transport model.

Right now, it's just SMS.

And once you trigger that, it basically waits for any incoming SMS and then notifies you when you get an SMS that follows a certain pattern.

So right now, it literally needs to follow the pattern that I basically mentioned at the bottom there, with your URL also in it.

So that's like the security layer there.

But once that happens, you can do anything with that code.

So you can autofill that form and autosubmit it to streamline what the user gets.

And this is neat because it basically takes what Android and iOS have been doing for a while now, which is really, again, a quality of life improvement of just, you get an SMS and it gives you a, just copy these numbers streamline flow this helps with that and just puts it straight into your app.

What it will look like is that it actually pops up a Notification does it?

Yes.

So this is the permission Notification that pops up.

This is why I personally I think this could be a little bit nicer.

It's daunting Every time you get like permission requests users usually just deny them But it basically just asks.

Hey, are you cool with listening to that and then you get the SMS and you can auto fill it in.

The thing that I recently found and that made this whole thing even cooler is, say you're on your desktop and you put in, your phone number, you get the SMS.

If your phone and your desktop are both connected to the same Google account, if you're using Chrome in both and it's on the same Google account, it will actually pop up a notification on your phone, just slightly creepy but still cool, whether or not you want to send that code to your laptop.

And then just from that button, it automatically does everything that it would do on your phone.

So even then, you can get that automated flow and you don't need to manually type in the confirmation code.

Cool.

25 minutes are not enough to talk about all web APIs.

I could literally talk all day here.

I have a few honorable mentions that I quickly want to go through.

And then I hope we have at least time for a few questions.

If anyone has questions to talk about a bit more.

First honorable mention.

This is probably slightly disappointing.

But debugging.

Console.

Console has a lot more than just console log.

Trust me.

These are actually really nice once you start using the ones that give you useful information.

If you use console a lot for debugging, console table, console trace.

Brilliant.

So just be aware that there's more than just console log.

Performance debugging.

So that's in the browser APIs, in the web APIs, there's tools to put in performance markers and then keep track of performance of different things.

I highly recommend doing this and using the performance observer as part of your end to end tests.

So keep track of those performances have thresholds and basically get automatically notified when your app gets slower over time.

Very similar thing with memory.

I might be slightly biased because I keep building applications that leak memory.

So getting notified about that is super awesome.

So having the ability to take memory snapshots.

And again, even in your end to end tests, just start analyzing those and having thresholds can be extremely powerful.

Authentication, but better.

So this is like an extension of the WebOTP API.

I think WebOTP is cool.

Credentials API is super cool.

So that allows you to use the browser's internal credential management system.

So it allows you to store credentials as the user logs in.

And that just makes it easier for the user to, when they come back, to automatically get logged in again, but also to sync that authentication across different devices where they use the same browser.

So that works with password and email, or username and password, authentication, but also with federated logins.

So there's ways how to use, say, a Google login, store those credentials, and again, automate that flow.

The Authentication API.

Basically, it goes a whole step further.

So that's the approach of what if we went password less?

And I think this is probably the more refined it gets and the more the libraries around it mature.

This, I feel, is definitely the future.

Basically it does, ignoring the code for a bit.

It's just taking advantage of the native authentication methods of your device.

So that's not even the browser, that's just like on your phone you have fingerprint, authentication.

This allows you to access that to authenticate users.

So again, super powerful and it streamlines the whole process of users authenticating themselves, not having to remember passwords, not having to deal with like specific stuff just for your application, they can just use the known methods, and move on.

And then we have next generation stuff.

So this is stuff that you probably won't necessarily touch directly unless you're following Ben's advice and say OK, no frameworks anymore.

But this is what most frameworks and most libraries will either already have adopted, or we'll start adopting more and more.

Internationalization API has been around for a while, but it's my personal favorite of all things, I think.

It's date formatting, it's even date formatting in like relative times, like in two hours or two hours ago.

And it automatically translates it for you if you go, multi language.

And it does number formatting, which is, I think, even cooler, so like, where do you put the separated comma, or in Germany it's actually a dot, and having to know all these things, this API just does it for you.

Where to put your currency symbol and what currency symbols actually to use in which locale.

Super handy.

I think most of the internationalization frameworks or libraries have adopted these by now.

Temporal is with an asterisk because it's not, I think it's stage 3, it's not fully 3 yet, but it's super exciting because it does a lot of the stuff that's been super painful with the current date API, and we've known about that, so they literally just took a look at that and started developing a separate API that fixes most, if not all of those problems.

And the big one here is just manipulating dates.

So whenever you want to add an hour or add a day, to a certain date, this will make it so much easier.

Navigation API, in a similar fashion, just tries to fix all the problems that we've discovered in the history API.

So things like your, your remix router, whatever libraries you use for single page application routing, if you do single page applications.

This will be super helpful, for that.

URL patterns, I think that's just cool because it literally gives us the power to actually match URLs easily in the browser as well.

So again, we don't rely on libraries to do that.

And then two mentions that are technically not really JavaScript.

They tie into JavaScript, but they're also just HTML, which is cool.

So the popover API, which allows you to, basically build popovers and dialogues and modals all in a way that's accessible out of the box, which is you don't have to then worry about, focus trapping and all of that stuff, it just, does what it needs to do.

And the view transition API, which I think got mentioned earlier, which allows you basically to get the single page application feel without using a single page application.

Routing from one route to another, and then transitioning the view between those, becomes a lot easier and controllable, which is cool.

All right, this is the link to the slides.

If you want to have another look at it.

I highly recommend literally just going through the MDN documentation and looking at all the APIs that are available.

It's awesome.

It's a way to literally waste a whole weekend.

And yeah, thank you.