kenwheeler/slick: a jQuery carousel that still ships, and what v2.0 changes

What problem slick-carousel solves, and who ends up using it

Slick answers a narrow question: how do I turn a flat list of child elements into a responsive, swipeable, keyboard-navigable carousel without writing the slide math myself. The README describes it as "the last carousel you'll ever need", and the option table backs up the ambition. A single call on a container produces arrows, dots, autoplay, touch dragging, infinite looping and breakpoint-specific settings. The plugin also covers cases people usually hand-roll: asNavFor syncs two sliders so one acts as navigation for the other, rows plus slidesPerRow turns the carousel into a grid, and centerMode shows partial neighbours on either side. The audience is therefore teams already committed to jQuery. The package.json declares jquery as a peer dependency with the range ">=1.8.0", so Slick is not a standalone widget. If your page has no jQuery, adopting Slick means adding it. For a content site, a marketing page or an older application that already ships jQuery, that cost is zero and the plugin removes a few hundred lines of custom code. For a modern bundle where jQuery was deliberately dropped, the dependency is the whole decision.

How the plugin actually drives the DOM

The entry point is slick/slick.js, declared as "main" in package.json. You give it a container whose direct children are the slides, and it builds the carousel around them. The README's data attribute example shows the expected markup: a div carrying data-slick with a JSON object, containing plain child divs. The README states that the data attribute alone is not enough and that you still need to call $(element).slick() to initialize. From there, options decide everything. Arrows and dots are separate DOM nodes; appendArrows and appendDots take a selector, an HTML string, an array, an element or a jQuery object, so navigation can live outside the slider. nextArrow and prevArrow accept markup or nodes, which is how you replace the default buttons. Transitions are CSS-driven by default through useCSS and useTransform, with speed and cssEase controlling timing and easing as an animate() fallback. Responsive behaviour comes from the responsive array of breakpoint objects, and respondTo decides whether those breakpoints measure the window, the slider itself, or the smaller of the two. Setting a breakpoint's settings to "unslick" removes the carousel below that width. That last detail is the design signature of the plugin: the carousel is a state the element can enter and leave, not a permanent wrapper you fight with at small sizes.

Installing slick-carousel and getting a first slider on screen

The README gives two routes. For package managers it lists Bower and npm. The npm package name is slick-carousel, which is also the "name" field in package.json, so the install command is:

npm install slick-carousel

For a page with no build step, the README points at cdnjs and jsDelivr. The jsDelivr example differs by jQuery version, and this is the part people get wrong. For jQuery 4.0 or higher the README uses the master path for both stylesheets and the script. For jQuery 3.0 or lower it pins @1.8.1. The two stylesheets are separate: slick.css is required and slick-theme.css adds the default styling.

<link rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/gh/kenwheeler/[email protected]/slick/slick.css"/>
<link rel="stylesheet" type="text/css" href="https://cdn.jsdelivr.net/gh/kenwheeler/[email protected]/slick/slick-theme.css"/>
<script type="text/javascript" src="https://cdn.jsdelivr.net/gh/kenwheeler/[email protected]/slick/slick.min.js"></script>

With the script loaded, mark up the slides and initialize. The README's data attribute example uses slidesToShow and slidesToScroll, both 4. Four slides should appear at once, advancing four at a time, with arrows and dots off because those defaults are false.

<div data-slick='{"slidesToShow": 4, "slidesToScroll": 4}'>
  <div><h3>1</h3></div>
  <div><h3>2</h3></div>
  <div><h3>3</h3></div>
  <div><h3>4</h3></div>
  <div><h3>5</h3></div>
  <div><h3>6</h3></div>
</div>

Then call the plugin on that element. The README is explicit that the data attribute does not self-initialize. Passing options directly to the call works the same way, and the two can be combined, with the call taking precedence in the usual jQuery plugin pattern.

Where slick-carousel gets in your way

The first constraint is the peer dependency. Slick is a jQuery plugin, and version 2.0 exists because of jQuery 4 compatibility. That tells you the maintenance work is tracking jQuery, not removing it. If your roadmap is a jQuery-free front end, Slick is the wrong tool and no configuration changes that. The second constraint is documentation depth. The README is a settings table with one worked example, the responsive option. It documents what each option does, not what happens when options interact. Combining centerMode with an even slidesToShow is one the README does warn about indirectly: centerMode's description says to use it with odd numbered slidesToShow counts. Others, such as fade with vertical, or variableWidth with centerMode, are not covered in the text available here. The third constraint is the upgrade path. Releases jump from 1.8.0 in 2017 to v2.0.0 and v2.0.1 in 2026, and the README's own CDN instructions still hand jQuery 3.0 or lower users the 1.8.1 assets rather than a 2.x build. Nothing in the README describes what changed between 1.8 and 2.0 beyond jQuery 4 compatibility, so a migration has to be reasoned about from the release notes and the diff, not from a guide. Finally, accessibility is opt-in in two steps: the accessibility option is on by default, but the README states that full compliance needs focusOnChange enabled as well.

Slick against Swiper and the CSS scroll-snap approach

The obvious alternative is Swiper, which is a standalone library with no jQuery peer dependency and its own module structure. The difference in approach is architectural, not cosmetic. Slick is a plugin: you supply a container of children, call a method on a jQuery object, and the plugin manages state through that object. Swiper is a library you instantiate, which is why it can be bundled and tree-shaken and why it does not care whether jQuery exists on the page. If your constraint is bundle composition, that difference decides the choice before any feature comparison. The second alternative is not a library at all. CSS scroll-snap plus a small amount of JavaScript gives horizontal paging with native momentum scrolling, no plugin state and no dependency. It handles the common case of a swipeable row of cards well. What it does not give you is the option table: no asNavFor, no responsive breakpoint objects that restructure the carousel, no grid mode via rows and slidesPerRow, no built-in arrow and dot generation. Slick's value is that those behaviours are configuration rather than code. If you need two of them, the plugin earns its dependency. If you need none, scroll-snap is less machinery.

Version 2.0, the MIT licence and what upkeep looks like

The repository is not archived and the last push was on 2026-09-14, days before this writing, with v2.0.0 on 2026-07-24 and v2.0.1 on 2026-07-30. The gap between 1.8.0 in 2017 and 2.0.0 in 2026 is the number that matters for planning. A team that adopted Slick in 2018 spent roughly eight years with no major release, and the upgrade to 2.0 arrives with no migration document in the README. Budget for reading the diff rather than following a guide. On licensing, package.json declares "license": "MIT", and the repository carries a LICENSE file at the top level. MIT is permissive: it allows commercial use and modification with the copyright notice retained. That is a statement about what the licence text says, not legal advice, and the obligations you actually carry depend on how you redistribute the code. For most teams vendoring slick.min.js into a build, the practical question is whether the licence header survives minification, which is a build-configuration check rather than a legal one. The peer dependency range ">=1.8.0" also matters for upkeep: it is open-ended, so a future jQuery major could land outside what the plugin handles, and the 2.0 release is evidence that jQuery majors do force plugin releases.

Editorial conclusion

Adopt Slick if you already load jQuery and want a carousel whose behaviour is configured rather than coded, with responsive breakpoints, synced sliders and grid mode handled by the plugin. Do not adopt it if you are building a jQuery-free front end, since the package declares jquery as a peer dependency, or if you need documented guidance for moving from 1.8 to 2.0, because the README does not provide one. Before committing, verify which jQuery version your page actually loads and pick the matching asset path: the README gives @master for jQuery 4.0 or higher and @1.8.1 for jQuery 3.0 or lower. Then check the responsive option against your own breakpoints, because the README's table stops mid-sentence at that entry in the copy available here.

Frequently asked questions

Official sources

1. Issues
2. kenwheeler/slick on GitHub
3. License: MIT
4. README
5. Releases