Funny story about drag-and-drop:

At my very first job, we had a weekly meeting to assign tickets and estimates.

Our non-technical PM wrote "drag-and-drop" on a whiteboard, and then my name.

"Gavin, how long do you think this will take?"

"All week. At least. Maybe longer?"

PM laughed, then realized I wasn't making a joke.

"What do you mean 'all week'? That's ridiculous, do I need to give this to someone else?"

"Well, you could, but I wouldn't count on you getting it any sooner."

Appalled, he exclaims: "It's just drag-and-drop!"

After 10-15 minutes of a room full of engineers trying to explain the difficulty, he gave up with an unhappy "Fine."

The phrase "it's just drag-and-drop" became an inside joke for the rest of my time there...

Oh, this is very, very cool, and very, very timely!

Paper here: https://declarative-dragging.github.io/D2.pdf

IMO one of the remaining gaps of agentic coding is that it's hard for even multimodal LLMs to check interactive motion effects for correctness and "feel." Like, sure, they can take screenshots of a few snapshotted states, but in terms of how things react as underlying nodes move and (potentially) reflow. How do you QA the feel of moving your wrist rapidly in the context of nested zones?

The answer is that you avoid the need to: you have a (nearly-provably) correct foundation that ensures that behavior is predictable regardless of state, and just render accordingly.

The paper's approach is incredible here: simultaneous optimistic rendering of multiple possible states, and a composable algebra (a small combinator language) over how drop zones and distance are derived - allowing for an extremely high-level interface in practice. Everything feels snappy and right, and the code you write is about as minimal as you can get - though the paper notes that state management is somewhat complex. But this seems solvable!

Once this is ported to HTML, it'll become an incredible part of the modern dev toolkit. I'm very excited for what this means.

Imagine an agentic coding system with a good memory implementation. It's prompted to build an app with sophisticated drag-and-drop features. And then another one... After twenty such apps it realises there must be better way and comes up with declarative dragging.

It's pretty clear to me how far current models are from this being real. I'd say it's a good example of how AGI it not upon us, despite what the big labs are claiming.

Even the remarkable mathematical achievements are in some ways brute-forcing in a limited space. The space of "how could we build this better" is in an entirely different category of scale.

I think this is a really cool project, but I also really appreciate the introduction to Hazel[0].

[0]: https://hazel.org/

The Twisted Trees example is really cool. I would not have been able to implement it that well. After playing with it, I think at the most basic the underlying principle is:

> Write your interface as a function of continuous variables, ui = ui(x1,x2,...) = ui(X). When dragging an element, compute the barycentric coordinates λ₁,λ₂,λ₃ of the cursor between the three nearest dropzones. Then render by interpolating the ui parameters between their values at those three dropzones, ui(λ₁X₁ + λ₂X₂ + λ₃X₃).

Appreciable, but what is the novelty exactly? The API design? I see the paper doesn't call out Sketchpad or any of Ivan Sutherland's work anywhere in the paper, neither ThingLab or Juno(-2). They do call out Apparatus, which already introduced speculative rendering. The work also doesn't seem to generate valid transforms, which you have to supply yourself. Discovering valid transforms or solving a more general inverse rendering problem would have been much cooler research.

Interesting idea, but look too complicated for me. What if there are 1000 places where an element can be dropped? What if we select and drag several elements at a time?

Also this approach seems to introduce new complicated concepts like "composables" and even a DSL. Probably writing custom code for Drag-and-drop would be easier that figuring out how this works. I read the page and did not understand much. For example, this phrase is difficult to understand: "Rather than programming all that visual behavior directly, you simply say, for each element you want to make draggable, which future states of your application dragging it should lead to.". Not "simply" at all. Writing new code would be easier especially with LLM.

Does this also work when the search space becomes large?

I fear this might lead to an exponential blowup.

(The examples shown are all tiny)

an author here (andrew). down to answer questions though it might be a bit until i get to them

Nice work! Good to see that someone is still working on making the Human Computer interface that has been around for while and used extensively in many applications more human. Thank you.

This API feels as significant to me as Reactive Extensions did when Netflix first debuted it. Thank you for this research! I have a lot to think about!

Very neat, looking forward to playing around with this. We are sorely in need of of more exploration into UX/UI, HCI of the current era of digital tools.

Is there any hope this could be turned into a vanilla js library and not attached to a particular SPA framework?

Anyone have an idea of what stack/technique would be used to accomplish a task that this is widely superior for. The work seems cool but I'm having trouble imagining what is it replacing.

Edit: nvm, answered by the Background section of the paper

We will continue to reinvent dataflow and planning problems until the end of time; you will be surprised how many fundamental pieces of software use this paradigm

Speculative rendering sounds awfully expensive.

This is so cool!

all links and buttons in document header are also draggable demonstrations of the concept. very cool

Fantastic work! The interactive demos are incredibly satisfying to play with, visually delightful, and genuinely educational.

This is revolutionary! I wonder if there's any similar prior art.

The Hazel programming env is dope. I can already imagine using it to explain refactorings to new programmers.

The twisted tree diagrams is also really neat. Is that a new idea as well? I got the beginnings of an idea where it might be a good diagram to display tangled code paths.

Wow that is an elegant way to do it. This could create a renaissance of drag n drop interactions for the web

It is nice to read a coding article.

Very nice work

related. https://news.ycombinator.com/item?id=49858513

Good work

Drag-and-drop is a user interface feature. More often we need drag tools for DAG (Directed Acyclic Graph), which is an execution architecture. Most work involves dependencies: something must happen before something else can happen. I didn't see DAG here.