dnd-kit vs Pragmatic drag and drop vs react-beautiful-dnd for Next.js in 2026

Quick answer (September 2026). These three are not three choices at the same stage of life, and treating them as a like for like shortlist is the mistake. Measured live on 16 September 2026: react-beautiful-dnd is retired, its GitHub repository is archived and every one of its 69 stable npm releases carries a deprecation notice. dnd-kit is actively developed but split in two, because the package almost everyone installs has not shipped since December 2024 while the real work happens in a separate, still pre-1.0 package family. Pragmatic drag and drop is the only one of the three shipping on a normal cadence, and it is not a React library at all. Pick Pragmatic drag and drop for new work if you can absorb a lower level API, stay on dnd-kit v6 if you want the largest ecosystem and can live with a frozen version, and treat react-beautiful-dnd as a migration source rather than a choice.

Why the usual comparison is wrong before it starts

Almost every comparison of React drag and drop libraries lines the candidates up as equals and scores them on API ergonomics, bundle size and accessibility. That framing quietly assumes all three are live options you could reasonably start a project on this week. Two of them are not, and the reasons are different in each case.

So this piece starts somewhere else. Before any API comparison, it asks a question you can answer from published registry and repository state in about ten minutes: what stage of life is each of these actually in, and does the thing you would install match the thing that is being worked on? The answer turned out to be more interesting than the API differences.

Everything below was read on 16 September 2026 from the npm registry, the published package tarballs and the GitHub API. Where a number could have come from a secondary article, it did not.

The three lifecycle states, measured

react-beautiful-dnd is retired, and it says so in three places at once

react-beautiful-dnd is Atlassian's original library, Apache-2.0, copyright 2019 Atlassian Pty Ltd according to the LICENSE file inside the published tarball.

Three independent signals agree that it is finished:

• Its GitHub repository is archived. The GitHub API returns archived: true, with 642 open issues frozen in place and the last push on 18 August 2025.
• Its newest stable npm release, 13.1.1, was published on 30 August 2022. That is four years ago.
• All 69 of its stable npm versions carry a deprecation notice, reading "react-beautiful-dnd is now deprecated" and pointing at issue 2672 in the repository for context and options.

That last one is worth dwelling on, because it is unusually thorough. Plenty of unmaintained packages simply go quiet. This one was explicitly and retroactively marked across its entire release history, which means your package manager will tell you, on install, without you having to go looking.

The honest reading is milder than "do not use it", though. Archived is not the same as broken, and this is still the most starred of the three at 33,928 stars. If you have it in production and it works, an archived repository does not reach into your app and break it.

The concrete blocker is narrower and much easier to check: its declared peer dependency range is react ^16.8.5 || ^17.0.0 || ^18.0.0. React 19 is not in that list. On a current Next.js app you will be installing it against a React version its maintainers never declared support for. That is a specific, testable problem rather than a vague worry about abandonment, and it is the thing to check first. It also carries redux and react-redux as runtime dependencies, which is a surprising amount of state machinery to pull in for list reordering in 2026.

dnd-kit is not abandoned, but it is split down the middle

This is the finding that changed the shape of this article, and it is the one most likely to catch you out.

If you look only at what you would install, dnd-kit looks like it is dying. @dnd-kit/core is at 6.3.1, published 5 December 2024. That is 21 months of silence on the package that 18.5 million weekly downloads point at. Every instinct built from day to day dependency triage says abandoned.

It is not. The repository was pushed to on 12 September 2026, four days before this was written, and it is not archived. The work moved to an entirely new package family:

All of it MIT, copyright 2021 Claudéric Demers, read from the LICENSE file in each tarball.

So the project is healthy. But notice what this actually asks of you, because it is not the same as a clean rename. @dnd-kit/core is not deprecated. Zero of its versions carry a notice. Your package manager will say nothing at all. And the successor is 0.5.0, still pre-1.0 after 21 months of development, with the version number itself declining to promise API stability.

That leaves a genuine fork in the road rather than a migration path. Start a new Next.js project on dnd-kit today and you choose between a battle tested v6 that has not moved in nearly two years, and a rewrite whose own maintainer has not yet called it 1.0. Both are defensible. Neither is obvious. And crucially, nothing in the tooling will surface that choice for you.

Pragmatic drag and drop is shipping, and it is not a React library

@atlaskit/pragmatic-drag-and-drop is Atlassian's replacement for its own retired library. Apache-2.0, copyright 2022 Atlassian Pty Ltd from the tarball. Version 3.1.0, published 29 August 2026, repository pushed to on 15 September 2026, the day before this was written.

The single most important structural fact about it is one line of its package.json:

"peerDependencies": {}

It has no peer dependencies at all. No React, no react-dom. To check whether that was a packaging oversight rather than a real design choice, I searched every JavaScript file it ships for React imports. Across 282 JavaScript files, the word "react" appears three times in total, and all three are the same code comment in the same module across its three build outputs:

"Some frameworks (eg react) don't render into the container until the next microtask."

That is the only mention of React in the entire package. Not an import, a comment about working around one. It is genuinely framework agnostic, and the comparison is not really React library against React library at all.

The fair counterpoint, which the bare fact obscures: this does not mean you write React bindings yourself. Atlassian ships the React ergonomics as separate optional packages, and they are moving faster than the core:

• @atlaskit/pragmatic-drag-and-drop-react-drop-indicator 4.2.1, published 15 September 2026
• @atlaskit/pragmatic-drag-and-drop-hitbox 2.2.2, published 16 September 2026, the day this was written
• @atlaskit/pragmatic-drag-and-drop-auto-scroll 3.2.0, published 29 August 2026

So "no React dependency" is an architectural decision with an opt in React layer on top, not a gap. It does mean you assemble more pieces. The core ships 434 files built as many tiny entry points, most of them between 300 and 1000 bytes, which is the same philosophy expressed in the file layout: take only what you use.

One trade off worth knowing before you adopt it: the core declares "sideEffects": true, so bundlers will not tree shake it as aggressively as the other two, both of which declare false. Given the entry point architecture that is a reasonable design, but it is the opposite of what the file sizes might lead you to assume.

The Next.js half nobody writes down

Here is the part that matters if you are on the App Router, and it is the same result I found when I compared the Next.js rich text editors a few days ago, which is what makes it worth recording.

I searched the published tarballs of all four relevant packages for a use client directive. The result:

Zero, in all four. The control column is there because a zero is only worth reporting if the same search could have found something: the identical pass looking for export statements returned 226, 4, 8 and 276 files respectively, so the search was working and the absence is real.

What this means in practice is simple and consistent across all three libraries: none of them declares its own client boundary, so you own it. Every one of these requires a component of yours carrying use client, and none will do it for you or warn you if you forget. There is no server rendering entry point anywhere in this category, which is unsurprising for libraries built entirely on pointer events, but it is worth confirming rather than assuming.

One smaller difference does show up in packaging. Only @dnd-kit/react ships a modern exports map, with four entries covering the root, ./hooks, ./sortable and ./utilities. react-beautiful-dnd, @dnd-kit/core and the Pragmatic core all ship none, relying on main and module. react-beautiful-dnd additionally declares no types field at all. For a 2026 TypeScript codebase that is a small but real ergonomic gap, and it is the clearest signal that the 0.x dnd-kit line is the modern one.

What the download numbers say that the star counts do not

This is where the picture becomes genuinely surprising. Weekly npm downloads for the week of 5 to 11 September 2026:

Two things fall out of that table, and both cut against the tidy narrative.

Neither official succession has actually landed. Atlassian retired react-beautiful-dnd and published Pragmatic drag and drop as its replacement. More than two years on, the deprecated, archived library is still pulling more weekly installs than its own official replacement, 1.51 million against 1.02 million. Meanwhile dnd-kit's own rewrite has roughly five percent of the volume of the version it is meant to replace, 0.94 million against 18.5 million.

Stars are measuring the past. The archived library has nearly twice the stars of the most actively maintained one. A star is a bookmark from whenever someone found the project, and it does not decay when the project does. If you are using star counts to judge whether a library is alive, this category is a clean demonstration that they cannot do that job. Downloads are better, and the archive flag and the publish date are better still.

How I would actually choose

Starting something new and you can take on a lower level API: Pragmatic drag and drop. It is the only one of the three on a normal release cadence, the adapters are shipping weekly, and the framework agnostic core means it is not exposed to a React major version bump. Budget real time for assembling the pieces, and expect more code than a batteries included library.

You want the biggest ecosystem and the most examples: @dnd-kit/core v6. Eighteen million weekly downloads means every problem you hit has been hit before, and the frozen version number is less alarming than it looks for a mature library whose scope is basically complete. Go in knowing you are pinning to something that has not moved since December 2024.

You are tempted by @dnd-kit/react 0.5: only if you are comfortable tracking a pre-1.0 package. It is the modern architecture and the packaging is clearly better, but 0.5.0 after 21 months is the maintainer telling you something about stability, and you should believe them.

You are on react-beautiful-dnd today: you are not on fire, but start planning. The trigger to act is not the archive flag, it is your React upgrade. The moment you move to React 19 you are outside its declared peer range, and that is the point at which this stops being technical debt and becomes a blocker.

What I did not measure

Stating the limits, because they bound everything above. I read published registry metadata, package tarballs and repository state. I did not build three applications and benchmark them. Nothing here is a measurement of runtime performance, dragging smoothness, accessibility behaviour with a screen reader, or touch device handling, and those are exactly the axes on which a drag and drop library is ultimately judged.

The byte counts I quote are unpacked tarball sizes across all shipped build formats, not minified and gzipped bundle sizes for a real application. They are useful for seeing that react-beautiful-dnd ships 1.39 MB across 239 files while @dnd-kit/react ships 240 KB across 23, and they are not a substitute for measuring your own build.

What the published state does settle, and settle cleanly, is the lifecycle question. That question is answerable today, it is the one that decides whether the API comparison is even worth running, and it is the one most comparisons skip.