Discofork
Repository brief

SortableJS/Sortable

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis
cached 2026-03-31T09:47:47.588Z
1mo ago

SortableJS/Sortable

SortableJS/Sortable is a mature JavaScript library for reorderable drag-and-drop lists in modern browsers and touch devices, with no jQuery or framework required. It is actively maintained, widely used, and has a large ecosystem of framework integrations and plugins. Forks are most likely interesting if you need drag-and-drop sorting, plugin-based extensions, or framework-specific adaptation work.

GitHub
Loading tags...
Stars31,053
Forks3,744
Default branchmaster
Last pushed2026-03-24T22:02:22Z
Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

10 of 10 fork briefs
Selected

Choose this fork only if Composer distribution is the main requirement. If you need current SortableJS behavior, active maintenance, or the latest bug fixes, upstream is the better default.

Choose this fork only if its extra event metadata solves a concrete integration need. For most users, upstream SortableJS is the better default because this fork is small, old, and substantially behind current maintenance.

Choose this fork only if the one-axis fallback drag behavior is the requirement. For most users, upstream is the better default because this fork is stale and substantially behind.

Prefer this fork only if lock-axis behavior is a hard requirement. Otherwise upstream SortableJS is the safer choice because this fork is old and significantly behind current maintenance.

Prefer this fork only if you need its specific legacy drag-and-scroll patches and can tolerate being hundreds of commits behind upstream. For most adopters, upstream SortableJS is the better default because it is far more current and likely safer to maintain.

Choose this fork only if you need its legacy event behavior. For any new or actively maintained project, upstream is the better default because this fork is severely outdated and adds only a tiny compatibility-oriented change.

Choose this fork only if async-define compatibility is the problem you are solving. Otherwise, upstream is the better default because this fork is small, stale, and materially behind on fixes.

Prefer this fork only if the added MultiDrag and DOM-revert behavior are essential and you can accept stale upstream lag; otherwise upstream is the safer default.

Prefer upstream unless you specifically need this older frozen state; this fork adds no visible features and is far behind on maintenance.

Prefer upstream unless you specifically need this frozen legacy snapshot. This fork offers no clear added capability and appears materially behind on fixes and maintenance, so it is mainly useful for existing deployments that cannot move.