Install Nothing: App UIs With Native Browser APIs

♪♪♪ Hey, how's everybody doing? Whoo! Sick. Cool. Hey. What's up? My name is Scott Talinsky. I am the co-host of the Syntax Podcast. It's a podcast I do three times a week with Wes Boss. We talk about JavaScript. It's pretty sick. I'm also an executive producer over at Sentry where I get to work on Syntax full-time. In fact, we're doing a lot over at Syntax right now, beyond just the podcast. We have a YouTube channel and a lot going on on the website, so check it out at syntax.fm.

So, what am I going to be talking about today? Well, we're going to be taking a look at some real demos, and all of these demos run entirely on HTML, CSS, and JavaScript. There's no frameworks, nothing, no build steps. These are going to be looking at new or potentially underutilised browser APIs, some of which you've probably seen before, some of which maybe you haven't, and maybe you didn't know you were able to use them today. So, again, all of these demos, they can be loaded directly into Chrome, no build, no framework.

In addition to that, after I show you a new API, I will be giving it a ship score, and that ship score is either going to be you should check it out now, something you should be aware of, you should try it now because it is really coming down the pipe, or you can ship it. You can ship it today. I have a lot of demos, and another QR code for you. I have so many demos for this talk, I couldn't fit them all in the slides, and not only that, I didn't want to spend too much time on the code itself. So I'm going to breeze through a lot of the code, but we're going to talk a lot about the APIs themselves. I will have this available at the end of the talk too, so I'm going to tab forward. You can find it on my website, Tolin.ski as well.

Have you ever built any of the following UIs? A modal, a menu, a mobile nav, a drawer, a slideshow? I would imagine so. These are the types of things that we build all the time, right? Typically, if you're building one of these things, you might reach for your JavaScript framework, right? Me personally, it's really easy to have a state variable and just toggle that state variable, throw a little animation on it, and the next thing you know, you have a modal, right?

But, you know, another thing we might do is head to npm install and bring in who knows what into our application. It could be anything. The first one I'm going to talk about is modals, alerts, and dialogues. The first demo we have here is just a basic modal. This is using the dialogue element in HTML. You can see it is still using JavaScript. In fact, most of these demos will still use JavaScript. We're just going to be using less JavaScript, and so all we're doing here really is some query selectors and calling show modal. Next thing you know, we have a modal. What's so cool about this is it applies a nert to your page so you don't have to do the overflow hidden trick to prevent scrolling. It also gives you keyboard shortcuts so you can hit escape to close it, but in addition to that, it captures your focus so you can start typing right away. All of these accessibility things that we would typically have to code ourselves. But not only that, we hardly have to write any JavaScript to get this working. You can use these techniques exactly with React, Vue, Solid, anything, you can use these techniques, right? It's not beholden to vanilla JS. The dialogue element. Could you ship the dialogue element today, and are you shipping the dialogue element today? Yes. This thing is available in 96 per cent of browsers.

I didn't tell you this, but each time we get a ship it, I'm going to have a break-dancing gif. This guy is the Olympic representative for the Netherlands in the Paris Olympics 2024. This is your Olympic representative. He's really good. All right. So you might have seen 96 per cent, thought, all right, 96 per cent, not 100, but a lot of these things are never going to get to 100, and if you see something 96, 95, anywhere in there, as long as it's supported by the big three, you can imagine that it's most likely shippable. Many of these things have polyfills if you need to support further back. I would imagine a lot of you are shipping Grid today. Grid only has 97.25 if it's unprefixed. Prefixed, even 97.7. Getting into that 97, 96 per cent range is pretty good. So if we wanted to animate this, we could bring in web animations API, or WAPI, and if we open this, you can see we get a nice little animated dialogue.

The web animations API is pretty simple. We are just toggling a couple of values here. I'll stop moving. Sorry. You just toggle a couple of values. Then you call this .animate method. Next thing you know, you have an animation. In fact, this demo has zero CSS. Well, it has some very basic CSS to apply to make it look pretty, but the animation, the positioning, all the important things will work with no CSS here, and you get all that through the web animations API.

This is what I'm sure many of you are aware of, but if you aren't, the web animations API is extremely well supported and has been around for a bit. This guy's name is Menno. He is the other Olympic representative from the Netherlands in 2024. But you can see this one goes back. 84, Safari 13.1. So web animations API, it can save you from having to import a whole animation library. Now, I like animation libraries. I use a lot myself. They can make things really easy. Magic transforms and stuff. But sometimes you just don't need one, right?

And even less of needing one is the view transitions API. I know Fred talked about this a little bit earlier, but you can see the JavaScript in this one is even a little bit less. We're mostly handling the close and open events, and we're just basically calling document.startTransition. We're wrapping that in and we're just calling dialogue.showModal. Check it out. That's it. Nice little fade in. I'm not sure if the FPS is getting that, but it's a nice little fade in that you get. That's the default style. I did not apply any CSS to this transition. By default, you wrap something in a start view transition.

You get a fade. It's pretty sick. So the view transitions API. Can you ship this today? It's 72 per cent but I'm going to say ship it, because this API is actually pretty easy to work around if you're not animating.

So, for instance, if you want to do these animations, you can do them, and many of these things will still work. In fact, a lot of the automatic transitions you get from the view transitions API kind of fall back to nothing. They just don't animate. And if it doesn't support, doesn't animate on the browser, the browser it doesn't work on, hey, that's fine. They did announce this week or last week that it's coming in Safari 18 officially. That's great. We will have it there. Cool.

So you can also do this with CSS. In fact, this is all the JavaScript we need, and check this out. We still get the same escape key, everything works, it still captures our keyboard, and this time we don't even have to program the animation on fade out when you hit the escape key. With the other options, you're going to have to do that. This is being done with a couple of really neat APIs that you will see a couple of times in this talk today. This is being done with one, allow discrete. Allow discrete to me is kind of one of the coolest things coming to CSS. It allows you to transition, display none, which, I mean, that's the kind of thing that we used to use jQuery for, to slide in and slide out. Now you can do it with CSS.

Likewise, there's another new API here, starting style. Starting style might be one of the most interesting ones to me too. This API is essentially saying what is the style of something before it enters the DOM? In React world, you might have had like React transition library that applies a class to something and quickly applies another class and does the transition that way, same thing when it's animating out. This is basically that but in CSS. You don't have to write any JavaScript to do this. And I'm not against writing JavaScript, by the way. I write a lot of JavaScript. I think if you can let the browser do it, as Bruce said, let the browser do it. So starting style, one of the most exciting new APIs.

Can you use this today? Sadly, not. But you should try it. It has been in Safari since version 17. You will notice Firefox is going to be the one lagging behind in all of these. But you should try it because I think this API is really neat. In the fallback, it is nice and easy if you don't mind not having it animate. That's Vin Diesel, by the way. Yes, seriously!

Next one, allow discrete. Allow discrete? Not even close. So this is one we are going to want to check out. It is very exciting, but we are just going to have to check this one out for now. Be aware of it. It's coming. All right.

This section is really super interesting to me, menus and popovers. So a basic popover looks like this. There's no JavaScript here whatsoever. The CSS is only used to make it look pretty. Nothing is doing anything. Check this out. Pops. And not only that, it gets your keyboard. You can immediately make this accessible. You hit escape key, it closes. This thing works. No JavaScript, you have a popover. What's really interesting about this is it puts it on something called the top layer. The top layer sits on top of everything else, it has its own context, and therefore, you never have to worry about zindex. There is no zindex applied to this element.

There is no zindex applied to this element. None whatsoever. And it will always sit on top of everything because of top layer.

In addition, you can get some actual controlled actions with this. So with this, you can say popover target action show, popover target action hide, and get a little bit more control over it than just having whatever the default toggle is, right? And that all works.

So can you use popover today to toggle a popover with no JavaScript? Yes. You can use this today. 96 per cent global usage. It's in every browser.

If you want to get into animating these things, this is where it gets a little bit more tough. Not only that, there's a fatal flaw with the top layer that we haven't necessarily talked about. The thing with the top layer is when you add something to the top layer, and you want to position it relatively, you can't position it relatively because it's in its own context.

So if you wanted to have it sit underneath another item, let's say you're building a literal menu like what we're doing here, you usually want it to sit underneath that button. And we can't necessarily do that. So the way you approach it now is with JavaScript.

I click this. You can see it's here. If I scroll, it stays here. Works really nice. I get all the keyboard accessibility shortcuts that I want for this.

The only thing I'm doing here that's really interesting is I'm calling an update position function with a git bounding client rect. I'm running that on resize and re-scroll. And then I'm doing a basic animation with the web animations API. That gets us there pretty good.

Works really nice. I get all the keyboard accessibility shortcuts that I want for this. The only thing I'm doing here that's really interesting is I'm calling an update position function with a git bounding client rect. I'm running that on resize and re-scroll. And then I'm doing a basic animation with the web animations API. That gets us there pretty good.

It's quite a bit of JavaScript compared to what you might write in your JavaScript framework. It's not bad, though. In fact, I wrote a Svelte action for this exact thing to anchor it, and I can just tuck it all nice and neat underneath that action. So could we do this whole thing with CSS only? Check it out. Hit that. We get the animation. We get everything that we want here. No JavaScript whatsoever. That's a menu. How many times have you ever built a menu like that with no JavaScript? I have not. So you can do that with another new API called Anchor, and Anchor, you first set an anchor name, you give it a name, then you tell the thing you want to anchor how to use it.

So you say I would like the top to anchor to the bottom, I would like the left to anchor to the left. Pins it up nice and neat. It's a really cool API. In addition, we're also using starting style and allow discrete. These are two key APIs that are going to be coming to the browser soon. So Anchor, can you use Anchor today? No, you can't. But this one is in wide discussion right now. In fact, the reason why it's not in every browser is because I think there is a little bit of a disagreement over how much the API should cover, but it's implemented in Chrome if you want to at least give it a try and get used to it and have JavaScript as the back up for now. Next time you know, when it's out, you can use this thing.

So let's get into some interesting things here with the mobile nav in drawers. So this is a version with the web animations API. This is a slide in navigation. This is being accomplished through the popover API. In fact, if we didn't have any animations on this, this would just work if you wanted to have this pop in. But since I wanted the animations, I threw in the web animations API and made a nice slide in mobile navigation, but once again, you get the keyboard, you get your focus, you get the escape key, all that stuff, and likewise, you can do this with view transitions with the same API.

Look at that. You get the exact same animation with view transitions. The only difference here is that we give it a view transition name. Then we do the transition in CSS. And really, what a lot of this stuff is, is it's offloading things that we do in JavaScript that we're having to ship to CSS that we don't have to ship. And what's cool about this is that we have this keyframe slide, and all we have to say to get this animation working is from translate 100VI. The VI unit here is viewport inline. If you've ever seen VW for viewport width, that's basically the same unit if you're thinking in a logical property way. 100VI in a top to bottom left to right is the same as 100 VW. Because we only have to say from, you just reverse this animation when you have it leave. The view transitions API is really versatile. You can write some really intense CSS animations and transitions with this thing, and you can do this all with only CSS as well using those APIs that we talked earlier. These things are going to make an endless amount of these UIs that you build all the time. You don't have to have a single JavaScript toggle to ever toggle a mobile nav again after we get these APIs.

And likewise, a drawer can be done with the dialogue component, it can also be done with popover, but a drawer, this is kind of like the GitHub one. You can see how much is accomplished with this stuff using just CSS and a tiny bit of JavaScript.

Accordions. Accordions are not that exciting. I'm going to be honest. You have a basic accordion here. This can be done just like this. Details and summary. This works by wrapping a summary tag in details, and then you automatically get this working accordion. Can you use details and summary today? Heck, yes, you can. We're getting into single-digit territory here with Safari supported this since version 6. This thing is extremely widely supported. A lot of people can use this.

I almost pulled it from this talk because I was like, this one is kind of boring, but on my flight here, I pulled up Delta's website, and it's a bunch of divs. Divs and buttons. Why don't they use detail and summary? I felt like people still need to hear this. You can animate this with WAPI as well. I don't know if anybody actually calls it WAPI, but I'm calling it that right now. You get this nice sliding animation. This is probably the easiest way to animate this today without a framework or an additional library bringing this on. If I was animating this thing, I would probably use a library.

This is using web animations API. The reason why this JavaScript is so much here is because we wanted to make it cancelable. Other than that, not too much going on. The HTML, as you can see, is hardly changed, just the details and summary. View transitions are kind of out for this one because you're not going to be able to get that nice slide feel until we get the starting style and allowed to screen properties. So CSS only, now, this should work. It's using allowed to screen and starting style. There's no reason why this shouldn't work. It works one in every ten times.

You might not have seen that because of the FPS, but it worked. Every subsequent time, it's kind of working sometimes. I don't know, this feels like a bug to me because the code is there. But, again, if you're animating this type of thing, this is where you reach for a JavaScript library.

Swipers and slide shows. These are things we build all the time. In fact, Instagram is like the entirety of Instagram is just little swipers, or if you wanted to buy a syntax basketball, you could do some swiping, right? These things work really well, but we often reach for JavaScript for them.

In fact, let me hit, there we go. And now we get a swiper that works and functions very well. Actually, this one feels really good on your phone too. This is using no JavaScript whatsoever to build this swiper. And you will see it functions just kind of like what we're used to. This is being done with the scroll snap API. So, basically, the important CSS here is scroll snap type X mandatory here, and scroll snap align start where we're snapping to the start of each slide. So scroll snap, can we use this today so we don't have to build swipers with JavaScript? Yes, we can absolutely use this today. It's been around quite a while if you aren't using this thing. By now, scroll snap can save you from a ton of things, and not only can it save you from a ton of situations where you wouldn't want to write JavaScript at all, it also makes working with JavaScript in certain ways easier, right? We have indicators as kind of a common thing that you have with these swipers. You just sprinkle in a tiny little bit of JavaScript in here, next thing you know you have these working indicators, but it still functions the same. I still get that nice smooth scrolling and everything like you'd expect. The only difference is I'm running an update function here each time I want to update this. Likewise, you can build the classic style slide show with this thing. This function is the exact same. Not only do we get the buttons and indicators, but we can get the nice easy swipe and it just works. That way, again, it feels nice for your mobile users, and it works really well with the browser, and the amount of JavaScript we're having to write for this is extremely minimal. I'm essentially just calling a slider.scroll and using the behaviour smooth to make this thing, just updating the position on it.

You can check out all the code for these demos. This thing works extremely, extremely well. Cool. So again, I had a lot more of these demos, but I was going to go over by a tremendous amount of time. So if you want to check out all these demos, I have each of them, in fact, most of them, what they do is they run through varying degrees of how much or how little CSS and JavaScript you have to write for each, but there's a ton of demos up here, again, if you want to make sure that you can check those out.

Every single one of these demos you can load up in a browser, Chrome, and only HTML, CSS, and JavaScript, and it will work.

So thank you so much, and that's all I've got today. APPLAUSE.

Scott, things like dialogue did not work well for me on mobile at all. Safari and Chrome are mobile browsers, the 3 per cent. Is the questioner in the room? Because I'm interested to know whether that's Safari and Chrome on iOS they're asking about.

Yeah, you know what? We've shipped dialogue on mobile browsers. We tested pretty extensively and didn't have too many issues. But again, any time you need further back support or different support, you can reach into JavaScript and handle these things if you need to. But for the most part, you know, as long as the browsers your audience are supporting needs to be able to use these features, they're good to go.

Yeah, I've had no problem with shipping dialogue on mobile, I have to say. You did. You did, yeah. We shipped it on syntax in March and haven't had any complaints.

Another question which I can't find in the list, but I'll take it from memory, is can I make sure that things like toast pop-ups appear over a dialogue? Oh, yeah. Well, that's actually a great question, because you have the top layer, but once a thing is in that top layer, my understanding, because I don't work too many over layered over top layers, typically they're temporary things, right? My understanding is that that would be its own context. I actually don't know 100% exactly how to layer them top layer, yeah.

I was thinking about this, diverting, but I was thinking about this, but a dialogue doesn't have to obscure the rest of the page. You can style the backdrop if you want to, but a toast should only be notifying anyway. It shouldn't be something that you interact with, I think. I don't know if I'd want always a toast to appear over, I guess maybe a dialogue. Basically, dialogue should be the only thing that you can interact with on a page, because if they're modal, they're important, I think.

Yeah. There is some discussion on that, about whether they should even consider removing just the show method, or just keep it as show modal, yeah, to make it modally.

A question about popover. Scott, can you invoke a popover from inside an iframe and have it appear on the top layer outside the frame? I have no idea. I have no idea on that one. Once we get into iframes, my whole talk was iframes. I don't know if you noticed that. There was a whole bunch of iframes, and I don't love working in iframes, so I don't know about that.

But popover in general, I found, if you're using it the way it's supposed to be used, is a really smooth experience overall.

Yeah, I can attest to that. Two weeks ago, before I joined Vivaldi, I shipped for a client to hundreds of thousands of users a menu that was based on popover.

Yeah. Works perfectly on mobile as well. You can use it now when you should. Yeah, and there's a polyfill out there, too, that works really well if you want additional support.

Somebody asked, how accessible is the scroll swiper you demoed? Yeah, well, I mean, some of these things are as accessible as you make them. With that one, right, if you wanted keyboard support for that, let's say, you're going to have to add in keyboard support.

The swipe everything happens, it feels nice like that, but let's say if you wanted to hit tab or overkey or something like that, that's when you'd reach for JavaScript the same way that we were doing it. It's your beard. With the buttons, yeah. Yeah. Yeah. Yeah, so that would work really nicely, I think, as long as you did it with JavaScript in that regard.

You want to test these things, make sure you know exactly what you're shipping out.

Wow, another question I'd never thought of. I wonder what the answer is. Scott, will the web animation API respect the user's wish for reduced motion? The API itself, I believe you would have to check first. My understanding is you have to check first.

Man, that's a good one. Because typically even with CSS, you're having to check for that yourself. I believe it's just a way to make sure you can. But yeah, that's a good one.

A lot of accessibility questions, huh? Lots of accessibility questions is good. I think you'd use match media in your JavaScript before you call the API to check the reduced motion property. I think you would have to check manually, though. That's my understanding.

Do you have any intel on why Firefox is missing lots of these APIs? I have no intel whatsoever. But it does kind of seem like that.

It's not like Firefox isn't getting new APIs. It just so happens that they're not getting the ones that I specifically want myself. I think that's it. Yeah, I mean, Firefox is putting in loads of APIs. They've got a different shipping schedule. They've got different priorities, I guess.

Somebody else said, I hope this talk is available later. Great demo. Do you want to remind us of your website where people can get it? Yeah. So my website is T-O-L-I-N.S-K-I. So my last name, Talinsky, is just .ski. Talin.ski. The website is unfinished. I built it this week while making the talk. So enjoy that.

Scott, another question requiring your divinatory powers in browsers peoples. What's your opinion on Chrome just skipping proper web specs to build this? I'm not quite sure what the this is, but... Yeah, that's a good question. So there's two sides of that. It's really just that Chrome is really pushing things forward, but in the same regard, like with the anchor API, there certainly was no quorum on how it should work and function, what it should entail. So with that, if they're not pushing it forward, we wouldn't have it where it is today, but in the same regard, they shipped it pretty early when some people might say it wasn't complete.

I think these things are required to push things forward, but I don't work on any of the browser standards, so my involvement in any of those conversations is nonexistent. I just personally feel like without Chrome pushing it a little bit, who knows if people are going to be actually adding the things that the browser simply needs, right? I also know that the CSS working group is meeting this week in Spain, and Tuesday was devoted to all day to a discussion on the anchoring API, and I think yesterday was making sure that stuff that's moved around the orders changed in Flexbox and Grid, so you can change the tab order so it follows it. Yeah, I think people are trialling these things, but it is being done properly throughout all the groups, don't you think?

Yeah. Yeah, it's definitely being done properly, but it's funny how early it was added to Chrome in regards to the state of the API itself. Granted, I'm stoked that it is, because it's nice to be able to give it a try, you know, and that's kind of like my role here, as I, you know, demo things and get them, get everybody excited about it, but also get the potential out there, right? What can these things do? And again, I would guess you would agree that the more that people in this audience kick the tires of these things and feedback to the working groups, the better they can iron out any problems or solve your use cases.

So imagine you are now king of browsers, if you like, you are the lord of browser land, the head of web standards world. What UI patterns would you like to see browser primitives for next? Yeah, so a lot of my work has been done around animations overall. I got my start in motion graphics, so for me, anything that involves smoother transitions, smooth animations, one of the APIs I think that is being talked a lot about is the view transitions API over multiple pages, because as it is right now, the view transition API that everyone is shipping primarily works JavaScript.

I can wrap my entire Svelte app in a view transition and do some really fancy animations without having to worry about even compatibility, and Astro shipped view transitions and just has it working. So, the multi-page, when you're transferring from essentially one HTML file to another HTML file, that little bit I think is really exciting to me. In addition, the ability to do proper things that we used to do in jQuery really easily in jQuery, a simple slide down, the fact that we can do that now with CSS, those are the things that I want to push forward, the common UI patterns, the stuff that makes it feel more native, smoother, easier, like what people are used to, right?

I think that is kind of a thing even with the reason why web apps always kind of get maybe a bad rep compared to native apps is almost always the smoothness of the animations, or the transitions, or they just don't feel native, and I think those are reasons why. Lots of food for thought there. But we're out of time. So a big JS Nation goodbye and fare thee well to Scott, please.