Unsupported & Future APIs

[00:00:00]
>> And finally, we have red. But we won't cover red here, unless you have questions in terms of can I do something with the JavaScript? And if the answer is no, it's because that capability is not yet there. And it's not even yellow, so there are still not trials or experimental APIs.

[00:00:21]
So we're looking at long term maybe, or maybe never. Because sometimes it's about security, because websites, yeah, we're good people all here in the room and you there, but we know that there are bad actors out there. So we don't want user to get into a website and get tricked or get their data stolen or things like that.

[00:00:43]
So that's why there are some capabilities that will probably never be available directly for the web, okay, for the web platform. And what happens if you really need that for some reason? I mean, your business model relies on that. So the only option that you have is to create a progressive web app, a PWA, so a web app, ship that web app to the app stores.

[00:01:11]
Or for desktop, you can embed that web app in a native container. So when you do that, you can connect, you can bridge your JavaScript with native code, okay? But that's not gonna work in a URL in the browser. You will need to ship that as a PWA built in native app, okay?

[00:01:37]
So you still have that option, okay? So on desktop, it can be things like Electron. On mobile, we used to use PhoneGap, in case you have heard about that, or Apache Cordova. Now, you also have Capacitor from the Ionic team. Different tools, different frameworks that will let you do that.

[00:01:56]
We won't focus on that here today. But have in mind that the only way that you have to extend that is through those options. And of course, you also have the ability to create browser blinds, extensions for the browser, but that's not typically targeting one app. You could create an extension for your own app.

[00:02:17]
But it's kind of weird, typically the extension is multi-origin, so multi-website. So yeah, question.
>> I have a quick question on judging by the maturity.
>> Yeah.
>> Is that based on making that API and then sending it over to Google or different browsers and having them kind of release it in the next release.

[00:02:45]
Is that how that would work for it to be available?
>> In case you have an idea for an API, you say, or-
>> Yeah, or just judging the API and just how it's available in one place and it's not available on the next.
>> Okay, so they have to understand how this works.

[00:03:01]
So actually, if we say we wanna create a new API, I don't know, to move the table, because now the table has a way, it has Bluetooth or wherever, so we have a table movement. I'm talking about physical table, not the table HTML element. So, well, the way that works is typically someone creates a proposal, today typically on GitHub, and you start touching people from the web standards that are looking into that.

[00:03:30]
Typically you need a browser to say, hey, that's a good idea. Let's see if we can implement that, typically first as a yellow API. And then we experiment with that a couple of months or sometimes even years. And after that, someone says, okay, I think I like it, so I will ship it in stable.

[00:03:49]
And what about the others? I don't know, sometimes the others will say, that's a good idea, let's do that again, also. And sometimes the discussion says, no, we don't want that, because different companies, different policies, different ideas of what the web should be. Sometimes you have, for example, Safari, Apple implementing APIs many years after Chrome.

[00:04:12]
For example, they have just implemented web push notifications after seven years of not wanting to do that, and Chrome and Firefox already had that. And there are other APIs that we will see later today, that Safari said, we are not going to do that ever. So that how the process works.

[00:04:36]
So you can create your own API if you want, but if you don't have a browser, doing something with it, it will never reach a stable. And by the way, after a while on the W3C, that's the organization that sets the standard for the web, if only Chrome or Chromium implements the API and no one else, typically, they never get that spec into recommendation.

[00:05:07]
And there are a lot of APIs that are not a recommendation yet, they are draft, or they say, you know what, no, we are not going to recommend this. But even Chrome is still supporting that and Chrome says, okay, we have it anyway. So we can say that that's not a standard API now, because the standard process rejected the API.

[00:05:27]
And there are a couple that were rejected by the standard process, but they're still working on Chrome. You can still use them, but only on Chrome. And there are others that are still being discussed in the standard process. So we will see in the future if they will get into your recommendation or reject them, make sense?

[00:05:48]
>> So with that being said, what are some best practices for utilizing these API effectively in the web application and PWAs? What are the best practices?
>> Well, I think it depends of where your capability stands. If it's a green, go ahead. If it's a light green, you need to be sure to first check if the API is available or not.

[00:06:09]
Later with code, we'll see how you can check if an API is available or not. Unfortunately, we don't have an API to check APIs, okay? So we don't have a way to say navigator.supports, and I pass an API, it give me true or false, we don't have that.

[00:06:25]
So typically what we do in JavaScript, because JavaScript is a dynamic language, so there are ways to do that. Most of these APIs are typically injecting into the window global context a constructor, a function, or an event. So the way to know if an API is available, that we don't know if it works, but at least if it's available, the API, is to check if one particular constructor is available in the window object, or if a property is available in one object.

[00:07:00]
For example, let me give you a quick idea so far. The Bluetooth API that we will cover later, that will let you connect to bluetooth devices, it lives under navigator.bluetooth. If a browser is not supporting the API, you won't have the bluetooth property in the navigator object. So it's just a quick if, check in for that property.

[00:07:26]
And that's how you know on the fly with your real users, real devices, if the API is there or not.