vue-flux, a Vue 3 slider with 20 transitions, and what the component split costs you

A Vue 3 slider that ships its own transition set

vue-flux is an image slider built with Vue 3, and its defining feature is that the transitions come with it. The documentation lists 20 of them, split into 2D and 3D groups. The 2D set covers Fade, Kenburn, Swipe, Slide, Waterfall, Zip, Blinds 2D, two Blocks variants, Concentric, Warp and Camera. The 3D set covers Cube, Book, Fall, Wave, Blinds 3D, two Round variants and Explode.

The point of that list is that none of these require you to write a transition. A fade and a book page turn are very different amounts of work, and the difference in effort between them is exactly the cost the library absorbs. The README also says transitions are expandable, that you can add your own very easily, and that contributors are welcome to send transitions for inclusion, which means the set is meant to grow.

The project is written in TypeScript, published under the MIT licence, and the current package version is 7.1.3. It declares a peer dependency on vue at ^3.5.0 and an engines field of node ^20.19.0 || >=22.12.0, so the runtime expectations are specific and modern.

The audience is a Vue 3 application that needs a hero slider or gallery with motion, and the developer who would rather not build one. What it is not is a general purpose carousel for dense content, and the documentation pages are organised by major version, with separate overviews for versions 5, 6 and 7, which tells you the API has changed across those lines.

Three entry points: the core, the complements and the transitions

The packaging is the most instructive thing in the manifest. The exports map in package.json defines three public paths rather than one. The root export resolves to the built ES module and CommonJS builds with type declarations. The ./complements export carries its own type, import and require entries pointing at a complements bundle. The ./transitions export does the same for a transitions bundle, and there is a separate ./style.css export that resolves to the stylesheet.

The consequence for a user is that the tree is assembled by hand, and the quick start shows the whole shape in one file. The component itself, VueFlux, and the Img resource class come from the root import. The complements come from vue-flux/complements and include FluxPreloader, FluxCaption, FluxControls, FluxPagination and FluxIndex. The transitions come from vue-flux/transitions, with Book and Zip shown in the example.

The quick start is explicit that this import list carries every complement, and that you can remove the ones you do not want. That is the design philosophy in one sentence: a minimal core plus optional pieces you opt into by importing them.

Resources are first class rather than an afterthought. Images are created with new Img('URL1', 'img 1'), a constructor that takes a url and a caption, and collected in an array that is passed to the slider as rscs. The options object is separate, and the example sets autoplay to true. Both the options and the resources are held in shallowReactive wrappers rather than ref, which is a deliberate choice: the slider mutates and reads these structures during transitions, and shallow reactivity avoids deep tracking of arrays of objects that only need to be observed at the top level.

The quick start as a working template, and how the controls are wired

The installation is one command:

npm install --save vue-flux@latest

After that, the documentation walks through a complete single file component. The script block imports from vue, from vue-flux, from vue-flux/complements and from vue-flux/transitions, plus the stylesheet, then declares the options, the resources and the transitions, and finally renders the slider in the template with one slot per complement.

The template shape matters as much as the imports. VueFlux takes the options, the resources and the transitions as props, and each complement is provided through a named slot that receives its own props object, which is then spread onto the component with v-bind. The pattern repeats for the preloader, the caption, the controls, the pagination and the index, and the same props are handed to the child so each complement can render the state it needs.

The component is also given a template ref, and the example drives it from a button outside the slider:

   <button @click="$vueFlux.show('next')">NEXT</button>

So the slider is controlled imperatively through a ref, and the show method takes a direction such as next. Keyboard navigation with the arrow keys and a full screen switch are listed among the documented features, and gestures are called out as mobile friendly. The parallax component is a separate export, FluxParallax, and the documentation shows it taking a single resource and a height, with your own content nested inside.

What you should see after wiring this up is a slider that autoplays through three images, with a caption, working controls, and a button that advances it.

The transitions are CSS driven, and the weight figure is about 60 KB

The performance note in the documentation is short and specific: the weight is about 60 KB, described as light given it carries only the essential CSS, and the animations are performed with CSS3 hardware acceleration, so it does not require a high end computer.

The hardware acceleration claim is a design statement about the implementation rather than a measurement. It says the transitions are composed from CSS transforms and opacity changes that the compositor can handle, rather than being driven per frame by JavaScript state updates. That is the same reason the transitions are listed as a catalogue of visual effects rather than as data: a 3D transition such as Cube or Explode is a set of CSS rules applied to layers, not a render loop written by you.

The trade-off is that CSS driven motion is also where the accessibility questions live. The documentation lists gestures, keyboard navigation and full screen as features, and the transition set includes fades and zooms, so the library is not animation blind. What the documentation does not describe is any reduced motion behaviour, any way to switch transitions off for users who ask for less animation, or any focus management for the controls. If your site has a motion sensitivity policy, that is a gap you will have to close yourself.

The 60 KB figure is also worth placing in context. It is the weight of the library with the essential CSS, not of your application, and the manifest ships only the dist directory, so the type declarations and the separate complement and transition bundles are part of what you pull in. If you import two transitions and one complement, you are not necessarily shipping the other nineteen.

Where vue-flux is the wrong choice

The first wrong case is a project that is not on Vue 3. The peer dependency is vue at ^3.5.0, and the component uses the script setup style with named slots, so a Vue 2 codebase cannot adopt this without a migration. Version 5 documentation exists for older lines, but the current package targets modern Vue.

The second wrong case is a project on an older Node version. The engines field requires ^20.19.0 || >=22.12.0, which excludes Node 18 entirely and also excludes Node 20 releases before 20.19.0. In a build environment pinned to an older LTS this is a hard stop, and it is easy to miss because nothing in the quick start mentions Node.

The third wrong case is a content slider rather than an image slider. The resource model is built around images with captions, the transitions are visual effects on a single slide, and the components are about slides rather than about pagination of a long list of items. If you want a carousel of cards with text, the pieces here are the wrong shape.

The fourth wrong case is a team that wants one component with no assembly. The complements are separate exports, and the example imports all five while telling you to remove the ones you do not need, which means the bundle you ship depends on how carefully you trimmed the imports.

The fifth wrong case is expecting a mature release train. The repository has no GitHub releases, the last push was on 2026-07-26, and the documentation is split across version 5, 6 and 7 overviews, so a project that needs long term version pinning has to decide which of those lines to standardise on.

vue-flux against writing the transitions yourself

The realistic alternative is not a competing slider package but the option of building the effect in your own components with CSS, which is what most teams do before reaching for a library. The difference in approach is where the work lives.

Hand written means the transitions are yours. You write a fade in a few lines, and you own every visual bug, every responsive adjustment and every accessibility decision. You also own the cost of adding the twentieth effect, which is what a library like this amortises across users. For a site with one slider and one effect, that arithmetic often favours writing it yourself.

vue-flux inverts the trade. The cost moves from writing effects to assembling components, and it is a real cost: three import paths, a resource class, a ref based imperative API, and a slot per complement. In exchange, a project gets twenty effects, a documented extension point for a twenty first, and the same set of behaviours across browsers, since the documentation states the slider is supported by all major browsers.

The project also names its own inspiration, Flux Slider, and the credit is worth reading as a design lineage rather than a comparison. The approach here is a Vue 3 component library with typed exports, tree shakable subpath entries and a component API that slots pieces in, not a standalone script attached to a DOM container. For a Vue 3 codebase with several sliders, that difference is the deciding factor, because the slider becomes part of the component tree and reacts to the same state as everything else.

Editorial conclusion

vue-flux fits a Vue 3 application that needs a slider with more personality than a bare fade, and a team willing to accept a component library rather than hand written CSS. It does not fit a project still on Vue 2, a project that needs server rendered markup for the slider, or a team that wants a single dependency with no extras to assemble. Before adopting it, confirm your Node version satisfies the engines field of ^20.19.0 or 22.12.0 and above, check that vue 3.5 or newer is what you are on because that is the peer dependency, and read the version 7 documentation for the complement list, since importing from vue-flux, vue-flux/complements and vue-flux/transitions is three separate entry points rather than one.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. ragnarlotus/vue-flux on GitHub
5. README