 Welcome back to the 2018 THDP203 World Cup of Web Features. Uh, yes. I thought I should just let you carry on. That was quite good. So in the previous episode, we looked at eight features and we whittled them down to our favorite, like one of them. Of those eight features, yeah. Of those eight features. And if you haven't seen that video, then. You should. Yeah, this will maybe make more sense. And if you haven't seen it. Spoiler alert. Yeah, it was Skrullsnap was our favorite. One. I've got to repeat who Skrullsnap won against, but. No. But we're going to take a look at the next feature. And I would like to talk about Async Clipboard. Probably that's what it says on the tin, doesn't it? It is. Well, do you remember Clipboard? Remember doing this. Exec command. That is some API design straight out of hell. Yes. Yes, it is. And you would have to, if you wanted to copy some text, you would have to create an input element, because that's where you could do the focus and selecting properly. And setting markers in the DOM, text selection markers, which gets even worse. Which is horrible. You do copy. You've changed focus. You've changed selection. This is very destructive things for a page to be doing. And support was iffy, then you had your fallback flash plug-in until flash support got, yeah. Horrible. So this is, it's Async, so it's for large content. It's less likely to be blocking on the main thread, which is great. But I think the main cell here is, isn't that nice? It's so nice. Isn't that nice? And I'm guessing there is not just write text and retext, but there's also going to be files and images. And because you have screenshots on many operators, you just go onto the Clipboard first. Yeah, potentially in many formats. So that bit is not there yet. Yeah. That's something that's, it's just text for now. Still winning already. But absolutely, absolutely winning. So that brings us on to the next one, which is typed OM. That's a Houdini. That's typed OM. That's a Houdini bit. So it's actually one of the lower, almost less exciting APIs of Houdini. You're really selling it? Yeah. That it's very necessary to make all the other ones happen. And it's actually addressing a huge pain point, I think, of many developers. Because it gives types to CSS stylings. OK. So you might know getComputedStyles or just the .Style property on an element. And there's now the typed versions, which are either element.ComputedStyleMap or the AttributeStyleMap. OK. And so now we have a StyleMap. So what does it actually mean? A StyleMap basically has getters and gives you separate number values and their units. So now you don't want to do string concatenation and like some weird splitting or all these different things to figure out what is the actual numeric value. Much easier to do math, which you sometimes have to do, or just analyze them and figure certain things out. Well, before you, I really like what they've done here. So we've got Units, PX, which is nice and short. It's what you write in CSS to have that. And then here we have Percent. Yeah. I don't remember why, but there was a reason. There was a reason. OK. That's good. That's good. It actually goes further than that, because you can also create these types this way. So you can now have basically a small part of the CSS parser exposed and that you can just put in the string and it gives you back that kind of typing. You can create them yourselves and then set them this way. But even more excitingly, you have Add and Subtract on these. You can actually do math. Oh. So you do it the same way the calc works in CSS. So this actually, if it's the same type, the same unit length, it will just coalesce. If you have different, like here I'm adding 5% to 10 pixels, it will actually give you a proper arithmetic tree. So you can do all these analysis or reorder them, all these things you sometimes want to do without having to re-implement a CSS parser. OK. I'm feeling that I might know what has won here. Maybe. Let's go back to the tree. I don't remember what you talk about. Oh, yeah. Oh, it's so exciting. You can't remember it even 30 seconds later or whatever it was. I just think as a clipboard, it's good. Yeah. It's not that often that you need type to M directly. You need them for a lot of your linear APIs. And if you need type to M, it is so huge to have it. Yes. Then again, you don't need clipboard that often as well, I guess, unless in certain circumstances. So yeah, I'm going to go with type to M. OK. OK. I agree. So as in clipboard, it's a big improvement to what we had. But it's just a lot going on in type to M, isn't it? It feels like it wins just for being a bigger feature. It's definitely something I would have loved in the past, like even the small parts of that. I love when I get excited. It's jingling. And there were some experiments where they had like animation heavy sites. And they basically rewrote them with type to M and actually got 80% faster. It's an extreme case. That's a big number. I'm going to put it through. That goes through. Right. Next, steady on, because the next feature is update via cache. OK. Yeah. So this is a service worker feature. I'm not surprised. What happened? We ran this problem where we were checking for updates on the service worker using the HTTP cache, how things normally happen everywhere for everything else. Oh, that cache. That cache, the HTTP cache. But we would always time things out after 24 hours. If it was over 24 hours old, we would go to the network regardless of what was in the cache. Ignoring the caching headers. A lot of developers still had a lot of issues with that because they didn't have control over the headers for one particular JavaScript file, like the service worker. Yeah. Good app pages, I think, is a good example where you don't have control over your headers. Exactly. Exactly. Yeah, they have a default cache of like 10 minutes or something random. Yeah. So we introduced update via cache where you can tell the service worker what to go to the HTTP cache for, what to ignore. So for the source, you tell the browser whether to respect the HTTP cache for the service worker file specifically. Yes. OK. So you update via cache all, which was the old default. It's not the default anymore. There's imports, which is saying, don't go to the cache for the main service worker file, but anything it imports, you can go to the cache file. That's cool. That's the new default. Or you can say, ignore the cache for everything. All right. That's my feature. My feature. All right, what was my feature? Desktop PWAs. So I have no core templates because it's, once again, something that doesn't really change the way you write code or gives you any new capabilities. But it's basically the whole install to home screen, but on desktop. Make it its own window. Make it its own button in the launcher or in the start menu or whatever you have nowadays. And Edge has it kind of with allowing you to submit PWAs to the store? Yeah, they were ahead of everyone in doing it. But you still couldn't just install something from Edge to your desktop. That wasn't possible. It was only you have to submit it to the store. I got it proved, I think. And I got in there. So now with Chrome on Chrome OS and on Windows and I think on Mac behind the flag. Yeah, that's behind the flag. You can legit open the menu and say, install this. And then it gets into the launcher with its own window, its own icon, its own command tab spot and all these things. So becoming a proper application on your desktop. It's kind of replacing Electron for a lot of simple cases. Hopefully. Hopefully. OK, so this. This is a difficult one because when I talk about Update via Cache, the big news there is that we changed the default. It's not a new feature. It's a change. So shaky ground. Desktop PWAs, it's not a developer-facing feature. Well, it kind of is because it's something you can talk about my app can run on the desktop. It's not even on all operating systems. Yeah, it's just a weak ground. The two things that are actually have been really well received. I think Update via Cache solves. Oh, really? So I was going to say, I think desktop PWAs, it's such a major thing. It's something like it's moving the web into native space. I guess you're actually right. It just doesn't feel as real to me yet. Because there's no direct APIs for it. Yeah, and also there's no install banner, I think, on desktop. It doesn't prompt you to do it. You need to set up some JavaScript to have a button for it. I'm fine with letting desktop PWAs through. OK, well, I find in these sort of things I feel like you've done me a favor by siding with me, which is weird because it's against the service worker feature. You set yourself up, mate. I did, didn't I? And I worry that I now owe you one maybe in a later round. I'll call in that favor when I need it. OK, so that moves desktop PWAs into the next round. Into round two. So type 2M desktop PWAs. Type 2M. I'm really torn about this one. Yeah, actually, the more I think about it, now type them. Because it doesn't allow me to write better code. Like desktop PWAs don't give me necessary new capabilities. I'm not. They don't make your life easier as a web developer. They might make it easier to get more work because you're able to do things that are more like native apps. And also I feel like lots of other features are still missing to make most of the things I do want to have in a separate app actually possible in a web app. File access is one of the main things that comes to mind. So many apps I would like to have as a proper app are still not possible on the web. So the exceptions would be like, yeah, what's that web can I can install? I guess. I'm also quite not too sad about that being a tab. I feel like a lot of people are going to be screaming at the screen right now. I mean, they always do. It is YouTube after all. Go nuts in the comments. OK, so next up, as you may have seen on the screen I actually find this really difficult to read because I kind of go bitmap prerender. Bitmap prerender. Or bitmap prerenderer. OK, it's bitmap prerenderer. Bitmap prerenderer. Yeah, check it out. Look at this. It says bitmap renderer here. No, I'm now wondering if I. I think it's bitmap renderer, not bitmap prerenderer because I think it is bitmap renderer, not bitmap prerenderer. OK, yes, see it's difficult to read. OK, so it jingles when I get angry as well. It's bitmap renderer. Of course it's bitmap renderer. Right, here it is. Create a canvas, but get context. Oh, it's a new get context type. It's a new context type. And what you can do with this is you can create an image bitmap, which is an existing feature. Separate feature, nothing to do with this. You can transfer it onto the canvas. So it's just a fast path for basic canvas draw image. Yeah. That's pretty cool, but it's like blitting. I'm guessing this is super fast under the hood where there's all the other layers are skipped. It's a little bit faster. It is very efficient on memory because this is transfer. Yeah. This image object is now, oh, yeah, it's been transferred in the same way as if you were crossing over to a worker. So the data buffer is now neutered, as it's called. Neutered, exactly. Great. Those game engines are going to be happy. All right, going up against the bitmap pre-render is WebLogs. I have many fields, both good and bad about WebLogs. Oh, interesting. Let's take a look at the API. Basically, sometimes you have a resource that might be shared between multiple workers or even multiple tabs of your web app via IDB or something else that is shared across your origin. The service locker, for example. Yes. And so you have some code, and it does something. You don't need the lock. And when you need a lock, you request a lock by a name. It's just a string name. And then an async function will get invoked with a lock once you have that lock. And then you run your code. Because that might not be straight away, because something else has got a lock right here. And then once that async function is done running, the lock will be released, and you can continue normally. And there is also a concept of shared logs and exclusive logs. Shared logs, if you request a shared log, and you can get it if there's only other shared logs. If you request an exclusive one, you have to wait until there's no other logs and you look at an exclusive log. Because shared logs are fine if lots of things are reading from something. Exclusive log is for writing. I like that I went with shared and exclusive though, because there is multiple patterns, not just to read, write pattern. Because sometimes you might be reading and writing, but disjoint parts of an array. So that would also work. So yeah, so this is something that lots of people have requested. The more I think of it, the more I think it's actually necessary. I think there's also a lot to be done without this. Instead of using the actual pattern where you have one designated thread, but that's a different story. Yeah. Why have you done underscores? This is not very. Because I copy pasted it from MDN. Good excuse. It's a good excuse. That's a good way out of it, because I dislike that in JavaScript. It's not like any other APIs. Right. I mean, it feels to me like WebLocks is just a more. It probably has, on average, more use cases than the Bitmap render. It's kind of niche for probably game engines, probably some image processing. It's good if you've got an off-screen canvas and you want to make it transfer across. But yeah, let's see what we put WebLocks through. Let's declare WebLocks the winner of round number seven. Round number seven. OK. Right, so WebLocks is through to the next round. What are we going to look at now? I want to talk about reach, reach a policy. OK, it's the font again. This is feature policy. Lots of buzzes around feature policies at CDS. Yes, there was. So here's basically how it works. This is a header. And you can serve this on your page. And it's essentially, it's like CSP. It's like CSP for features. Exactly. So here I'm saying, this page may not use geolocation. So you're declining yourself access to the geolocation API, which is good, because that means when somebody evil injects JavaScript code, they can't do these things. Exactly, exactly. And you can also specify it for an iframe. So that's cool. You're saying this iframe may not use geolocation. And there's lots of features. Great for ads, I would presume. Yes, exactly. Yeah, you probably want to put quite a lot of this on if you really want to restrict what, if you've got me. And there's a massive set of feature policies, right? Like for like, if your images are too big for this. So that one, yes, that is one, but that's an experimental one that's not released. The ones that are released is auto play, camera, document.domain, stopping that, which I quite like, because that might come with performance benefits later in line. EME, full screen, geolocation, obviously. Microphone midi, payments stuff. VR, I've written a speaker here. Can't remember what that is now. Synchronous XHR as well. Oh, sync. Yeah. That's all good stuff. All right. Absolutely, because that's something you would definitely want to stop. And I think in the future it's like, if you opt out of a certain subset of features, you actually get, there could be the option to enable a faster path in the browser, because if you can opt out of legacy stuff, the browser knows, oh, don't need the legacy stuff, I can be faster, like enable certain optimizations potentially in the future. Yes, absolutely, absolutely. Right. What have you got? Coming up next is CSS Paint API. Oh, yeah. Okay. I would forward people to my CDS talk. Oh, yeah. But maybe that's a 50 minute video if you want to see the unedited version. Yeah, I see a lot of things went wrong for you. A little bit. Yeah. Anyway, let's get the quick version of CSS Paint API. Basically, it allows you to define your own paint routine whenever CSS expects an image. So just before the squircle is, is the point where your talk failed at CDS? Yes. We had a catastrophic laptop meltdown. I did. And yet you've brought it up here. Yes, I wanted to absolve the squircle from the curse that is crushing it. Understood, understood. Sorry, I interrupted. Yeah, so a squircle is basically a square that is mathematically closer to a circle than it's a way to paint a rectangle with rounded corners. But it looks a bit more natural than how rounded corners happen. For example, and browsers can do that. You have border radius, and if you don't like how it looks, then you're kind of screwed. And now with CSS Paint, you can basically hook into the actual paint part of the rendering pipeline and define your own paint routine. So here I basically load a module, which is a JavaScript file, into the paint workload and I use a name. Then in that file, I can define the paint routine and basically get the same context like a canvas. And just define what I'm going to draw. And you get the geometry, which is going to be telling you stuff like... How big is the element, and the properties, what are the styles on this element, and you can incorporate all of those in your JavaScript code. And the good thing is that in the very near future, this code is going to run off the main thread, basically not costing you any main thread budgets that you only have like 60 milliseconds per frame. Because previously, if you used Canvas, it could end up costing you a frame budget. Is it on main thread now? Currently it is. Okay, like Canvas, right? But the feature of workloads in all the units that they are migratable. So whenever we think it's feasible to move it to a different thread, we can without you having to change your code. Okay, okay, right. So this allows you to reduce the DOM and stuff. Right, so I guess we should have a think about those features. This is a tough one. Is it? I think. I was going to go straight in with CSS Painting. Yeah, I'm going to lean towards feature policy. But to be honest, that's mostly because of the projected future and not of what it gives you right now. Because right now it's mostly a debugging slash development feature, like opting out of features. But I have the hope that it is our way out of supporting legacy stuff for long amounts of time. Well, document.domain, that's one of those. And I think if feature policy today, like you said, you put this combination of things in, this stuff is going to be twice as fast. Yeah. Then I think I would be putting it through. Yeah, too, but that's not what it is today. The range of things that CSS Paint API sort of opens up, it feels like I'm more excited about it. Who am I? I'm more excited about what it can do today. Flutter is using it as well for their web port, for example, which I published a blog post about to do all the mask imaging and form morphing. And all these things is actually pretty impressive. The users that I didn't necessarily think of myself. So it is quite good. So let's call CSS Paint API. I'm going to put it through. So now we have web logs versus CSS Paint API. The CSS Paint API. Two developer features, one of them many more use cases, in my opinion, on average than the other one. Oh, which, which, because I... CSS Paint API, like for me it would be a CSS Paint API. There's more use cases there. Yeah. It makes a lot of new things possible, but also makes all things much more efficient. And especially on low-end devices where you're under memory constraints, it just gives you, makes more visual things possible. It feels the, gives the web a more high-fidelity feel, enables more high-fidelity UIs, I guess. And it's the first feature that's really opening up CSS. And I can see there being more little micro libraries released with CSS. It's a very extensible web API in that you are now hooking into the actual engine. I really like web logs. I really do. But I think you're right. I'm going to put CSS Paint API through to the next round. And that gives us another semi-finalist to decide as well. Yeah, now we have to decide between typed OM and CSS. So Houdini API versus Houdini API. Oh, this is unfortunate, isn't it? I mean, it was, it's going to happen at some point. Yeah. Depends on how we judge them. On average, the problems that I encounter when building a web app. Paint API is more useful than typed OM. And both of them are currently, as far as I know, pretty much Chrome only. Typed OM has a lot of lower level use cases, right? Like if you were trying to figure out layout stuff, this is going to become handy. Even the amount of times I've written little rubbish pauses just to take those CSS values and break them out. So that's where I guess my experience differs, because me, the problems that typed OM solves, I encounter much less than the problems that Paint API solves. Mm. We should just do that for 15 minutes and extended cut. All right, let's find. So you would say typed OM. You're leaning towards typed OM. Let's go paint API. It is, I'm more interested in the tooling that's going to be built around CSS Paint API. Yeah. I think that's a really tough one. Yeah. I'm hoping there will be an ecosystem of off-the-shelf modules with all the effects, like a ripple, and all the things that you can potentially build. Yeah, I do think that's interesting. And it also means we can come up with a first semi-finalist we can come up with. Oh, and this is too, I mean, I was about to say, this is two good ones. You would hope at this later stage in the competition that this would be two good ones, but it definitely is. Two CSS features, once again. I see a pattern, I think. Yeah, that's interesting. This is a really tough one, actually. I would look. The amount of times that I've wanted scroll snap and I've either had to implement it in JavaScript and it's been horrible because it's been laggy. Like as soon as things are moving, it's fast because you're on the compositor. But that initial picking up the touch event to starting to do the movement, it often involves setting up a lot of layers on the compositor. And then you do pretend physics and you have to do touch and pointer events and mouse events. Yes, it's a horrible moment where the user swipes. And then because it's happened to go into your code, it kind of is a bit of a break before it then flings. And then you figure out the ramp up curves and everything. And no, I agree. Scroll snap removes so much code and it's much more cross-browser than CSS Paint currently is. That is true, actually. Scroll snap is around in Chrome and Safari, but there is a sort of older standard that's available in all the other browsers. OK, yeah, I'll give it extra points because it is something that you can use today in projects. OK, so our finalist. So we are 50% through. We are 50% through. Whittle down 16 features to one. And we will do all of that all over again with another 16 features. I regret doing this already. Well done, us. Yep. How do we sign this off? I don't know. See you next time. Is that right? Is that OK? Next video, next on the other, on the flips. I don't know. Yeah, soon next one. Subscribe. Keep getting people back every day. Why didn't we do one episode per one of these? So they've been much better. Anyway, so good at this. We're so good at this. See you next time. See you next time.