 Because you don't always speak fast. Just like checkmarks appearing on. Welcome back to the 2003-2018 web development feature World Championship. Contest. 2018, yes. Yeah, well, we've been looking at web features that have landed in Chrome in 2018 because I went on to all of the new in Chrome posts and ripped them out. Thanks, Pete. Put them in. Yes, thank you, Pete. Put them into a chart here. And we whittled 16 of them down to one. Scroll snap. That's the first finalist. Yeah, that was a spoiler if you haven't watched the other videos. So there's no point watching them now. It sucks to be you. Yeah, well, it sucks to be us because we don't get the views. Fair enough. All the way back to the bottom. All the way back to the bottom. We're going to look at some more features. And the first one I want to talk about is web off public key credential. Yes. Yes, it is. This is part of the web off API, the credential management stuff, which is an API I've not really looked at. And I struggled to find an example of this. I found a demo. I struggled to get the code out of it, which is really bad of me. It was good. But basically, I can describe what the feature's going to do. A Zufba. What's a Zufba? A Zufba. I have no idea what that is. Well, I'm going to press it. User verifying platform authenticator is not available. That's not even what that. Oh, OK, so user verifying platform authenticator. Oh, who knows? That was exciting, though, wasn't it? Is this like the number of things maybe integrated? No, this is the number of things. It's now asking me to insert a security key. And it can be a Bluetooth one or a USB one. Do you have one? No. But I tried it earlier. And it will give you the key details, like the private parts, but not the private parts. I won't say private parts. You don't see the private parts. Well, that's good. It gives you enough details so you can authenticate that user later on. OK, so basically, I could allow users to skip all kinds of user names, slash passwords, thingamajigs, and just be like, yes, put in your nubby. Put in your nubby. Is that a name for those things? Is that a brand name? I don't know. Sounds horrendous. But yes, so you use this with GitHub, being able to use it. That's so convenient. Yeah, I love that. The two-factor authentication. Maybe we don't use that. I don't know. Because I think for now it was pretty much Chrome only that had native support for those things. Yes, that is true. So yes, that is public web key, credential thing. Going up against what public key, credential thing is a toggle attribute. Now, this code sample, the code I've written for this is going to blow you away. OK, here we go. Oh, that's it, is it? Can I guess? Yes, go take a wild guess. It's going to toggle that attribute, isn't it? It is. Isn't it brilliant? So OK, it's literally like classless toggle but for attributes. Right. It also has the second Boolean parameter if you wanted to toggle on classless does. But most of the time you just want to toggle a class. This is going to be destructive though, because if I toggle, because it could have a value, it could be hidden equals something. That's actually true, I didn't check that if you can pass a value. No, I don't think you can. Yeah, but there you go. So cool. That's it. OK, OK, so we'll go back to the brackets. Back to the brackets. We've got toggle attribute versus. Now, although I really badly solved the public key, credential thing. I'm actually so very excited about the prospect of being able to access two-factor authentication tokens. It's one of those things that, credentials, payments, are the things where native apps are so far ahead, all were. And so having these sort of things. If I can at some point write a web app where people can authenticate with a fingerprint or something, I don't have to loop them through authentication flow in my back end. But just do it all client side, winning. Absolutely winning. Brilliant. There we go. Put it through. OK, let's look at our next couple of features. I would like to talk about off-screen canvas. Oh, I know you're excited about that one. We've already talked about this, haven't we? A little bit. I think we talked about in the podcast, but not. Yes, a little bit. And about the Bitmap renderer as well. The Bitmap pre-renderer over over over. Oh, whatever it is. Off-screen canvas. There you go. It's like a canvas, but off-screen. But off-screen. So therefore, available in the worker. Yeah, exactly. That's exciting. So you want to do bitmap manipulation in the worker. That's great. You can also proxy it. So you're doing the computation in the worker. Because this has just got regular canvas now, 2D, WebGL. But you can also sort of transfer it. Create it on the main thread. Send it over to a worker. And all the paint operation the worker does magically appear on the screen. Well, yeah, the other way around. Yeah, so your main thread, the bit of your web page is being updated by the worker, essentially. Which is amazing. I do think is amazing. Going up against this is the focus management API. Now, this is a very fancy word that was mentioned in one of the new Engram blog posts with no explanation of what this API is, no code sample, no link to the spec. And I googled it. It was very hard to find. It turns out it's the focus method. So you might remember you can focus in elements. I've been around for a while. It's very old. So what's new about this, it takes a new options object now, which has exactly one option. And that option is prevent scroll. So you can focus an element without scrolling to it. It almost feels like calling this the scroll management API is a little. Someone wanted to feel a jit. That's someone making up their own job title of master of development or something. I own the focus management API. Thank you very much. Yeah, OK. So it's just one option. But it's useful. Maybe, yeah, sure. If you wanted to send focus for accessibility reasons, especially when you didn't want it messing around with the scroll position. Yeah, I guess. But that probably is use cases. That's why it got standardized. I did not. But probably is use cases. That's why it got standardized. That's a good way to think about it. I have not run into this myself. And it's, yeah. I feel like I might have, like, if the default where the browser was scrolled might still be obscured by, like, a position fixed element. I don't know. Yeah, OK. Yeah, OK. Let's stop talking. So putting up against each other, it's off-screen cameras with focus. If you add it, it's off-screen cameras. I'm going to put off-screen cameras through. It's not a big discussion right there. I mean, just because it does so much more, it's something that, well, from a selfish point of view, I've wanted it for ages. Although there's a negative point against it, because we tried to use off-screen cameras for Squoosh. And there's a bug in Chrome. Yeah, it forces a GPU switch. If you have a laptop with two GPUs, an integrated one, which is not as powerful, but does most of the time. And the discrete one for, like, high power things, for some reason, it forces a switch. And that's super janky. Yes. It's like a one-second pass in the system. Because we were doing, I was doing some rotation of an image, and it meant with very little code in a worker, it wouldn't, I was actually rotating big images, so it was taking 300 milliseconds, even with the power of the GPU and everything. But that 300 milliseconds, like, moving that off the main thread, was just destroyed by the one-second of operating system jank you get with a GPU switch. So that's a shame. So as a result of off-screen cameras winning, we now have to decide web of public pre-credential API versus off-screen canvas. Off-screen canvas. So what are we talking about the current incarnation of off-screen canvas or the projected future of off-screen canvas? Well, so what do you mean in terms of, like, fix that? Do we incorporate this bug, for example? Let's assume the bug is going to get fixed. Yeah, because I think off-screen canvas is massive. And yes, for me, it would be off-screen canvas. I think if we were talking about web off as a whole, not just this sort of part of web off, I think I'd be putting web off through, but I think I'm going to put. Yeah, you might have a point. I'm going to agree if you put off-screen canvas. Canvas. All right. That goes through to the quarter. I think the other problem is that I don't build apps a lot that have login. Maybe I should change it to get some experience with that. Ah, big web quiz. True. But we used Google. Yeah. OK, fine, fine. Let's look at the next set of features. I would like to talk to you about sensors. Sensors. Sensors. Specifically, the generic sensor API. And that is these things. Would you like an umbrella term for? We already had, I think, gyroscope, for example, for a long time now. Yes, it was like an event on the document or something. Yeah, motion changes or something. This brings them all together. There's a lot of sensors, yo. There's a lot of sensors. And these are the ones that are in Chrome now. But they all have a very similar API in that you get a reading event out of them. And then the properties of the object has changed so you'll get a slide. I think the event name really bugs me. Reading. Yeah, do you know what? Because when I first saw that, I thought that meant it has begun reading. Yeah, it would be like a star event in there or something. But you probably get an event every time there's a new data set for you available to read. I think it's not the verb reading. It's the noun. It's a reading. Which I would. I would think it to be a change event like we have a lot of. I'm sure there must be a reason why it's not a change event. And I think it's because it's debounced maybe. It's there now. It will stick around forever. So you get all these things. These are actually really useful. So that's kind of cool that they're there. Especially for XR. Yeah, all these things. All of that sort of stuff. All right, going up against these sensors is. I forgot that you might want to do one. Big int. Big int. A big int. A big int. So basically, you might have seen it before. Big int. This is a big int. It's a very big integer. That is a big integer. Yeah, because there's a magic n at the end. That's bigger than numbers I know, like 12 and 89. So we got the n at the end. Java could not know. So this is supposed to be a integer and not just a float number. And it can be arbitrarily big. Like Java will always be saving every digit and you can have multiplication and addition and all these things now working on arbitrarily large numbers. Division? There's a module low. That's probably integer division. I wouldn't. Oh, OK. Integer division. Integer division. Right. Awesome. Fun side fact. It is actually a new primitive pipe. Oh, excellent. Which is that we don't get those very often. No, symbol. It's been. Yeah, we got symbol. It's probably the most recent addition before it was number, object, function, string. Big int. OK, excellent. Right. So let's talk about them too. Census big int. Now, these both feel like things that not many developers are going to use. I have run into big integer concerns and chose to ignore them because there was no other way around them. Would you use big int for a small int? Hear me out. I realize this sounds stupid, but I'm going to try and rescue it in the next sentence. Would you use big int for small ints if you did not want floats to happen? Like, for instance, that you. Make sure it is always integer. So I'm thinking that if you were doing currency. Yeah. Yeah. Well, I'd be better if we said the same thing, but we didn't possibly reshoot this and edit it in. Let's leave it at that. Maybe, actually. Maybe. But also, I often, whenever you talk about certain. I wonder if these work in JSON, actually. Like, if you send them down from the server, if JSON powers will actually understand them. Nope. Probably not. The answer is no. That much I know. But there's oftentimes where I just don't want to worry about if I'm going to overflow. Whenever I build certain libraries, generating random UU IDs instead of distributing integers across an array, and then doing operations and I could just build one UU ID and then just slice them. There's many use cases where I see them as being useful. Sensors are more niche to me than big ins. I'm going to admit that they're still big ins are probably kind of niche and not. That's the thing, these are both really niche. Not really. I think sensors are more niche, except in XR land. Yeah. OK. Yeah. OK. Yeah. Yeah. OK. Yeah. OK. Mostly because I can't make a decision I'm going to. I'm going to let you make the decision. Big Int goes through to the next round. Excellent. Next up, here we go. It's the Lifecycle API. We did a big episode on this one. I don't even know how much we talk about it again. But it's this. It's the first time we show code about it, I think. Yeah, I think you're right, actually. It was a podcast one. In a way, it's just new events, but they're really useful. Yes. It takes stuff that mobile browsers already do, discarding tabs, because to save memory, it kind of wraps a spec around it. It also introduces this idea that a page will be frozen, which means that it's not running anymore, but the memory for it still exists so it can be resumed. So this is, if it's discarded as in it's taken out a memory and the user revisits the tab, the page is essentially reloaded, but you can detect that that happened. It's something that all native platforms have from literally version one life cycles of the first thing they build to recycle views to figure out where they go and the web didn't have it and now it does. So it's a massive step in actually building something that behaves more like an app and how you expect it. You sold it then I have. Let's see how you do on one of your own. What do I have? Server timings. I didn't know about this and I actually found it quite interesting. So server timings in and of themselves are literally just a new header. So it allows you to put a word in there and say like this request missed the cache, for example. You can have multiple server timings in a header. So I could, for example, add like this request took 2.4 milliseconds to be processed. So this is just random names. You can give them your own names. They're just names for these different timings. So I said this one has a flag set to true called missed cache. The CPU server timing is set to 2.4. If I wanted to, I could even add a description. And these are sent along with a response from the server. So you can send your server timings to the client. And over there, you basically use the performance docket entries by resource array, which for every resource you've requested on your page, you can now inspect. And in there, you have, so every entry is a resource. And each entry has an array of server timings. And so in there, you have the missed cache flag. You have the CPU thing that is set up there. What would you do with this data? Probably send it to your analytics to tie it to a user and be like, oh, a user on this device had problems. But the server was already slow and maybe correlated certain features. It's mostly analytics. Your server sends these things to the client. Yeah. So the client can send it. Yes, it sounds a bit weird, but the problem is that often when you have load balancers, they make decision based on, for example, the user agent. So these timings might differ depending on what the client is. So you want to tie these measurements to the client and ideally to that timing that might emit more measurements on the client side later on. Right, of course, because you could take the client processing performance stuff as well and tie that into one big analytic that you send. So maybe one user has an extraordinary large music collection, and so all the clients have become slow. But there's no way to tie these two timings together until now. Until now? Fair enough. OK, let's discuss these ones then. Still an easy one, I think. Oh, OK. I was going to say lifecycle. Yeah. OK, OK. That's good. I know there's many data driven people out there who get super excited about collecting more data. I'm excited for them. And statistics are great and everything. But for me, as developer, lifecycle is just a big hitter. Agreed. I'm excited about the sort of stuff we'll learn from server timings. I'm excited that hopefully things that Google Analytics will make that not something I have to implements. True, actually true, yeah. Although I guess maybe with some of the server stuff I would have to do that. But that's not a big deal. But yeah, lifecycle, for me, it just explains some platform things which have been under spect for so long. And to finally have them is a big deal. And now we need to figure out big int versus lifecycle API. I'm going to go lifecycle. Yeah, I agree. It's not a big discussion for me. Big int is great. And I love that we have it because all the libraries were super big. But again, it's niche while lifecycle is literally every app. Literally every app will probably touch this API if you want to do it right. And to be able to, especially on mobile, to be able to go back to a tab and have a way to, even though the page is closed, it re-loads. Restore the state. Restore the state. Yeah, absolutely. And this means we get to decide our next semi-firm list. Now that, that's rough. This is a tough one. This is a tough one, off-screen canvas versus lifecycle API. I know, so politically, in terms of the overarching, the story arc of the web, it would be lifecycle. For me personally, the things that I do on the web, it would be off-screen canvas. OK, so the Squoosh use case, which was doing things like rotation. Did we build an image compressor? We did. We finally built an image compressor. But doing things like rotation, resize, and that without experiencing main thread stuff. But generating a new Fev icon, all these little things that you often want to do. Yes, and that's, yeah, if you're generating a notification icon in a service worker, like, here's the two people that are a part of this chat to generate the icon for that. I'd like that. I worry it's niche. But then, so here's the thing. Lifecycles shouldn't be niche. Everyone should be doing it because everyone should enable their tab to come back to life in the same state that it was in before. That actually requires a big mentality shift, because right now, nobody writes apps in this way on the web. Well, if you do it with the URL, if all of your state is in the URL, you're fine. I guess, but in a lot of apps, that's hard. Like, if you think about, it's just a simple to-do list. You're in the process of writing a to-do. You switch tabs. It gets frozen or discarded. Nobody persists that half-written to-do to the URL bar. That's true. That's true. And you want to go back and still have your half-written to-do list there. Yeah, and it'll rely on something checking IDB on page load, which I know GitHub does a good job of. So it requires a big mentality shift, but so does moving work to a worker, as I have found out. It's very hard to get developers to in the mindsets. I think both of them. Because it's a pain. It is. I'm working on it, mate. I'm working on it. I'm going to say, I think we agree that life cycle is probably, in overarching, the more important problem to solve. Let's go with that. I'm definitely willing to go with that. Now we have life cycle APIs, our first second semifinalist. Our first second semifinalist. Exactly. That makes sense. So yeah, we're going to leave that there for this episode. Going to find our second second semifinalist in the second. And our second. And our winner, actually. Yes. We're going to find our second finalist. And while we're there, we may as well do the winner. I'm not ready for that. Oh, you want to say that as well? I don't know, maybe. Nothing's going to be linear. We've really messed this one up. We're going to get it right from now on.