Blossom Carousel keeps the native scroll and adds drag on top

The carousel that refuses to give up native scrolling

The positioning sentence is the whole pitch. Blossom Carousel is described as the first carousel library that builds on native browser scrolling rather than taking it over, and it provides a small drag enhancement for pointer devices while maintaining the core interaction model, performance and accessibility of a real scroll container. That is a deliberate rejection of the standard architecture, where a carousel hides an overflow container, translates a track with transforms, and reimplements momentum, snapping, keyboard handling, focus management and screen reader semantics by hand. Everything a native scroll container gives you for free, including the platform's own performance work and the accessibility behaviour that assistive technology already understands, is inherited rather than reimplemented. The audience is a team that has been burned by a carousel that broke the keyboard or fought the platform, and the cost of the approach is that the visual transitions a transform engine can do are largely out of reach, because the scroll position is the browser's to decide.

Drag for pointer devices, and nothing at all on touch

The feature list is where the design becomes concrete. Native scrolling gives full performance and accessibility. Dragging is custom, physics-based dragging for all pointer types. Navigation controls are first-class, with Previous, Next and Dots controls and customizable dot rendering. There is no abstraction, in the sense that it works with all native web APIs. Configuration is done with CSS, working with CSS scroll-snap, position sticky and scroll-driven animations and more. And the detail that stands out is the weight: 0kb on touch devices, because Blossom only loads when a fine pointer device is detected. That single line tells you the whole philosophy. A mouse user gets a drag gesture with momentum, and a phone user gets a document that scrolls, with no JavaScript shipped and no gesture handling to fight the platform's. Framework support is a set of components for React, Vue, Svelte and Web Components, and the last item on the list is the honest one, experimental cyclical scrolling, which allows the carousel to infinitely loop.

Five packages, and the one you actually need

The installation table is the package layout, and it is a familiar split. There is a core package, @blossom-carousel/core, which is the library itself, and a framework package for each target, @blossom-carousel/vue, @blossom-carousel/react, @blossom-carousel/svelte and @blossom-carousel/web for the web component, each installed with npm install and each linked to its own documentation page. The install commands are the plain package names:

npm install @blossom-carousel/core
npm install @blossom-carousel/react
npm install @blossom-carousel/vue
npm install @blossom-carousel/svelte
npm install @blossom-carousel/web

The core package is the interesting one for anyone who is not in a framework, because the claim of no abstraction means you can use it with any rendering approach, and the web component package is the escape hatch for a stack that has no framework at all. The repository is a pnpm workspace with a turbo pipeline and vitest, and the root scripts show the shape of the development setup, with a dev script per framework package filtered by name, a publish:framework script that publishes the four framework packages together with the access public flag, and a test:core script that runs vitest only over packages/core/src.

Migration guides for the libraries you are probably leaving

The most useful section of the README for an evaluating developer is the migration table, because it names the incumbents directly. There are guides for Embla, Swiper, Splide, Slick and Flickity, and the fact that five exist tells you which part of the ecosystem is looking at this project. The table names Embla, Swiper, Splide, Slick and Flickity, which shows which established carousel libraries the project expects users to come from. A native-scroll carousel instead gets a scroll container with CSS scroll-snap, so slide state is derived from scroll position, styling is CSS, and the previous and next controls are buttons that scroll. The example gallery on the site is organised by complexity, which suggests the intended usage is mostly CSS-first, with the JavaScript reserved for the drag.

What is settled and what is not

The state of the project is worth stating carefully, because the README mixes settled and experimental claims. The core ideas, native scrolling, pointer drag, navigation controls, CSS configuration and the touch-device zero weight, are presented as the product. The cyclical scrolling, which allows the carousel to infinitely loop, is explicitly marked experimental, and that is a meaningful gap, because infinite loop is the feature people most often want from a carousel and because it is the one thing a native scroll container cannot do without a content duplication trick. There are no GitHub releases, and the root package.json is a private package at version 1.0.0 whose description calls the project a native-scroll-first carousel component for the web, so the version you install comes from the framework packages on npm. The licence deserves a second look too, because Apache 2.0 appears in the licence field shown for the repository, while the root package.json declares MIT, so read the LICENSE file in the repository root rather than trusting either label. The website, the documentation guides, the example gallery and the migration guides are all hosted on the project's own domain, which is where the real documentation lives.

Editorial conclusion

Blossom Carousel is the right choice when accessibility and native behaviour matter more than the slide transitions a transform engine gives you, because the browser keeps doing the scrolling and the library only adds a drag gesture on top, which is also why it costs nothing on phones. It is the wrong choice for a design that depends on looping infinitely, since cyclical scrolling is marked experimental, and it is a poor fit if you need the specific option surface of one of the established carousel libraries, though the migration guides suggest the mapping is worked out. Before adopting it, read the migration guide for the library you are leaving, test the drag physics on the pointer devices you actually support, and check the licence in the LICENSE file, since the licence field shown for the repository and the root package.json name different licences.

Frequently asked questions

Official sources

1. Issues
2. jespervos/blossom-carousel on GitHub
3. License: Apache-2.0
4. README