react-slick alternatives: migrate by what you built with it

react-slick ports the jQuery-era slick carousel to React. It still works, but the architecture predates hooks, releases are sparse, and it drags a separate CSS file into every build. The right replacement depends less on features than on which of two camps your usage falls into.

react-slickEmblaSwiperreact-horizontal-scrolling-menu
What it isReact port of jQuery slickHeadless carousel engineFull slider frameworkScrolling menu, native scroll
MaintenanceSparseActiveActiveActive since 2018
Bundle (min+gzip)≈15 kB + slick CSS≈8 kB≈40 kB≈5.7 kB
Extra CSS file requiredYes (two)NoYes (core)One, or Tailwind via shadcn item
Slide semantics (snap, dots, fade)YesYesYesNo — deliberately
Rows of clickable itemsBent via centerModeHand-built on the engineConfigured against the grainThe core use case

Sizes are approximate cores. The last column is this site’s own library — the table says so rather than pretending otherwise.

Camp one: it was a real carousel

Hero sliders, image galleries, testimonial rotators — anything where slick's dots, fade and autoplay carried the design. Migrate to a real carousel engine:

Map slidesToShow/slidesToScroll to Embla's slidesInView/slidesToScroll or Swiper's slidesPerView/slidesPerGroup, and expect to delete your arrow-positioning CSS overrides — both successors let you render your own buttons.

Camp two: it was navigation wearing centerMode

The other slick install is the quiet one: a row of categories, logos, dates or filters, bent into a carousel with centerMode, focusOnSelect and variableWidth because slick was already in the bundle. The tell is what you fought: clicks firing after drags, arrows at the wrong times, items you couldn't measure, snap you didn't want.

That row was a menu. react-horizontal-scrolling-menu does the three things centerMode was faking — center the clicked item, scroll natively with drag support, and report which items are visible — in ≈5.7 kB with no slider engine. See the scrollable tabs and category rail pages for the two most common shapes.

Whichever camp: the migration is smaller than it looks

slick’s API surface is large, but audits of real configs shrink fast: most projects use a handful of props. List the ones you actually set, decide which camp each usage is in, and migrate per-instance — the two camps often coexist in one codebase, and there is no rule both must land on the same library.