¿Sigue siendo relevante Meteor.js en 2026?

Sí: Meteor.js se mantiene activamente. La versión 3.5.2 se publicó el 4 de septiembre de 2026, según el changelog oficial.

Esto puede sorprenderte si la última vez que le echaste un ojo a Meteor fue hace algunos años. El framework construido sobre Fibers, plantillas Blaze y un bundler propio de la era Babel ha sido reemplazado, y conviene entender qué lo reemplazó antes de descartar Meteor, o antes de decidir qué hacer con esa app 2.x que tienes en producción.

Este artículo cubre para qué fue diseñado Meteor, por qué dejaste de oír hablar de él, qué cambió realmente entre 2024 y 2026, y quién debería —y quién no— utilizarlo hoy.

¿Se sigue usando Meteor.js? Primero, la evidencia

El framework publica releases con una cadencia regular. El changelog registra 18 releases en la línea 3.x, desde la 3.0 en julio de 2024 hasta la 3.5.2, además de las 17 versiones menores de la serie 2.x que se extendieron desde enero de 2021 hasta mayo de 2024. Un detalle que conviene conocer si quieres comprobarlo por tu cuenta: el repositorio meteor/meteor no publica GitHub Releases, por lo que la pestaña de releases aparece vacía. El registro canónico es el changelog, no GitHub.

Sigue habiendo usuarios en producción, la documentación está actualizada y el equipo core fusiona pull requests de la comunidad en cada release. Que todo eso haga de Meteor una buena elección es otra cuestión, y el resto de este artículo la responde.

¿Para qué se construyó Meteor?

La premisa de diseño de Meteor, desde su lanzamiento en 2012, era que una aplicación en tiempo real no debería necesitar una capa de API en absoluto. Un solo lenguaje corre en el cliente, el servidor y las consultas a la base de datos. El servidor publica cursores de MongoDB sobre DDP, el protocolo WebSocket de Meteor, y el cliente almacena los resultados en MiniMongo, una reimplementación en memoria de la interfaz de consultas de Mongo. Cuando los datos cambian en el servidor, los clientes conectados se actualizan automáticamente. Sin endpoints REST, sin resolvers de GraphQL, sin código de sincronización de estado.

Alrededor de ese núcleo, Meteor empaquetaba todo lo demás que un equipo pequeño necesitaba: integración con MongoDB, un sistema de cuentas completo con proveedores OAuth, una herramienta de build sin configuración y despliegue con un solo comando. Entre 2012 y 2017 ese paquete era, con toda legitimidad, la forma más rápida de publicar una app en tiempo real que existía en el mundo JavaScript, y de ahí que conquistara tantos corazones y hackathons.

¿Por qué dejaste de oír hablar de Meteor?

“React ganó” es solo un tercio de la historia. Blaze, la propia capa de plantillas de Meteor, perdió frente a React y nunca recuperó terreno, pero las heridas más profundas fueron organizativas. Alrededor de 2016, Meteor Development Group desplazó su atención hacia Apollo y GraphQL, y el framework dejó visiblemente de ser la prioridad de la empresa. El hosting gratuito de meteor.com desapareció. Figuras destacadas de la comunidad se marcharon, los tutoriales quedaron obsoletos y los paquetes de Atmosphere fueron abandonados.

Después llegó el golpe decisivo: la espera por la release que eliminaría Fibers. Fibers, la librería de corrutinas que hacía que el código de servidor de Meteor pareciera sincrónico, bloqueaba las actualizaciones de Node y divergía del funcionamiento de cualquier otro codebase de Node. Su eliminación se discutió durante años antes de que Tiny se hiciera cargo de Meteor en octubre de 2019, y Meteor 3.0 no llegó hasta mediados de 2024. Gran parte de la comunidad dejó de esperar. La marca murió más rápido que la tecnología, y la tecnología siguió mejorando en silencio.

¿Qué cambió de Meteor 3.0 a 3.5?

Meteor 3.0, publicado el 15 de julio de 2024, eliminó Fibers por completo en favor de async/await nativo y sustituyó Connect por Express como capa HTTP. Las releases posteriores siguen un mismo arco, según el changelog:

El hilo conductor importa más que cualquier fila individual: Meteor dejó de ser un runtime a medida y se convirtió en una aplicación Node.js normal. Async/await en lugar de Fibers, Express en lugar de Connect, SWC y Rspack en lugar de un pipeline de Babel personalizado, y Change Streams en lugar de oplog tailing. Change Streams sí impone un mínimo: tu base de datos debe ser MongoDB 6 o posterior, ejecutándose como replica set o como clúster con sharding. Donde no lo sea, Meteor vuelve por sí solo a oplog tailing o a polling. Esa normalización es lo que hace legítimo reevaluar el framework.

Para código 2.x, la migración es mecánica en su forma: las llamadas sincrónicas a colecciones pasan a sus equivalentes asíncronas.

// Meteor 2.x
const doc = Tasks.findOne(taskId);
Tasks.insert({ text: "hello" });

// Meteor 3.x
const doc = await Tasks.findOneAsync(taskId);
await Tasks.insertAsync({ text: "hello" });

Sobre rendimiento: las propias cifras de build de Meteor, medidas en su app de Galaxy Cloud, reportan builds aproximadamente un 60% más rápidos con SWC y builds más de 3,5 veces más rápidos con bundles de cliente hasta un 88% más pequeños con Rspack. Una prueba de carga independiente ejecutada por el equipo de Meteor en un contenedor de Galaxy reportó un 40% más de capacidad de conexiones concurrentes con Change Streams frente a oplog. Tómalos como benchmarks del propio proveedor.

Mantenido no es lo mismo que saludable

Que Meteor esté mantenido y que su ecosistema esté saludable son preguntas distintas con respuestas distintas. El framework publica releases; el ecosistema a su alrededor sigue siendo escaso. La bolsa de talento es pequeña, y llevó una década encogiéndose. Atmosphere, el registro de paquetes de Meteor, es una fracción de lo que ofrece el npm mainstream, y muchos de los paquetes a los que recurrirías son forks mantenidos por la comunidad de originales abandonados. La capa de datos es MongoDB-céntrica por diseño, así que si tus datos son relacionales, estarás peleándote con el framework.

El problema mayor es el encaje. La fortaleza principal de Meteor —enviar datos en vivo por un socket a los clientes conectados— simplemente no es lo que la mayoría de los equipos está optimizando. Una buena parte del trabajo con Node consiste en sitios renderizados en servidor, orientados al SEO y con mucho contenido, y Meteor es la herramienta equivocada para ese trabajo. Si tu métrica de éxito involucra a Googlebot, elige algo diseñado para eso.

¿Deberías usar Meteor.js en 2026?

Meteor en 2026 está mantenido, modernizado y es una elección razonable para un conjunto concreto de tareas: aplicaciones real-time-first como dashboards, chats y herramientas colaborativas; herramientas internas donde un único lenguaje y la ausencia de capa de API pesan más que el tamaño del ecosistema; y prototipos rápidos. Si tienes una app 2.x, la ruta de actualización a 3.x es real, está documentada en la guía de migración oficial y vale la pena recorrerla en lugar de dejar que la app se pudra sobre un runtime en EOL. Lo que Meteor no es, es una opción por defecto de propósito general, y elegirlo para un sitio de contenidos o una propiedad pública orientada al SEO sería un error. Revisa el changelog por ti mismo, ejecuta npx meteor contra un prototipo si el encaje con el tiempo real existe, y decide sobre el framework que hay ahora, no sobre el que recuerdas.

Preguntas frecuentes

¿Puedo usar una base de datos distinta de MongoDB con Meteor?

Puedes, pero pierdes la principal ventaja del framework. El stack de reactividad de Meteor (publications, MiniMongo y el driver de Change Streams) solo funciona con MongoDB, y el sistema de cuentas integrado almacena allí los usuarios. Bases de datos como PostgreSQL funcionan mediante drivers estándar de npm dentro de los métodos de Meteor, pero escribes tu propio código de carga de datos y no obtienes consultas en vivo. Si tus datos son relacionales desde el primer día, elige otro framework.

¿Meteor 3 requiere Blaze, o puedo usar React, Vue o Svelte?

Meteor es agnóstico respecto a la capa de vista. Ejecutar meteor create genera por defecto el andamiaje de una app React, y existen skeletons oficiales para Vue, Svelte, Solid y Blaze. Meteor aporta el sistema de build, la capa de datos DDP y las cuentas, mientras la librería que elijas renderiza la UI. Blaze sigue funcionando y se mantiene desde la comunidad, pero la mayor parte de la documentación actual, los skeletons y la actividad de paquetes asumen React.

¿Puedo actualizar una app Meteor 2.x directamente a 3.x, o necesito pasos intermedios?

La ruta recomendada empieza en 2.x. Los métodos asíncronos de colecciones (findOneAsync, insertAsync y el resto) se introdujeron en Meteor 2.8, así que puedes convertir el código de servidor de forma incremental mientras sigues en 2.x, y saltar a 3.x una vez que nada dependa de las llamadas sincrónicas al estilo Fibers. Los paquetes de terceros de Atmosphere son el bloqueo habitual: cada uno de los que use tu app debe publicar una versión compatible con 3.x antes de que hagas el cambio.

¿Necesito Galaxy para desplegar una app de Meteor?

No. Ejecutar meteor build produce una aplicación Node.js estándar que puedes correr en cualquier host que ofrezca Node y una conexión a MongoDB: un VPS, Docker o un proveedor cloud. Galaxy es el hosting gestionado opcional de Meteor Software. Un detalle de despliegue importa en la 3.5: para obtener reactividad con Change Streams, tu MongoDB debe ser versión 6 o posterior y estar configurado como replica set o clúster con sharding. En cualquier otro caso, Meteor vuelve por sí solo a oplog tailing o a polling, sin que tengas que configurar nada.