Dragology lets you build drag-and-drop by declaring where things can go
Declarative Dragging
Designing custom drag interactions usually means writing fiddly code for geometry, feedback, and animation, so many builders skip it. Declarative dragging flips this: you specify which future states of your app a dragged element should reach, and the engine speculatively renders those states, extracts positions, and synthesizes a smooth interaction. Implemented in the Dragology library for SVG on the web, it supports composable modifiers like floating and snapping, and shines in interfaces with parallel representations.
I eventually came up with a primitive version of what would become model-driven dragging, but implementing it seemed daunting, so it sat on my whiteboard for the next two years, haunting me every time I went to make a sandwich.
- gavinray
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...
- btown
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.
- nostrebored
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
- codedokode
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.
- sourdecor
I think this is a really cool project, but I also really appreciate the introduction to Hazel[0].
[0]: https://hazel.org/