Актуален ли Meteor.js в 2026 году?

Да: Meteor.js активно поддерживается. Версия 3.5.2 вышла 4 сентября 2026 года — согласно официальному changelog.

Это может стать неожиданностью, если вы последний раз смотрели в сторону Meteor несколько лет назад. Фреймворк, построенный на Fibers, шаблонах Blaze и самописном бандлере эпохи Babel, был заменён — и стоит разобраться, чем именно, прежде чем окончательно списывать Meteor со счетов или решать, что делать с принадлежащим вам приложением на 2.x.

В этой статье разбираемся, для чего был создан Meteor, почему о нём перестали говорить, что реально изменилось между 2024 и 2026 годами и кому стоит, а кому не стоит использовать его сейчас.

Используется ли Meteor.js до сих пор? Сначала факты

Фреймворк выпускается с регулярной периодичностью. Changelog фиксирует 18 релизов в линейке 3.x — от 3.0 в июле 2024 года до 3.5.2 — вдобавок к 17 минорным версиям серии 2.x, выходившим с января 2021 по май 2024 года. Одна деталь, о которой стоит знать, если решите проверить сами: репозиторий meteor/meteor не публикует GitHub Releases, поэтому вкладка releases выглядит пустой. Канонический источник — changelog, а не GitHub.

Продакшн-пользователи всё ещё существуют, документация актуальна, а команда ядра мержит community pull requests в каждом релизе. Делает ли всё это Meteor хорошим выбором — отдельный вопрос, и остальная часть статьи отвечает на него.

Для чего создавался Meteor?

Идея, заложенная в дизайн Meteor с момента его запуска в 2012 году, состояла в том, что real-time-приложению вообще не нужен слой API. Один язык работает на клиенте, сервере и в запросах к базе данных. Сервер публикует курсоры MongoDB через DDP — WebSocket-протокол Meteor — а клиент кэширует результаты в MiniMongo, in-memory реализации интерфейса запросов Mongo. Когда данные меняются на сервере, подключённые клиенты обновляются автоматически. Никаких REST-эндпоинтов, никаких GraphQL-резолверов, никакого кода синхронизации состояния.

Вокруг этого ядра Meteor собрал всё остальное, что нужно небольшой команде: интеграцию с MongoDB, полноценную систему аккаунтов с OAuth-провайдерами, сборщик с нулевой конфигурацией и деплой одной командой. С 2012 по 2017 год этот набор действительно позволял выпустить real-time-приложение быстрее, чем что-либо ещё в мире JavaScript — именно поэтому он покорил столько сердец и хакатонов.

Почему о Meteor перестали говорить?

«React победил» — лишь треть истории. Blaze, собственный слой шаблонов Meteor, проиграл React и уже не догнал его, но более глубокие раны были организационными. Примерно в 2016 году Meteor Development Group переключила внимание на Apollo и GraphQL, и фреймворк заметно перестал быть приоритетом компании. Бесплатный хостинг meteor.com исчез. Видные фигуры сообщества ушли, туториалы устарели, пакеты на Atmosphere были заброшены.

А затем наступила решающая часть: ожидание релиза, который уберёт Fibers. Fibers — библиотека корутин, благодаря которой серверный код Meteor выглядел синхронным — блокировала обновление Node и расходилась с тем, как работал весь остальной Node-код. Её удаление обсуждалось годами, ещё до того как Tiny приобрела Meteor в октябре 2019 года, а Meteor 3.0 вышел лишь в середине 2024-го. Значительная часть сообщества перестала ждать. Бренд умер быстрее технологии, а технология продолжала улучшаться в тишине.

Что изменилось с Meteor 3.0 по 3.5?

Meteor 3.0, вышедший 15 июля 2024 года, полностью убрал Fibers в пользу нативного async/await и заменил Connect на Express в качестве HTTP-слоя. Последующие релизы, согласно changelog, укладываются в единую линию:

Общая линия важнее любой отдельной строки: Meteor перестал быть кастомным рантаймом и стал обычным Node.js-приложением. Async/await вместо Fibers, Express вместо Connect, SWC и Rspack вместо самописного пайплайна на Babel и Change Streams вместо oplog tailing. У Change Streams есть минимальные требования: база данных должна быть MongoDB 6 или новее, развёрнутая как replica set или шардированный кластер. Там, где это не так, Meteor сам откатывается к oplog tailing или поллингу. Именно эта нормализация и делает переоценку фреймворка вообще осмысленной.

Для кода на 2.x миграция механична по своей форме: синхронные вызовы коллекций превращаются в асинхронные аналоги.

// 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" });

О производительности: собственные показатели сборки Meteor, измеренные на их приложении Galaxy Cloud, сообщают о примерно 60% ускорении сборки с SWC и более чем 3,5-кратном ускорении сборки и до 88% уменьшении клиентских бандлов с Rspack. Отдельный нагрузочный тест, проведённый командой Meteor на контейнере Galaxy, показал на 40% больше ёмкости по одновременным соединениям на Change Streams по сравнению с oplog. Относитесь к этим цифрам как к вендорским бенчмаркам.

«Поддерживается» — не то же самое, что «здоров»

Поддерживается ли Meteor и здорова ли его экосистема — разные вопросы с разными ответами. Фреймворк выпускает релизы; экосистема вокруг него остаётся тонкой. Кадровый рынок мал и сжимался десятилетие. Atmosphere, реестр пакетов Meteor, — лишь малая доля того, что предлагает мейнстримный npm, и многие пакеты, за которыми вы потянетесь, окажутся поддерживаемыми сообществом форками заброшенных оригиналов. Слой данных по своей архитектуре ориентирован на MongoDB, так что если ваши данные реляционные — вы воюете с фреймворком.

Более серьёзная проблема — соответствие задаче. Ключевая сила Meteor, доставка живых данных через сокет подключённым клиентам, просто не то, что оптимизирует большинство команд. Значительная доля Node-разработки — это сайты с серверным рендерингом, ставкой на SEO и большим объёмом контента, и для этой работы Meteor — неправильный инструмент. Если ваша метрика успеха связана с Googlebot, выбирайте что-то, созданное для этого.

Стоит ли использовать Meteor.js в 2026 году?

Meteor в 2026 году поддерживается, модернизирован и является разумным выбором для конкретного набора задач: real-time-first приложения — дашборды, чаты, инструменты для совместной работы; внутренние инструменты, где один язык и отсутствие слоя API важнее размера экосистемы; быстрые прототипы. Если у вас есть приложение на 2.x, путь апгрейда до 3.x реален, описан в официальном руководстве по миграции и его стоит пройти, а не оставлять приложение гнить на EOL-рантайме. Чем Meteor не является — так это дефолтным выбором общего назначения, и выбрать его для контентного сайта или публичного SEO-проекта было бы ошибкой. Проверьте changelog сами, запустите npx meteor на прототипе, если задача действительно про real-time, и принимайте решение о том фреймворке, который существует сейчас, а не о том, который вы помните.

Частые вопросы

Можно ли использовать с Meteor базу данных, отличную от MongoDB?

Можно, но вы потеряете главное преимущество фреймворка. Стек реактивности Meteor (публикации, MiniMongo и драйвер Change Streams) работает только с MongoDB, а встроенная система аккаунтов хранит пользователей там же. Базы вроде PostgreSQL работают через стандартные npm-драйверы внутри методов Meteor, но код загрузки данных вы пишете сами и live-запросов не получаете. Если ваши данные реляционные с первого дня — выбирайте другой фреймворк.

Требует ли Meteor 3 использования Blaze, или можно взять React, Vue или Svelte?

Meteor не привязан к слою представления. Команда meteor create по умолчанию создаёт React-приложение, а официальные скелеты существуют для Vue, Svelte, Solid и Blaze. Meteor предоставляет систему сборки, слой данных DDP и аккаунты, а UI рендерит выбранная вами библиотека. Blaze по-прежнему работает и поддерживается сообществом, но большая часть актуальной документации, скелетов и активности в пакетах ориентирована на React.

Можно ли обновить приложение с Meteor 2.x напрямую до 3.x, или нужны промежуточные шаги?

Рекомендуемый путь начинается на 2.x. Асинхронные методы коллекций (findOneAsync, insertAsync и остальные) появились в Meteor 2.8, поэтому вы можете переводить серверный код постепенно, оставаясь на 2.x, а затем перейти на 3.x, когда ничто больше не зависит от синхронных вызовов в стиле Fibers. Обычный блокер — сторонние пакеты Atmosphere: каждый используемый вашим приложением пакет должен получить версию, совместимую с 3.x, до переключения.

Нужен ли Galaxy для деплоя приложения на Meteor?

Нет. Команда meteor build создаёт стандартное Node.js-приложение, которое можно запустить на любом хостинге с Node и подключением к MongoDB: VPS, Docker или облачный провайдер. Galaxy — опциональный управляемый хостинг от Meteor Software. Одна деталь деплоя важна на 3.5: чтобы получить реактивность на Change Streams, ваша MongoDB должна быть версии 6 или новее и развёрнута как replica set или шардированный кластер. В противном случае Meteor сам откатится к oplog tailing или поллингу, без какой-либо настройки с вашей стороны.