The King of Drag and Drop: Alex Reardon

Welcome to Syntax. Today, we have the king. Oh, shit. I just dropped my I just. I'm so emphatic about the king of dragon drop on today. I just knocked over a bottle onto my thing. Luckily, I, keep all of my computers off the desk because I've done that so many times, and I've ruined a few, pushing them on. Anyways, very emphatic, very stoked today to talk to talk to Alex Rudin, who is the author of Pragmatic Drag and Drop. He was from Atlassian.

This episode was a dog to get scheduled because he is from down under in Australia. Welcome, Alex. Thanks so much for coming on. So good to be here, and thank you so much for accommodating the weird time zones. Yeah. Yeah. Absolutely. What what time is it there?

It's 6:0:3

AM at the moment. Man. So you're pretty much pretty tired. Deno of day for us. Super early for you.

It's always always tricky to get scheduled.

Yeah. It is. It's not too bad. I'm usually up about this time with the kids, but it's Wes yeah. Big kudos to my wife who's doing the early shift with them this morning. So Oh, yeah. I know how that is. Yeah. Holy cow. Getting Getting them out of the house, getting ready to go, get to school Yeah. Everything. Everything. Yeah. Yeah. Totally. And, also, hey, talk about amazing partners,

picking up and taking our kids school and all that stuff. Let's talk about Sanity picking up our bugs and helping us solve them. So Sentry Scott I o, the perfect place to help us solve all of our challenging, challenging bugs.

Maybe not quite as challenging as getting kids out the door in the morning, but, definitely, you know, less challenging with Century in your corner. Century can't fix though. Can't fix that. Cannot fix that. Yes. Exactly. That that's one of Century's, like, taglines is Century can't fix this.

And they have, like, billboards, and it just shows, like, hilarious things that they can't fix. And getting your kids buckled in the car is certainly one of them.

Yeah. For real. Oh, man. Alright. Well, Alex, do you mind give us a a quick rundown of, who you are, where you work, what you do?

Yeah. For sure. Before I do, I just wanna say, Scott, that was probably the smoothest segue I've ever seen.

Thank you.

He's really good. I tried my hardest. That was that was that was really impressive. Okay. Yeah. A bit about me.

Yeah. So I work for Atlassian.

So they make, like, Jira, Confluence, Trello, and a few other things. I work on the design system team there, building all the fun shared pieces of UI, but I kinda have a special focus on drag and drop, that problem space. So I'm the author of React Beautiful D Deno D, but that wasn't my 1st outing in that space either. There was some stuff before that, and more recently, a new library called, pragmatic drag and drop, as well. At Atlassian, we you know, drag and drop is pretty core to a lot of our experiences, so I've had the fortunate opportunity to spend a lot of time focusing and thinking about that space.

So I I first came upon Alex by a video he did at a, I think it was like a local meetup, about pragmatic drag and drop. And I watched it, and it was an hour on on drag and drop. And I I'm someone who went down the rabbit hole of, like, trying to build a drag and drop solution from absolute scratch and make it accessible.

And it's it's wild. It's it's so difficult. There's so many little edge cases that I I didn't even cover, and there's so much you have to think about. And I thought, like, man, this guy probably knows more about drag and drop than anybody on on planet Earth.

We must we must protect him. So you you built the React one, and now you've built pragmatic drag and drop, which is a a JavaScript or TypeScript focused solution that works with any framework. Is that right?

Yeah. Yeah. That's right. Yeah. So you can use it with, yeah, React, Svelte, Vue,

just jQuery, Vanilla JS, whatever you want. Nice. Wow. And you had mentioned that you worked on, other drag and drops before React Beautiful DND? Because I I used React Beautiful DND. I've used pragmatic drag and drop. I just wanna see if I've used more of your work.

If you use Atlassian products, you might have. So they weren't, like, yeah, public libraries, but, yeah, I've been thinking about that space internally. And, also, personally, I've sort of feels like it's just a space for whatever reason that keeps drawing me in. I just find it really interesting. Yeah. I get it. It's one of those things that when you implement,

you start to realize that every solution out there, well, just in general implementing for the web is kind of fraught with all kinds of, issues. So that's why I'm so thankful for your work here.

Wes, where do you wanna where do you wanna start?

Yeah. Let maybe, like, tell us a little bit about what makes drag and drop tricky, and then maybe we'll get into the something you mentioned right before we hit record, which is built in drag and drop. Like, the browser has some a p APIs for it, and and there's custom drag and drop. Right? And I'm curious which Node you're using here. What makes it tricky? We'll start with that. I think it's tricky because

I don't wanna throw shade on anything. I think there are some problems on the way that aren't tricky because we have a lot of fantastic primitives in the browser that help us be successful really easily, and we just don't have to think about it. And there are primitives in the browser for drag and drop, but I think they are pretty hard to be successful with. And I'll come back to that. But more generally, I think the problem's hard because it's so such a broad category of interactions.

When people say drag and drop, you can actually be meaning so many different things. We're talking about, you know, moving elements around on the page, which could be any kind of experience from lists, boards, to site builders, to drawing, to just so the list goes on and on on different types of interactions you could be talking about, which can have very high amounts of visual complexity

as well. I'm curious about that, like, the different types of drag and Node. Because if you think about it, there's, like you said, there's simply just dragging a div from one to another, but there also is dragging, like, actual text from a Yarn on the page into somewhere else. But then there also is dragging from window to window, and then there's also dragging from, like, the OS, like, a file into the browser. You know? And then there's there's files dragging out of the browser. And then there's also, like sometimes you're you're dragging a visual element, but that visual element needs to have some some data that comes along with it so that when you drop it,

you need to understand what was actually dropped. And when I built my, like, very simple drag and drop, I was like, man, there's there's a lot to it. JS does this library, like, cover all of those use cases, and are there there use cases that I haven't even covered here? No. You touched on a lot of them, actually. Yeah. So that's really good. So, yeah, specifically on pragmatic drag and drop, yeah, it does handle every all those things, which is pretty cool. Thankfully, the web platform has is very Vercel, has a very powerful built in drag and drop primitives, and everything you just mentioned is possible to do. I think why we don't see a lot of it too widely is that, historically, it's pretty hard to be successful with. The web platform's drag and drop built in drag and drop functionality has I think using it can be pretty tough. Like, that's a subjective call, but that's been my experience.

If there are a a lot of bugs you sort of need to overcome for the various browsers, which is hard, And there's inconsistencies as well, minor inconsistencies between them. So all these sort of things and even just achieving some simple outcomes like, oh, I wanna style the drag preview, which is the thing that you drag around in a certain way or it feels like there's a lot of hoops you have to jump through to do it.

And to be fair with Pragmatic Drag and Drop, like, I spent I I knew the space already pretty well, and I've spent, I think, I've by the end, about 2 years on it to to to have something where people can just run with it.

Yeah. I believe that. You know, I've built, like, sortable lists. I mean, that's even Node thing you didn't even mention, Wes, is, like, sortable lists. Oh, yeah. They're reordering.

That's a giant pain in the ass too, but you have to do it on most projects. And then, again, it's a a can of worms. So yeah.

So so someone who has written several drag and drop libraries, spent 2 years working on this type of thing to get it to a spot where it should work. And that's why I love this JavaScript ecosystem so much. Right? Because you see people simply just double down on Node specific area. Like, we have we have lots of these component libraries out there, and often the component libraries will pull in a project that some like, simply for for Toast messages or for signals or for drag and drop because, like, just that one specific area requires such a large domain expertise.

So I'm curious. Is Pragmatic drag and drop, is that using the platform drag and drop, or did you build your own custom It's using the platform on Horelood.

But that's probably a good point. And to answer your Wes from before, like, what's the distinction between platform and nonplatform Mhmm. Drag and drop? So a lot of solutions out well, solutions basically fall into 2 camps. They're either reinventing drag and drop, so saying, hey. We're gonna kind of ignore what the browser does because we don't think it's that good, and we're going to build up this interaction using, you know, pointer events, and you're basically starting from scratch to create an experience that we think feels better. And if you go down that path, you can create some really nice feeling experiences.

One of the challenges, though, of going down that path is that you have to teach the browser how to do this new thing from scratch, which means, inevitably, you're gonna be sending a decent amount of code. It's always hard to support every single feature that Mhmm. You would think could be available on the web platform, and there are just some features that are not possible for you to create because, you know, you're limited by the tools you have available to you the alternative tools you have available to you on the platform. So, for example, with the native drag and drop, you can drag previews outside of your web browser, outside of the tab into another tab. You can't do that if you're not using the native saying. Drag and drop because you're sort of stuck inside the the tab.

That's why I found so interesting about this is that, like, drag and drop goes beyond the the body or the HTML tag. Right? Because it's it sort of is bridging to native. And there's also, like, security considerations that you need to think of there as well. I think you can tell me this if this is true or Node. But at one point, when I was doing it, like, you could drag a file from like, if you have a web browser and then you have your file list and then you have, like, an app in between.

And sometimes you, like, you drag and drop, and you go over another app, and that app will light up. You're about to drop on me. What security things are in place so that do you have to actually drop the file before that application can read it? Because, otherwise, if you accidentally just drag something over top of a random map, that could be a security issue. Right? Yeah. So the platform has built in

security stuff around that. Getting into the weeds now, but the native drag does have the ability to attach data to it, and you can only attach data to it at certain times and read it out at certain times.

And yeah. So once a drag has started, that data store that can be shared across, you know, tabs or applications, you can only read from it. You so you can read what types of things are being dragged. So you can say, hey. A file is being dragged or text is being dragged, but you can't see its content until they drop. Yep. So that's one of the, yeah, security features that's built in. Yeah. I've I've Scott a talk elsewhere. I won't go into it too much, but I think that might be a little bit too restrictive because there are some experiences where you do wanna know what's being dragged around. And I think if you were, say, on the same origin, you know, I think they could loosen that restriction a little bit so that you could see what's in there, like, because you're on the same origin, it's something you can trust. Then you could if you're on the same origin, you communicate through other channels anyway, like through yeah. Like, even just local storage or whatever it is.

So I think, yeah, you probably anyway, we're Node going to that weeds, but Oh, yeah. At the moment, it does have built in security, to answer your question. Yeah. Just but and it is, yeah, it's there. Node. I was gonna say JS far as, like, platform drag and drop goes, you know, it it isn't something you can just use kind of out of the box and have a a great experience, really.

So, like, what kind of additional things do you have to strap onto the platform drag and drop to get it to feel like something that people are used to with a native app or something?

Great question. I will pull up the code on my machine because there's a Scott there. Right? So we have the idea that, firstly, doing any problem well on the web, you need to be thinking about performance and how to get that. So even if you build something that's technically correct, you can mess up performance.

So that's a that's a big challenge too JS how do we create something that is gonna be fast and fast for everyone. So that kind of is not drag and drop specific, but that's something that's been a long time on as well. And the big idea for pragmatic drag and drop is that it's sort of a very small core, and you just add the pieces on that you want. And that way, you're only ever paying for the pieces that you want. That seems to be a really nice model. And then if one of those pieces doesn't work for you, you can just swap it out with your own piece and then but you can still kinda stay in the broader ecosystem. And then there's other performance things, like how do we manage events? You know, making sure we're not finding too many events and cleaning up events properly and, you know, all that fun stuff. Oh, yeah. Yeah. And I take it you have to get into, like, the whole the item you that you're dragging. Is that end up being controlled by the platform? Because every time I've used the HTML one, it gives you that little ghost image. Is are you working with the platforms,

the item that you're dragging, or is that something you're having to, like, recreate and emulate on your side?

Drag previews is one of the best features of the web platform, like, the in how they do it, but it is so hard to be successful with. And I'm pretty sure I invented techniques or, you know, independently invented techniques to actually get it to work because it's really tough. So there's a few different ways you can do it. Firstly, if you want to, you can just hide the native drag preview completely.

That's not easy to do. You actually have to set a tiny transparent GIF as the drag preview that. Which is pretty annoying. And then, yeah, there's no, like, 1st class API for that, and then you can just make any element you want a drag preview. But you have to move it around with, like, a transform, probably in a portal, but then it's limited to the browser window. You can do that with pragmatic drag and drop. We have a guide on how to do that, but I generally recommend folks don't do it because the performance isn't great. You're then tying the rendering of the drag preview to the page. So if your page is slow for whatever reason, you know, you'll feel it'll stutter, and it's just yeah. Not ideal. So, yeah, we're coming to the native drag preview. So this is the I think one of the coolest features of the web platform. So what it does is Wes you start, you can say like, hey.

Take a photo of any element on the page and use that as the drag preview, which sounds great, but the way it's set up is actually, like, pretty gnarly.

So it has to be an existing element on the page, which is usually not what you want. Well, let's say you're okay for the preview to look like what the element already is, then you're okay. And I've created a little technique where you you can change its appearance a little bit without having to do too much work. So I just run through that super quick, and then I'll get on to the more interesting one. So, effectively, you have to do this weird trick where you in the drag start event, you change its appearance somehow.

At the end of the drag start event, the browser takes a photo of that element to be used as the drag preview. So when you're dragging around, it drags around photo. Then the next frame, you revert that change or, you know, change it into some other resting state. And that way, you can get the drag preview to look how you want. It won't flash on the screen as some awkward color because the screen hasn't painted yet. You've sort of reverted it. You're sort of leveraging the fact that there's a it takes a photo before the front before the next frame. Oh, man. We so we had a question about the event stack the other day on one of the podcasts, and that's a very good explanation of things happening before paint. So sorry. Go ahead, but that's that's Yeah. So the yeah. Browsers will independently, like, render that in a separate, I don't know, layer UI thing outside of the browser, and it's not it's not tied to the paint. So you can, you can undo it straight away. But that that's really we've made that really easy with the pragmatic drag and drop API. You have events for that. But more interestingly is the there's another thing I've created, which is there is more complexity here than I'm gonna say, but I'll give you the the high level. Basically, same idea. When the drag start event is happening, we mount an element on the topmost layer in the browser. Like, put it basically in the top left corner of the screen, except for Safari. I'll come back to that. But you put in the top left screen, and you render whatever element you want in there to be your drag preview. It can be any kind of shape, any anything you want. You say, hey, browser. Take a photo of this. You'll take a photo of it, and then you remove it, you know, before the next paint. So you don't get that awkward flash of it being on the screen, but you get to have whatever you want. But what's the point of all this? Why why are we doing this? It's so that you can have the drag preview look different to what the element is at rest, which is usually I find pretty common. People wanna do that. They want it to have be, like, blue, or they want it to have some different information on it or even a box shadow.

Yeah. The web the web platform does put a box shadow on drag previews, and it lowers the opacity to about 0.94 Mhmm. Which sounds good, but it's actually kind of annoying because you don't actually want that all the time. And this you just can't opt out of it. So it would be great to have a little bit more control there. But yeah. So it it does that. But you can up the box shadow if you want, and you can up the opacity. But Yeah. It does up those. Yeah. The the opacity thing is one of my most common ones because I I feel like a lot of even native experiences

doesn't necessarily make it totally transparent or like, some oftentimes, it feels like you're just picking something up and moving it rather than having it be like a a shell of what what you're moving or something. I don't know. It's just a a vibe for me. Yeah. I think that it wouldn't be too I've got a,

a talk floating out there where I talk about how we could, you know, evolve the web platform safely, and I think it wouldn't be too difficult to add the or for browsers to add the ability to give us a little bit control over what the styling is of that element. But, yeah, today, yeah, that's the way it is. You can probably tell there's a few hoops you had to jump through to do something that should be pretty straightforward.

There's some more hoops, which JS, like, if you wanna push the drag preview away from the cursor, you actually, after lots of exploring, ended up stealing a strategy that I found in in Spotify, which is they actually use a transparent border around the preview to push it away. If you use margin padding, anything else doesn't work. Wes. So then there's a few other kind of tricks like that. And it's just it's just not easy. Like, it's just not easy to set you'd think it's setting a custom drag preview would be a straightforward thing.

Unfortunately, it's like you have to know these very specific timing points and how they work to be successful there. Is the drag and drop

spec ongoing? Like, is there is there any rumblings of improving it or addressing it? Or is that just like a it's done and it's not being reevaluated

at at the time? I don't have any special insight into that other than to say I've been looking at at it for a while, and there hasn't been much movement.

I have done a talk in the past where I talk about how we could improve the web platform, but I have yet to make the next step of that, which is to to actually create proposals.

Yeah. But, my sense is it's Scott, actively worked on space. Alright. So I have a question about, like, the headless aspect of this because we've talked in the past about how headless components work and how they're really neat. How do you build something that is entirely based on the elements being on the page and having classes added to them and and dragging and hovering over top and dropping and drop areas, how do you build this entirely visual thing headless?

Yeah. It's so good. We can talk about how we did it for React Beautiful Damnedo as well if you're interested because it's a little bit different. But Yeah. Yeah. Focus on pragmatic first. I mean, at the end of the day, what it's doing is you you pass it an element to say like, hey. I want this to be a draggable thing. I want this to be a drop target, which means I can be dropped on. And they have lots of different events and ways to attach data and extract data. And all of those sort of entities also, you can listen for events. Hey. Drag started.

I'm dragging. I'm being dragged into. I'm being left. And, really, then it's up to you what you do with those things. So that's kinda how we sidestep it JS pragmatic drag and drop doesn't render or anything. You can almost think of it as this is what the platform could have been for drag and drop. So it's it's inverts all the control. So it just says, this is the event. You can do what you want with it.

And then we also have so many, like, optional little pieces to help you achieve certain outcomes. So, for example, with the that setting the native drag preview, like, that's an optional utility you can pull in. And so in your on generate drag preview event, you can call that function, provide the arguments you want, and it'll just do the thing that it does. Wes. That's how it's headless. It's, it just sort of operates at the element level. It attaches behavior to elements JS sort of how it works.

I love that approach. And does that make making it a not a React plug in, but a it works with Svelte and Vue and React and and everything? Does that JS that make that a lot easier to write these adapters, or how does it work with all the frameworks?

Yeah. If you're working at the element level, it's basically the bottom. Right? So as long as your framework, you get can get access to elements that are related to your I UI, then you then you're good to go. That's all you need. Were there any frameworks that were harder to implement? Are there adapters? Is that is that what the situation is for the different fragments? I'm Sanity we're used to it headless. Yeah. So it does actually doesn't have any adapters at the moment. We use it really heavily with React and at Atlassian, and we haven't written any adapters because it just it didn't didn't feel like it actually added all that much, but you definitely can. Like, it's like a couple of lines of code to wrap it in a hook. Yeah. But how we usually set it up is or encourage people to set it up is just put it in an effect. That's you just set it up in there, and you pass it the ref, like, for the element, and you're kinda good to go. So I'm just I'm just thinking that's amazing. Like, you don't even need it. And, like, this is my hope for the future of, like, web components and and things like that that do need DOM nodes JS, you know, there is no adapter. It just it just works. Yeah. So as long as you can get the element, you're fine. I mean, if you want if you're really kind of a React I don't know what the right word is. You want everything to look like a React API, it's, like, trivial to wrap it in a hook, and then you kind of little hook. Yeah. You you're kinda done. Yeah. It doesn't add that much. I mean, you end up sort of just duplicating the API across 2 things anyway. So, yeah, we haven't felt the need to it. And putting in an effect has some nice benefits as Wes. Like, we basically can delay because an effect doesn't have to happen, you know, straight away.

I mean, technically, the hook could use an effect too, but it is nice to be able to delay this binding of of these events. Like, we don't have to do it as part of the render, so that's kinda nice. In fact, we've designed pragmatic drag and drop so you can bind it at any ESLint. Like, you can and you can lazy load it as well. So some of our experiences, like, inside the effect will or will load in pragmatic at a later point, basically. You don't have to have it straight away, which is a nice kinda little not that it's very big at all, but anything you can do to help improve

page performance is nice. Yeah. I'm curious about the difference in between mobile and desktop.

So at at all points, is it really just a matter of listening for presses or clicks or anything like that? Like, is there any special sauce you have to get to have it feel the same on mobile as well as desktop?

Specifically, we're using the web platform stuff. Thankfully, it's actually very well supported now on mobile. That wasn't always the case. That was sort of one of the the things that encouraged me to create pragmatic drag and drop in the 1st place was can't remember what year it Wes. I'll say maybe 3 years ago, Wes started supporting, for reals sorry, the web platform drag and drop API, which is a it was, it's pretty old. Yeah. It's been around for a long time, but it took a long time for them to support it. So, yeah, the browser support's actually quite good. So there's not too much you have to do. There is some, you know, little quirks, little bugs, little inconsistencies, but for the most, it you can just use the web platform the same.

Wow. Sick.

And are you using pointer events then? Is that Wes you when you say the web platform, is the pointer events how it works with touches and clicks?

Naming things is really hard. I really don't like calling it HTML 5, like, drag and drop, but a lot of people call it that. So I try and call it, like, web platform or platform drag and drop. So it's basically, like, the drag and drop that browsers have built in.

Okay.

And so when you're doing that, you're listening to events like drag start, drag over, drag new drop. You don't even have type of drag events. That said, I'll come back to it, but, the so a nonweb platform drag and drop or, like, custom drag and drop is where you're listening for, like, pointer down and then Yeah. Pointer move. And in response to that, you're saying, okay. The user's starting a drag. I'm going to, like, create my own element as a drag preview and move it around. And then when they do pointer up, I'm gonna say the drags over and so but you, yeah, you're just sort of teaching

teaching the browser how to do this interaction in a different way. Sorry. Whenever we have 3 people on here, we there's so much latency that Wes and I are always, like, either Yeah. Not to talk over each other. I I told them. I'm I'm like, it we're going through the Earth right now. Like Yeah. The there's a pipe going through the Earth to Australia, and I'm on STARLINK, and we have 3 people on. So Yeah. That we got the latency. No problem there.

I'm interested about, like, in general, lessons learned about performance in general because it's one of those things that, like you mentioned, if it's attached to your your DOM rendering, it can suffer from whatever JS happening in your application.

Is the platform is the HTML drag and drop, like, the key to having really good drag performance, or is there any any special sauce or any things that you learned? Yeah. There's definitely some special sauce.

Yeah.

So, I mean, well, let's let's compare the the one I have the most accurate picture on is, like, the difference between, say, React Beautiful DND and Pragmatic drag and drop. So React Beautiful DND is a solution that sort of ignores the web platform's drag and drop functionality and recreates it from scratch. Well, firstly, it had a some really cool performance stuff in there as well to make it work at scale, which is pretty crazy. It had its own virtual kind of DOM. It had windowing built in. It had lots of things to try and make it as fast as possible.

But, ultimately, it was shipping a lot of code, so teaching the web browser how to do drag and drop is not trivial, especially if you want it to work well with lots of different things. So that's the first point. It often involves shipping more Node. So that's performance.

It's tied to the React rendering.

So it's putting more, like, React Beautiful. It puts more components in your tree. It does more initiation work when the render is happening.

So it's just part of that render for React, which if we compare that to Pragmatic Drag and Drop, it basically steps out of React and does it has its own, like, way of managing kinda state, its own way of initializing its own, like, all that stuff. So it doesn't have to go through the it's not on the critical path for your renders, which is really Node. So you don't have to yeah, ask React to do more work. Like, React's a great distraction. I I really like using it. But if we you can step out of it to do certain certain things, like certain high performance things, it's kind of you can get some really nice benefits doing that.

Yeah. Totally. I think we talk about that all the time, you know, in terms of even picking libraries that you're using, you know, relying on the ones that utilize the platform so you're not the one in charge of or even the library or its dependencies aren't the ones in charge of so much of that stuff that that could end up,

biting you later on. React Beautiful D and D got bigger and bigger over time. But in some ways, like, its bundle size wasn't its goal when when I started that. It was how can we create something that feels fantastic on the web and then it's also accessible out of the Bos? And I think it kind of achieved that to a degree. And so but it just got bigger and bigger. So something that I was really keen on giving having another time around is how can I break it up in such a way so that people only ever pay for the functionality they use, which means that everybody, hopefully, is only paying the minimum for what they actually need? And that seems to be just such a nice model. And the site and another benefit, like so that's a really great benefit. Like, you get really great performance outcomes because you don't have to ship little rogue piece of functionality that's needed for one specific type of experience to everybody. Right? They can pay for that, for their thing, and then no one else has to pay for that. And, also, like, it means that there's no pressure. There's less pressure on the library to get bigger to accommodate everyone Mhmm. If that thing can be built as a a stand alone piece that doesn't have to be, like, in the core or in these other like, if it's genuinely a separate enough concern, it can be its own utility, whether that's in one of our utilities or one of theirs.

So there's less pressure on things to get bigger as well. And, just, even to clarify for the audience, when you say pay for it, you're talking about, like, bundle cost and those type of things, not, like, monetary cost. Right? Yeah. Yeah. Yeah. Deno. Yeah. The free free library. Just to let everybody know. I I had a question about accessibility because you had mentioned a little bit there. How do you even make drag and drop accessible? Is that that seems like a a difficult, problem to solve because that feels like such a inherently

touch focused thing. Right? Yeah. So this is I'm really glad you brought this up because my views on this have evolved, and I'm open to them evolving, you know, more in the future as well. So we'll go back to, like, React Beautiful DND. So something that I was really keen for with that library was how can we make this interaction that's historically excluded people who can't use pointers pointer of it to be able to achieve the same outcomes? What I did for that library was every piece of functionality for the most there were maybe a few things that we didn't quite get there, but you could achieve the same outcomes with your keyboard exclusively and listening to the screen reader and sort of follow what was going on, which is probably one of the things I'm most proud of with that library because I think that that had a ripple effect if you look across a lot of the libraries who came after that. You know, accessibility became a really big thing that people wanted to care about when it came to drag and drop.

So when we say what what do when we talk about accessibility, what are we talking about? It's allowing people to achieve basically the same thing as if they had that were able to see the screen and use their mouse, but if they can't do those things, they can still achieve the same outcome. Otherwise, we're sort of locking people out of being able to do things like in our software applications.

So that's what React Beautiful DND did. Now there is an asterisk there in that React Beautiful DND only actually covers a subset of the drag and drop problem space.

It was designed for lists and lists of lists. And within that sort of subset of the drag and drop domain, it was able to get away with that approach and be reasonably successful with it. That approach of being able to do everything specific, like ESLint with spacebar, arrow key around, spacebar drop, or whatever key combination you kind of think is better.

Yeah. And that is tough to scale across every single possible experience that there is. There's just yeah. Because there's there's, like, infinite, almost different types of things you can build. And so how do you get something to work? And I think if you look at React area, they've done a pretty good job at figuring trying to figure that out as well. That that's in a more flexible system.

Now for pragmatic drag and drop, I've actually gone well, we've we've gone a different direction. Oh, I say I, we. I mean, it's definitely a team thing.

Yeah. I'm I'm not just doing this making all these decisions on my own. We have a lot of amazing folks who work in accessibility, at Atlassian. And so instead of trying to get people with assistive technologies to perform drag and drop operations, like press a button to lift, tab or arrow key to move around, space to drop, it's like, instead of trying to have parity of interaction, what we've gone for is parity of outcome. If you think of, like, what does a drag and drop operation achieve? Like, let's think of a a list and you're reordering it. You're reprioritizing something Wes you're moving something down in the list, whatever that is. You could achieve that in a few different ways. Like, it doesn't have to be drag and drop to achieve that outcome. And so that's sort of the the core change, I guess, is how can we allow people with assistive technologies to achieve the same outcome in a way that's delightful for them? Don't even think about drag and drop at all. Like, what's the outcomes here? What's possible to do via drag and drop, and what would be a great way for them I'd say them. Like, people who have different, you know, mixed abilities, whatever that may be, how can they achieve this? So what there's a few different patterns to do that. We're not locked into 1 pattern, which is really nice. So with pragmatic drag and drop, we Scott of separated out the accessibility kind of controls and various things versus the core, like, and drop stuff so you can iterate on the accessibility pieces. And, also, that's nice because a lot of our accessibility pieces are sort of tied to the Atlassian design system, like using our button or our drop down menu. And you might not wanna use that, and you might wanna use your own. So separating those out is a convenient way to not lock the library into just being used for the last in design system. Going back, let's think about a list. One way that you or a board, one thing you could do is and this is a pattern we have a lot as well Wes, like, action menus. Action menus are so powerful. But, like, let's say on that draggable entity, you have a little dot Scott, like, more menu on it. They tab to it. They can open it. And in there, you've got, like, your movement actions, like move down, move up, move to in progress, move to whatever. And it's just like a few keyboard things away, and you're kinda done. Tab to move down, press enter, done. And that pattern scales really nicely too because it doesn't have to just be a flat list of things. You could pop a form. In that more menu, you could have, like, a move action. You click that, opens a form, and it you can have, like, very you can basically say, like, hey. I want this to move. We have one that's for trees, so you can say, like, hey. I want to move to this parent in this tree in this position. Like, you can It'll filter it. Can just have a form with any information you want in it. Yeah. And

yeah. Is any of that code part of Pragmatic drag and drop, or is that just your application code for, for example, moving it from 1 1 column to another? Is any of that code pragmatic drag and drop? What is and what JS in pragmatic drag and drop gets a bit fuzzy because we have so many optional packages.

That's the kind of the thing. So and we try to be as Wes try to invert control as much as possible as well. So there will there will inevitably be some wiring. Because, also, like, we don't know what actions you want. We don't know what they do. Like, you kinda need to decide on that for your own application.

So what is pragmatic drag and drop? Like, we've got sort of the pieces you need to be able to create those experiences, for people. We won't wire them up for you. You kind of need to decide, okay. I'm gonna use these pieces, but we have guides and examples on how to do it. It's not like you have to figure it out. Yeah. We've Scott, like yeah. You gotta think about this concern, and this is what you do. And this is the next concern, and these are the things you do. And then this concern is the things you do. And we did it in that way too because even that I mentioned, like, the action menu. That pattern doesn't actually, like, generically work for everything as well. So even within that model, we've kind of got room for, okay. Well, if this pattern doesn't work, we'll do this other pattern. Like, the driving principle is not figure out how to use an action menu. It's what's the best thing for people who are using assistive technologies to be successful with this experience.

I love that, outlook on it because oftentimes when we're talking about this accessibility stuff, it's like, alright. What do we do to give the users a working experience? Not like rethinking the user's experience for, their challenges or disabilities. Replicating it. Totally yeah. Yeah. We're always replicating the experience, like you said, like picking it up and moving it instead of, like, really taking a an outlook as to, like, what would a a a good experience be like that is completely just separated from the way that, you know, able people are able to use it. That's, I love that outlook. You think about, like, deleting a file on macOS,

and, like, yeah, you can drag it into the trash, but the, like, accessible or, like, other way to delete a file in Mac OS X is not like a keyboard shortcut to to click on a thing and drag the icon down. Right. Although that does exist. Yeah. That does exist in Wes, but nobody's doing that. People are just hitting command backspace to delete it, or they're using context menu to delete it, or they're using delete file. Right? There's there's so many different ways to to run the action. And I love that because, like, I had implemented the accessibility of my ESLint, and, like, it was I think the code to make it accessible was, like, 3 times the size of just the simple drag and drop. And because he had to announce when things are are up and down and changing and you have to he has to be polite and all these things. You know? I love that idea of just like no. Don't don't think about how you can replicate the actual visual movement of it. In some cases, that's helpful because it's it's visual. But at the end of the day, what are you what are you trying to do with this? That's that's really nice. Yeah. It's it is a really nice pattern, and it scales

super well. But I guess there is as with all things, there's a drawback to the approach that I mentioned, and that is there is a risk that someone will come along and just see the drag and drop stuff and go, I'll take that. Oh, here's all the accessibility stuff. Oh, that looks kinda hard. I'm not gonna worry about that. Mhmm. So that was a strength of React Beautiful D and D Wes it's like, nah. They're together. Like, you can't opt out of this. I guess a danger in providing lower level pieces is that people just can choose not to use it. Yeah. That that mean that is a a concern. It's not so much a concern where I work at. Like, this we we care a lot about accessibility, and we have a lot of tools that check for it and all that kind of stuff. But, yeah, that is a danger. So I think a way around that, potentially, is Wes don't do it right now, but right now, we have, like, very low level building blocks. But if you move into, like, higher levels of abstraction, then you can bake in those controls.

Mhmm. But it is hard for a library to move into those higher levels of of abstraction, without becoming too opinionated about what the experiences

should be. Okay. So would you see, like, a Shoelace or ShadCN or something like that putting out a 3 or 4 common drag and drop UIs that that you can use in your application that are already accessible. Is is that kind of the idea, or or maybe even you guys would ship a couple common use cases that are a little bit more built up?

Yeah. Yeah. For sure. If you're building any part of thing of UI, you're starting to add opinion opinions on, like, what styling library should I use, what rendering library am I using, know? And there's splitting. There's, like, n combinations of those things. Yeah. So, yeah, something like like, like, the tools you mentioned, they would be great candidates to, like, add those opinions on those visual opinions on.

What about testing this type of stuff? How do you possibly even test something where you have to click and drag it? Yeah. So

that's great. That's great. They're asking such good questions. It's like this is you know, you're professional. It's so good.

The testing, I can speak to, I guess, what we do at the library level and then what what would be helpful for applications.

Mhmm. I think when it comes to drag and drop, your best bang for buck is to do browser ESLint. Right? Because there's just so many little parts of a drag and drop operation that a unit test level that you have to think about. It just gets pretty overwhelming.

And so I would say, start with browser testing. Pragmatic drag and drop has guides on how to write tests drag and drop tests for the various, like, Cypress puppeteer, playwright, etcetera, and how you can how you can do that. So that's that's pretty great because you're you're not so much testing the little things. You're testing like, hey. If someone drags a card from this column to that column, like, it should do the thing. And in your application test, you don't really need to test that pragmatic drag and drop or the drag and drop library is doing what it should. You're more probably just testing the outcome of that. You've make sure you've wired it up sort of correctly.

And you may even test things like, hey. When I drag over this thing, the appearance changes. Blah blah blah. You could add you could probably even add visual sort of testing on that, visual regression testing for the various points in the in your drag if you wanted to as well or asserting certain things about the DOM. And we have those for pragmatic drag and drop as well. We have a lot of browser tests to check that things are working, and we test those in I think our test suite is currently running against Chrome,

Firefox, and Safari. Are you using Playwright for that?

That's a good I I think it is Playwright.

We've just gone through some, like, some quick iterations on things. But yeah. But it's also complicated because, at last, we actually have some teams using, like, Cypress, for example.

But I think our ones are, yeah, play right. Then we've got the unit testing. So Pragmatic Drag and Drop does a ton of unit testing as well. Really? But that's actually pretty nebulous. But we're testing, like, very low low things that they're that they're working.

But it requires like, it's using JS DOM, and we've had to polyfill a few things that because poll like, JS DOM like, most of the, like, DOM shims don't implement drag events, so we created a drag event polyfill.

Yeah. That's one of the big things. But, yeah, it's possible to unit test just like any other code. But Mhmm. In general, I won't go too into it, but it's all sort of well, all tested through public API as well, which is cool. But there is a decent amount of mocking JS you can imagine, like, because you have to mock out. Like, an element has these dimensions, and it's doing this stuff. And Yeah. It's kind of annoying. I don't like doing that, but, Yeah. Anyway, that that exists. But, yeah, pretty much all I think all the tests actually are through public API. So they've they've that that's pretty nice. They kind of withstand the internal kind of changes too, which is great, with one exception, actually. So I'm paranoid about events, event listeners, and making sure that they're added when I expect them to be and removed and and cleaned up correctly.

And so those tests can break, you know, if I add an extra event. So we Node an extra event. Like, sun suddenly, I'm getting more than I expected, so that can break. But other than that, yeah, it's pretty much all public API. What is the process of having, like, people internally to the company

adopt this? You know? Like, is is this running on Trello yet, and do you get a lot of really good internal feedback?

Yes. I mentioned I worked on pragmatic drag and drop for 2 years. So for 3 to 6 months, I was basically building what we see today, maybe even maybe 3 months. And then the rest of that has been building out what's needed in partnership as we go through kind of adoption with people. So we're now sitting at around 80% adoption in Atlassian, when compared to yeah. So we measure, like, hey. Are we using React Beautiful DND or other drag and drop solutions? And we're now seeing 8%. Then that's a lot of that's a lot of code that's been kind of shifted over, which is great. So, yeah, Trello's using it. So if you use boards today or pretty much any drag and drop in Trello, that's pragmatic drag and drop. Jira, Confluence,

Yeah. You kinda name it. They're they're pretty much using it. I know you're you you work on things that a lot of people use all the time, but, like, dragging and dropping is kind of Trello's whole project. Like, I mean, that's, like, the whole thing. I mean, besides, obviously, like, the function. So, like, how does that feel to have worked on something that's like Yes. You know? Supplying the main feature for one of the biggest products that is at your company. Is that amazing or what? If I saw somebody dragging and dropping something, like, in line or on the bus

and you knew that it was your code running? Like, have you ever stopped somebody and been like, I wrote the code.

Drop that item.

Yeah. It's it is surreal. I mean, before I go into this real enough, like, huge props to the people who work on browser vendors. Like, ultimately, we're just sort of unlocking their functionality. So a lot of folks have worked on making drag and drop work in browsers, so huge, huge, you know, massive respect to them. But coming back to your question, it is awesome. You know? It's it was one of the it's one of the greatest feelings to yeah. Especially something like Trello Wes drag and drop is so core to for them to trust me and what we're doing as well with basically, like, the thing that their app is known for is is huge. So I've had the privilege of working with all the Trello folks. They're just amazing amazing engineers, amazing people. To work with them is great. They actually helped So we have an auto scroller for pragmatic drag and drop. We were building it out for like, Trello was the main oh, sorry, the first people who really wanted it. So an auto scroller is the idea that when you get close to the edge of a scrollable element or to the window, it will automatically scroll for you. Okay. I have that on my Yeah. So questions to ask. That's good. Yeah. So Trello had this really interesting functionality where it actually keeps scrolling once you've left the element even though it's kind of not how the web platform wants you to work. And yeah. So I work Scott of collaborated with them to build that out.

Yeah. So that was amazing. But, yeah, to answer your question, it's it's it's really, really cool. Like, it's just a great feeling. Sometimes we build stuff, and we it doesn't go anywhere, and it's like, you know, I put a lot of time into that. I I worked for for 2 years on, about, I don't know, like, 50 components for the Ford Motor Company, and they used, like,

they used, like, half of 1 of them, and none of them ever went live. And I was just like, come on.

I can't even point to a single thing that, you know, this is what I did. Yeah. So, yeah, it's a great it's it is a great feeling. What I find is even in it's it's really, really nice when Atlassian products, like, use it, and it's been adopted really heavily, which is awesome.

I find for some it's kind of also a massive buzz when people outside the company, like, use it because they're like you know, they they could choose anything. So, yeah, that's pretty sweet too. It's it's cool that Atlassian, like, open sources this and everything. You know? And and, also, like, I I don't know who your boss is, but, like, allowing you to is do do you are you full time just on drag and drop for for 2 years? And, like and how do you also get that job?

You know? Yeah. I Wes. Yeah. If you could find out how how to get that job, you gotta can you let me know? That'd be great.

I I don't think that was how it was planned. So, originally, I kind of you know, I, obviously, am not that great at estimating, but I sort of thought, oh, yeah. Couple months, we'll be done, and we'll move on to Node next thing.

But, what we found is that so yeah. I guess there was no firm that has to be finished by this date, which is nice. It would have been different conversations if we'd known it was gonna be that long.

That said, it was sort of one of those things where we just kept unlocking massive chunks of value, and that kind of just kept propelling it forward. The value proposition kept being really strong. The performance improvement. So we were getting conversions. We're getting about, on general, about 1 to 300 millisecond improvements to time to interactive JS well as other paint improvements because we're taking things off the off main thread. We're getting server side rendering performance improvements because we're asking React to do a heap less work as part of that, server side render pass. Performance really carried it a long way, but, also, we scratched a huge itch internally. Like, we didn't really have a strong story for drag and drop, so we had React Beautiful Node, which was great for listen boards, but outside of that, there wasn't really anything there. So people were using, like, React DND and, like, other solutions, and we had, you know we just stockpiling all these different drag and drop solutions, which was hurting performance, right, because we just kept piling on more solutions. So I guess we were just scratching an itch internally. Like, people kept building, like, things with it. There was a gap there. We knew some of that gap, but we didn't realize how big that gap was. And, also, we will really let raising the bar on accessibility. So we had evolving and strong stories for, like, how to do accessibility, And so we had solutions that weren't using React Beautiful DND Node over to pragmatic drag and drop and also now become accessible as well, which was

really, really cool. Yeah. Because it seems like a lot of the org I mean, there's there's a lot of products and apps, but, like, I mean, you have Atlassian JS a whole has so many great system wide components and stuff like that. It does feel like there'd be such a huge benefit for the entire company for everyone to get on these types of things like like you said, being able to share in accessibility wins and stuff like that. That feels like probably a massive a massive job. It JS I'm wondering about, like, versioning and stuff like that. Do people at Atlassian,

they're always staying up to date with the latest versions of your own internal component systems? That that feels like a a big job. Right? That's in an evolving story too. So we we we've sort of have a design system that publishes end to Npm, and then they pull that in. How delayed that JS, historically, depends on the product. Some of them are basically up to date all the time, and some of them could be, you know, 6 months behind. But in the last sort of year, that's changed a lot. So we're we're sort of consolidating our front ends into a monorepo, so it's it's effectively instant now for most things. So it's just like, yeah, we ship stuff in in which brings its own challenges as well, but good challenge is good because it means that we're Scott. The challenge of just, like, shipping the Npm and waiting is, like, you're often, like, deferring the upgrade pain or, like, shunting the upgrade pain to someone pnpm, whereas now it's like, yeah, we just all kinda move together, which is a much better way of doing things, I think.

Yeah. That's great.

I was reminded before about the solution consolidation. Like, we had all these different drag and drop libraries. That was also a big performance thing that I forgot to mention before is, you know, being able to replace, you know, 5 different drag and drop libraries with 1 small one. You know, that's a huge, like, bundle bundle size win as well. Yeah. So something I was keen to do was was to try and make something that you could do anything with. Right? So we didn't you didn't have a need to, like, reach for something else.

Oh, yeah. Yeah. Like, even one of the examples is just like a drawing application, which I didn't even think of.

Like, that would be a a use case for this, but, like, it'd be kinda cool to build that with, like, stickers. Like, I remember Vercel had Vercel's, like, Vercel day, and they had, like, little stickers you could drag onto your badge and then take a photo of it. And I was like, that that would be a use case for

using this library. Right? Yeah. I mean, pretty much anything where you point to press the pointer and move it around and do something, you can Yeah. You can do it with with it. It can be sometimes not the best choice,

but you can definitely do everything with it, which is pretty cool. Cool. Should we get into the the last section here, Scott? Yeah. Let's do it. Alright. I'll I'll let you do it. Sure. So this is the part of the show where we do sick picks and shameless plugs. A sick pick is just anything that you're enjoying in life right now. Anything that that's cool could be a show, podcast, a product, whatever. And then a shameless plug is anything you just wanna share with the audience.

Do you have a a shameless plug for us today, Alex? Yeah. Shameless plug.

I'll start with, a few years ago, I released a website called domevents.dev.

It's just sort of ticking along, but if you're interested in learning a bit more about how events work in the browser, I'd check that out. That was, like, a real I'm gonna say watershed or, like, important moment for me to get a firm grip on how events work. It's so fundamental to so many things.

And I thought I understood events when I created this that page and the associated course, but I realized how much I did not know after going down that path. So and that has served me really well because so many gnarly problems in front end are, like, people doing weird things with the fence or not understanding how how events are working or various things like that. So, yeah, that's a shameless plug. And then, sick pick is coffee. I know. Such a such a such a such a great one. So I've been a long time drinker pnpm enjoyer of coffee, but this year, for whatever reason, I've had a a micro obsession about coffee, and I've gone down, you know, the YouTube rabbit Node, and and I've really enjoyed it. And my encouragement to others is if you're enjoying to get coffee today and maybe you make it at home, you're probably only a few YouTube videos away from really improving the quality of your coffee. I did not realize, like, you it's basically night and day how I make them today and how they taste today. Like, yeah, and you can kinda every little thing it's it really surprised me, but almost every little thing that you start to improve, it you can actually taste the difference, and it's very rewarding adventure. And now when I'm at because I work from home, it's also really kind of meditative.

I butchered that word, but to go out there and have this little process on how I make it, and you kinda get rewarded for having a good process as well. So, yeah, it's been very satisfying, journey.

Yeah. That's amazing. JS there any anything you'd recommend on YouTube or anything like that for, people who wanted to get into this? Any specific favorite channels or anything?

Yeah. I mean, a very popular and great one is James Hoffman. He's got some great videos on I think if you go just type in James Hoffman, you'll see it. We'll we'll link it in the show Node. He's got some how to know coffee fundamentals, and that's incredible.

They're very popular videos, and is is very well produced as well, but are also very educational. That was a huge, like, learning for me. And there's other there's lots of other creators as well, but that's a great place, I think, to start. I got some Australian coffee a couple of years ago from Jed Watson. Do you know him? He's he's you're in Sydney. Right? He's in Sydney? He

sent me a call. Jed Watson and I, we go way back. Yeah. He's he's Oh, yeah. A a great human being. I like him a lot. Yeah. I like him a lot as well. And he sent me some coffee. It was very good. I it was hilarious. He sent it at Christmas, and it arrived in, like, May because mailing things to and from Australia is a very hard thing to do.

But cool. Well, thank you so much for coming on. I really appreciate you, schooling us on all things drag and drop. It's fascinating to hear all the the ins and outs of it. And that's honestly why I love this podcast so much. It's just, like, Node tiny little aspect of the web, which is just clicking on something and moving it, is honestly such a deep well of information. And an expert, like, you can dive into it for a good chunk of your life. So thank you so much.

Yeah. Thanks so much for having me on. Really appreciate it. You're welcome. Yeah. It's been a blast. Thanks, Alex.