A Tour of Web Capabilities

Web Capabilities Maturity

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
A Tour of Web Capabilities

Check out a free preview of the full A Tour of Web Capabilities course

The "Web Capabilities Maturity" Lesson is part of the full, A Tour of Web Capabilities course featured in this preview video. Here's what you'd learn in this lesson:

Max defines a capability and shares how they are categorized by maturity. Green APIs are available in every browser on every platform. Light-Green APIs are only supported in some browsers but are mature enough to be used in production.

Preview
Close

Transcript from the "Web Capabilities Maturity" Lesson

[00:00:00]
>> So, capabilities. So we are going to cover capabilities. So we need to start understanding, okay, what's a Web capability? Because we know what a Web app is, I'm not going to define a Web app, I'm expecting you to be Web developers. So we know what a website is, what a Web app is.

[00:00:16]
But what's actually a capability? Because actually, rendering HTML is a capability, right? So using CSS might be a capability, but it seems like we are not going to focus on that, on basic HTML things to do. So it's actually the ability of a Web browser, or Web application to perform a specific task or function, using typically a built-in API?

[00:00:44]
I'm saying typically, because there are a couple of capabilities that are not API's actually. They are sometimes DOM events, they are offered through an HTML element, not really an API from the browser. But let's say that 98% of the capabilities are API-based, and mostly the new ones. Maybe we are still getting some features from the past that is still HTML.

[00:01:13]
Just to give you an example. If you wanna get open the camera so the user can take a selfie, there is an API, but also you can use input type file, with some attributes that you can add to express that you want a selfie. And then it will open the camera and take a selfie, and there is no JavaScript involved there, and we can take that as a capability.

[00:01:37]
But we will focus here mostly on the JavaScript APIs. So, have in mind that it's still a Web platform. So if you are a Web developer, you know how these work. Yeah, maybe if you are new to the Web, I mean, if you have started doing Web development in the past year or so, maybe you haven't deal with a lot of compatibility issues.

[00:02:01]
But the Web platform is vendor agnostic. So it's not like a platform created by one company, it's actually created by everyone, of course, that we have different companies and browsers with enough power to push the Web forward in one way or the other. I'm talking about Google with Chrome, Apple with Safari, Let's say still Mozilla with Firefox, has a little power there, also we have Samsung, Intel, Opera, and Brave, and many others that are pushing the wave in one way or another.

[00:02:38]
But because it's multi-vendor, and we have standards and specs, and we have different ideas on how to implement things. Sometimes we need to deal with compatibility issues. So for example, some capabilities that we will see later won't be available on every browser. I will give you enough warnings on which API's are everywhere, which other API's are not.

[00:03:01]
But for that, we need to remember a design pattern that has been in the Web for a while. I remember talking about progressive enhancement since probably early 2000s. That the idea is to make an app that works everywhere, and start adding layers based on compatibility. So if that device supports Bluetooth, okay, we will add Bluetooth to our app.

[00:03:29]
If you're opening that up in another device without Bluetooth compatibility, the rest should work instead of giving us an error. So we are adding layers based on compatibility. So here you have, we are not going to read this. But here you have a list of maybe all the API's or most of the API's available today on the Web with a link to the spec, or with a link to an article that explains that API.

[00:03:59]
Example, so you have a lot as you can see. But these API are not just a list organized alphabetically. They are organized by some kind of an idea color. We have green API's, and those are API's that are currently available in every browser on every platform. So that's iOS, Android, Chrome on dekstop, Safari on the Mac, Firefox, Samsung Internet browser, and it's a mature API.

[00:04:31]
So it has been for a while typically and it's safe to use that API, it typically works. There is always an asterisk here saying, hey, be careful, because that's when technically possible, because maybe the API is there, but the user has disabled the feature, or for some reason, that API is there, but the capability is not, okay?

[00:04:58]
So, I mean, the API might work, but maybe the feature is not there. We have some light-green API's that it's fairly mature. You can use them. The problem is that, not every browser is on it. Sometimes it's about, let's say how big is the browser. Sometimes it's about some commercial discussions behind scenes.

[00:05:28]
So I'm saying that just to say this really quickly, light-green API's are 99% working on Chrome, on Chromium-based browsers, that's Google Chrome, Microsoft Edge, Samsung Internet. And then we have other browsers, such as Firefox and Safari, that are not typically implemented them. And also there are some, Chromium-based browsers that are disabling that feature, such as Brave.

[00:05:58]
Today, Brave, Firefox, and Safari are kind of a group, and they will have Microsoft and Google with Edge and Chrome that they have probably today, 80% of the market. Anyway, that they are saying we wanna push these API's, and the other group says no, we don't wanna to push those API's.

[00:06:18]
I don't wanna get into that discussion of why what's going on? What's the problem, okay? But just have in mind that we have a lot of API's that we will see today, that are working pretty good, but only on Chromium-based browser. And that means not for example, on iPhone or iPad.

[00:06:37]
So, do we have iPhone users here? Right, iPad users? Yeah, are you using Chrome or Safari on your iPhone?
>> Mostly Safari.
>> Mostly Safari. Do we have Chrome installed? Do you use it?
>> Sometimes.
>> Sometimes. Do you know that Chrome on iOS is not really Chrome?

[00:06:55]
What? So it has the icon, yeah, it looks like Chrome, it's connected to your Google account, but as of today, 2023, actually it's Safari with a different scheme. And the same happens on Firefox, and the same happens on any other browser. It's not actually a Google's responsibility, it's an Apple restriction.

[00:07:21]
So on iOS on the App Store, that's iOS and iPad OS, you cannot publish an app with a different Web rendering engine. So if you wanna publish a browser, that browser must use the built-in WebKit engine. It's called the WKWebView internally, which means that the API's are just the same as in Safari.

[00:07:48]
In fact, sometimes not even the same, sometimes are less, because that Web view is more limited than Safari. So meaning that Google Chrome on iOS, it's not really Google Chrome. So just have that in mind when we're talking about compatibility, because maybe we're saying, hey, this works in Google Chrome.

[00:08:09]
And you're thinking well, on my iPhone, I have Chrome I will try that. Well, no, that's not how that works. Yes.
>> Does that also apply to MacBooks.
>> No, it doesn't apply to the to the Mac. So on Mac OS, Google Chrome is Google Chrome, Firefox in Firefox and there is no restriction for that.

[00:08:27]
So that restriction applies only on iOS and iPad OS. That might change in the future, I don't know. I mean, that has been like that since the beginning of iOS, and now, there are a lot of legal requirements in Europe, in Australia, in UK, that they're pushing Apple into openness because it doesn't make too much sense.

[00:08:50]
So it might change in the future. In fact, both Firefox and Chrome, they're preparing themselves for that moment. Already today, a project in the open source repository, they're testing the engine in iOS. So it's like they're preparing the work, because that might happen, okay, in the near future.

[00:09:16]
I don't know, but it might happen, okay? There was a question there?
>> Yeah, so with iOS Chrome, then with an update, would that just be the Safaris update then for that specific?-
>> That's a good question. Actually, today, you cannot update Safari in the App Store. So Safari goes with the OS.

[00:09:35]
So to update Safari, Safari is not actually in the App Store. So if you search for Safari in the App Store on iOS, you won't find it. So you cannot update Safari individually, you update the OS. So the whole iOS, so iOS 16.4 comes with a new Safari version.

[00:09:54]
And when you update the OS, you're also updating the engine that empowers other browsers, because it's called the WKWebView.
>> So the dot did for that, like that Chrome that Chrome would be different from like the Mac's Chrome. That'd be-
>> Yeah, it's completely different.
>> Okay,
>> So it's actually 99% Safari.

[00:10:16]
So there is still a 1% difference, but it's 99% Safari. So in terms of how CSS is being rendered, in terms of your HTML compatibility, in terms of performance, it's Safari, not Chrome. So in fact, when Chrome took that decision, I think it was 12 years ago, I was at Google I/O in Montain View.

[00:10:37]
At that event, when they presented Chrome for iOS, and it was a big surprise, because at that moment I remember I wrote an article, I titled that article pseudo browsers. So this is the new era of pseudo browsers, because it's not really a browser. I mean, from a user's point of view, it's a browser, it's an app that browses the Web.

[00:10:56]
But from a developer's point of view, it's not a different browser, it's just a skin over Safari, kind of. In fact, letme prove that. If we search for Chrome for iOS user-agent, do you know what the user-agent is? It's how the browser identifies itself to the server, when you make an HTTP request, that's how on your server and Node.js, you know which browser is accessing.

[00:11:25]
So this is a user-agent in Chrome for iOS, okay, this one. So when you look at the string you won't see the Chrome keyword, okay? It says, well, there is a history of why there is Gecko. There are several things here, but you won't find that the term Chrome.

[00:11:47]
Why? Because Chrome on iOS didn't want us, or backend developers to get the wrong idea that that's Chrome. In fact, it says CriOS, that seems to be crying or something like that. It's CriOS, that is, Chromium for iOS or something like that, but it doesn't say Chrome. On Android or on desktop, the user-agent actually uses the string Chrome, okay?

[00:12:12]
The same happens on Firefox, the same happens on Edge, because it happens on every browser on iOS. The only exception to that is proxy-based browsers, also known as cloud-based browsers, that are not pretty common in the US or Europe. There are more common, there are more users in Africa, in Southeast Asia, some Latin American countries.

[00:12:37]
For example, Opera Mini, that still has like 1% of the market share. So basically Opera Mini, when you browse the Web, you're not actually downloading the files, the HTML, the CSS, and the Javascript on your phone, there is a cloud server that is rendering that website in the cloud, and when you are receiving on your phone, it's a compressed version already pre-render.

[00:13:04]
And because of that, Opera Mini is not using Safari. It's using a browser that runs on a server, and because it runs on the server, Apple says, okay, it's fine to me because it's not running on the device. Okay, that's the only exception. But this is just a warning to have in mind that when we are saying this works on Chrome, that's not the case on Chrome and iOS at least today, okay?

[00:13:28]
It's safari, actually.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now