Slider Pro is a jQuery slider with 17 optional modules

Features live in separate modules, not in one bundle

The modular architecture is the defining idea of Slider Pro. The documentation directory lists seventeen modules that can be enabled independently: Fade, Caption, Full Screen, Lazy Loading, Retina, Conditional Images, Layers, Deep Linking, Autoplay, Touch Swipe, Buttons, Arrows, Keyboard, Thumbnails, Thumbnail Touch Swipe, Thumbnail Arrows and Video. A slider that only needs a fade transition and arrow buttons does not have to ship the code for a video player or a deep linking router. The trade-off is that the feature set is wide but the behaviour is opt-in per module, so a page that expects autoplay or a thumbnail rail has to verify that the corresponding module is present. The README frames the whole thing as a slider for creating elegant, professionally looking sliders, and the presentation page at bqworks.net is where the visual examples live.

The markup contract is fixed and not optional

The HTML structure is prescribed rather than inferred. The README states that the structure of slider-pro, sp-slides and sp-slide, along with the class names used, is required. A slide is a .sp-slide element inside a .sp-slides container inside the root .slider-pro element.

<div class="slider-pro" id="my-slider">
	<div class="sp-slides">
		<!-- Slide 1 -->
		<div class="sp-slide">
			<img class="sp-image" src="path/to/image1.jpg"/>
		</div>
		<!-- Slide 3 -->
		<div class="sp-slide">
			<h3 class="sp-layer">Lorem ipsum dolor sit amet</h3>
			<p class="sp-layer">consectetur adipisicing elit</p>
		</div>
	</div>
</div>

Content type is expressed with classes rather than configuration. The sp-image class marks an image that should behave as a background image, and sp-layer marks a text layer that the Layers module animates. Slides can also hold plain HTML or a video element, and the Modules document covers which content each one supports. For a CMS-driven site where templates come from somewhere else, this contract is the thing to check first, because a template that emits its own wrapper classes will not work without editing the markup.

Installation covers npm, bower and a CDN

The plugin can be installed from a package registry, forked or downloaded from GitHub.

$ npm install slider-pro

$ bower install slider-pro

Bower is still listed as an option, which tells you something about the age of the project and its audience. The files then go into the page: a stylesheet in the head, and the scripts just before the closing body tag.

<link rel="stylesheet" href="dist/css/slider-pro.min.css"/>

<script src="https://code.jquery.com/jquery-3.6.2.min.js"></script>
<script src="dist/js/jquery.sliderPro.min.js"></script>

A CDN route is given as well, pulling the same two files from unpkg.com, so the plugin can be added without a build step at all. The jQuery version in the example is 3.6.2, and the jQuery dependency is not optional: the plugin is a jQuery plugin, and the built file is named jquery.sliderPro.min.js.

Instantiation is a single method with 50+ options behind it

The plugin is initialised on a DOM ready handler.

<script type="text/javascript">
	jQuery( document ).ready(function( $ ) {
		$( '#my-slider' ).sliderPro();
	});
</script>

The README states that Slider Pro has more than 50 options which you can pass when instantiating it, and those are documented in the JavaScript API document, which is split into Properties, Public Methods and Callbacks. The separation into three groups is the useful part of that structure. Properties configure the slider up front, Public Methods let you drive it afterwards, and Callbacks let you react to it, which is how you would wire a slider to an analytics event or a server-driven content swap. Options are passed at construction rather than read from a data attribute, which keeps configuration in one place in the JavaScript.

jQuery is the hard dependency and the reason to look elsewhere

The defining constraint is that the plugin runs on jQuery. That is fine on a site that already has jQuery, and it is a genuine problem on a site that does not, because the dependency then has to be added for a single widget. The project is aware of this: the README notes that the slider is also available as a Vanilla JavaScript version in a separate repository, and as a WordPress plugin. That is the honest alternative to consider, and the difference in approach is concrete. This package keeps the standard jQuery plugin shape with the constructor, the jQuery plugin method and the options object, while the vanilla version is distributed separately. If you are starting a new project with no legacy jQuery, the jQuery package is the wrong distribution of the same product, and picking the vanilla build is a decision about dependency weight rather than about features.

The build pipeline is Grunt with concat, uglify and a watcher

The source lives in src/ and the built output in dist/, and the build is driven by Grunt rather than by a modern bundler. The devDependencies list is short and dated: grunt around 1.5.3, grunt-contrib-concat, grunt-contrib-cssmin, grunt-contrib-jshint, grunt-contrib-uglify and grunt-contrib-watch, with the Gruntfile.js at the repository root. Concat, cssmin and uglify are the standard trio for producing a single distributable JavaScript and CSS file, and jshint is the linter. The watch task is what makes local development workable on the source files. There is also a bower.json, a package-lock.json and a set of example HTML files under examples/, five of them, alongside an examples/css directory. For a plugin that predates widespread ES modules in browser tooling, this is a coherent setup, but it does mean a contributor is working with a toolchain that current JavaScript projects no longer use.

Where a jQuery carousel is the wrong choice

There are projects where Slider Pro is simply the wrong tool, and they are common. If the design calls for a single animated hero element rather than a carousel of slides, the plugin's whole model, with slides, arrows, thumbnails and infinite scrolling, is more than you need, and the markup contract would force structure onto a design that did not ask for it. If the site is being rebuilt without jQuery, adding the dependency to use one widget is a bad trade, and the vanilla build or a framework-based component is the better path. There is also the accessibility question, and here the documentation is telling: the Keyboard and Buttons modules exist, but the README highlights CSS-only navigation controls as a feature precisely because they need no graphics, and it lists the modules without describing focus management or screen reader semantics in the summary. A slider that carries essential content has to be checked for keyboard and assistive technology behaviour by hand.

Editorial conclusion

Slider Pro suits a team that already has jQuery on the page, needs animated layers, a thumbnail rail and lazy loading out of the box, and wants to switch individual behaviours off by loading fewer modules. It is the wrong choice for a new build that has no jQuery, since the plugin cannot be used without it, and the wrong choice for a design that wants a single animated element rather than a carousel, since the markup contract is fixed. Before adopting it, check that the required slider-pro, sp-slides and sp-slide class structure matches your templates, decide which of the 17 modules you actually need, and test the swipe and keyboard behaviour on the touch devices you support. The last push was on 2026-10-10, and the repository has no GitHub releases, so the version in package.json is 1.6.3.

Frequently asked questions

Official sources

1. bqworks/slider-pro on GitHub
2. Issues
3. License: MIT
4. README