Esta es la entrega #10 de Awesome Curated: The Tools, la serie donde disecciono las herramientas que pasan el filtro de nuestro sistema de curación automático. Hoy le toca a algo que parece simple pero que tiene más profundidad de la que se ve a primera vista.
Hay un momento en la carrera de todo desarrollador web donde el cliente —o el diseñador, o el product manager— te dice: "necesitamos un carousel acá". Y en ese momento, algo muere adentro tuyo. No porque sea difícil técnicamente, sino porque sabés lo que viene: tres días buscando la librería correcta, cinco tutoriales desactualizados, una implementación propia que queda rota en Samsung Internet, y finalmente, a las 11 de la noche, dándote cuenta de que el touch en iOS se siente como arrastrar un ladrillo.
Me pasó en 2022, trabajando en un proyecto de e-commerce con un catálogo de productos que tenía que funcionar como carrusel en mobile. Probé tres librerías antes de llegar a Swiper. Las primeras dos tenían comportamiento táctil que parecía sacado de 2013. La tercera funcionaba bien pero requería jQuery. Cuando finalmente abrí la doc de Swiper y vi el wrapper oficial para React, con lazy loading built-in y aceleración por GPU, pensé: ¿por qué no empecé acá?
Qué hace
Swiper es la librería de sliders/carousels táctiles más completa del ecosistema web moderno. Cero dependencias externas. Wrappers oficiales para React, Vue, Angular y Web Components. Transiciones aceleradas por hardware que en iOS y Android se sienten como si fueran nativas.
No estamos hablando de un jQuery plugin glorificado. Swiper tiene su propio sistema de módulos que podés importar selectivamente: paginación, navegación con flechas, lazy loading de imágenes, autoplay, thumbnails, efectos de parallax, zoom, y una docena de transiciones (fade, cube, flip, cards). Todo esto sin meter media librería de terceros en el bundle.
La API en React es declarativa y bastante limpia:
import { Swiper, SwiperSlide } from 'swiper/react';
// Importamos solo los módulos que necesitamos — clave para no inflar el bundle
import { Navigation, Pagination, Lazy } from 'swiper/modules';
import 'swiper/css';
import 'swiper/css/navigation';
import 'swiper/css/pagination';
function ProductCarousel({ productos }) {
return (
<Swiper
modules={[Navigation, Pagination, Lazy]}
spaceBetween={16} // espacio entre slides en px
slidesPerView={1.2} // mostramos un poco del próximo slide (patrón UX clásico en mobile)
navigation // flechas prev/next
pagination={{ clickable: true }}
lazy={true} // lazy loading nativo — no cargamos imágenes fuera del viewport
breakpoints={{
// en desktop mostramos más slides — responsive sin media queries extra
768: { slidesPerView: 2.5 },
1200: { slidesPerView: 3.5 },
}}
>
{productos.map((p) => (
<SwiperSlide key={p.id}>
<img
data-src={p.imagen} // data-src para lazy loading
className="swiper-lazy"
alt={p.nombre}
/>
<p>{p.nombre}</p>
</SwiperSlide>
))}
</Swiper>
);
}El CSS lo podés importar modularmente también. Si no usás el módulo de scrollbar, no importás el CSS de scrollbar. Simple.
Por abajo, Swiper usa transform: translate3d() y will-change para forzar que el navegador delegue las animaciones a la GPU. El resultado es que el scroll táctil tiene inercia real —con deceleración física que respeta los parámetros del sistema operativo— en lugar del comportamiento robótico que tenés con CSS puro o la mayoría de las alternativas.
El sitio oficial con la documentación completa está en swiperjs.com y el repo en GitHub tiene más de 39k estrellas. No es hype reciente: lleva años acumulando ese consenso.
Por qué está en la lista
Swiper apareció en 4 awesome lists independientes. Cuando un componente de UI específico —no un framework, no una librería de propósito general, sino un slider— logra ese nivel de consenso, algo está haciendo bien.
La diferencia con alternativas como Keen-Slider o Embla Carousel no es que Swiper sea objetivamente mejor en todo —Embla es notablemente más liviano— sino que Swiper tiene los wrappers oficiales más completos, la documentación más exhaustiva, y el soporte multi-framework sin necesitar adaptadores de terceros. Si trabajás en un equipo donde hay proyectos en React, Vue y Angular simultáneamente, tener una sola librería que funciona igual en los tres es un activo real.
El sistema de módulos también importa. Antes de que Swiper lo implementara bien, la queja recurrente era el bundle size. Hoy, si importás solo Navigation y Pagination sin nada más, el impacto en el bundle es mucho más razonable. El ~30kb gzip que figura como número de referencia es para el paquete completo con todos los efectos y módulos.
Además —y esto es algo que aprecio mucho como alguien que vivió migraciones dolorosas— el equipo publica changelogs detallados y guías de migración entre versiones mayores. La API cambió bastante de v6 a v8 y de v8 a v11, sí, pero no te dejan solos en el proceso.
Cuándo NO usarlo
Primer caso honesto: si tu carousel tiene tres slides fijos y no necesitás touch, probablemente Swiper sea overkill. Para eso existe CSS puro con scroll-snap-type. Cero JavaScript, cero dependencias, soporte nativo en todos los browsers modernos:
/* Un carousel básico táctil solo con CSS — sin JS */
.carousel {
display: flex;
overflow-x: auto;
scroll-snap-type: x mandatory; /* snap al slide más cercano */
-webkit-overflow-scrolling: touch; /* inercia en iOS */
gap: 16px;
}
.carousel-slide {
scroll-snap-align: start; /* cada slide hace snap desde el inicio */
flex: 0 0 80%; /* cada slide ocupa el 80% del ancho */
}Segundo caso: si el performance es crítico y el bundle size te duele, mirá Embla Carousel. Es más pequeño, más extensible por diseño, y tiene una filosofía de "traé solo lo que necesitás" llevada al extremo. La contra es que la API es más de bajo nivel y requiere más configuración para cosas que en Swiper son un prop.
Tercer caso, el más importante: cuestioná si realmente necesitás un carousel. Hay bastante evidencia de UX que sugiere que los carousels reducen el engagement en landing pages. No porque Swiper sea el problema, sino porque el patrón mismo puede ser problemático. Si el cliente te pide un carousel, preguntá qué problema quiere resolver — a veces hay una respuesta mejor.
Cierre
Swiper pasó el filtro del sistema de curación por las razones correctas: consenso real de la comunidad, mantenimiento activo, y una propuesta de valor clara que resiste el escrutinio técnico. No es magia, pero hace lo que promete mejor que casi cualquier alternativa.
Esta es la entrega #10 de Awesome Curated: The Tools. Si llegaste acá directo y no viste el resto de la serie, hay posts que vale la pena revisar: el de Sniffnet para monitoreo de red y el de Node.js que arrancamos la semana pasada son buenos puntos de entrada si te interesa el ecosistema de herramientas más allá del ML. El próximo post de la serie sigue el mismo criterio: una herramienta que apareció en múltiples listas, que pasó el filtro automatizado, y que yo revisé personalmente antes de escribir una sola palabra sobre ella.
Artículos Relacionados
Next.js App Router caching: revalidate, dynamic y no-store sin folklore
El problema con Next.js caching no es memorizar los flags. Es decidir qué tan fresco necesita ser cada dato. Una guía para leer revalidate, dynamic y no-store como contratos de datos, no como trucos aislados.
Sniffnet: monitoreá tu red sin volverte loco con tcpdump
Sniffnet es un monitor de tráfico de red multiplataforma escrito en Rust. UI real, gráficos en tiempo real, sin necesitar un título en seguridad para entender qué está pasando.
XGBoost: gradient boosting que dominó Kaggle y sobrevivió al hype
XGBoost no es moda: es el algoritmo que ganó cientos de competencias de ML con datos tabulares. Por qué sigue siendo referencia obligada en 2025 y cuándo usarlo.
Comentarios (0)
¿Qué pensás de esto?
Dejá tu comentario en 10 segundos.
Usamos tu login solo para mostrar tu nombre y avatar. Nada de spam.