Что вы должны знать о Meteor.js, прежде чем начать.

Я наткнулся на Метеор еще в 2012 году, чуть позже его выхода. Было интересно. Он предлагал запускать один и тот же код JavaScript как на сервере, так и на клиенте, что было странной и новой концепцией, но всем понравилось. Решение абстрагироваться от сложностей взаимодействия клиент-сервер было очень привлекательным в то время, когда полная перезагрузка страницы для отправки форм стала хромать.

Идея заключалась в том, чтобы иметь облегченный клиентский кэш сегмента базы данных и выполнять запросы и обновления на обеих сторонах. Затем пользовательский интерфейс автоматически обновлялся из кеша без каких-либо явных манипуляций с DOM. Тем временем данные прозрачно отправлялись клиенту для исправления любых возможных несоответствий, поэтому единственным источником правды оставался сервер.

Это было действительно круто. В то время я приветствовал каждое решение, которое помогало избавиться от ненужных старых практик и перейти на новый веб.

Перенесемся на 3 года вперед, к лету 2015 года. Node.js распространен повсеместно, а метод запуска одного и того же кода на клиенте и сервере теперь широко известен как изоморфный JavaScript, хотя степень его определения со временем немного изменилась. . В настоящее время он в основном используется для включения маршрутов рендеринга как на стороне клиента, так и на стороне сервера, что полезно, учитывая, что, хотя большинство пользователей хотят мгновенно обновлять представления, поисковые системы все еще ожидают получить полностью отображаемую страницу во всей ее статической красоте.

Благодаря статье TechCrunch, описывающей огромное финансирование, которое Meteor удалось получить, я решил взглянуть на него еще раз. Это был все тот же монолитный фуллстек фреймворк, который обещал резко ускорить разработку. Самым большим дополнением стал менеджер пакетов, которого не было в оригинале. Я попробовал это, повторно реализовав Tinder на выходных (примечание для себя: материал для блога).

Проект был коротким и веселым, но этого уже было достаточно, чтобы выделить его недостатки: блокировку фреймворка, проблемы с производительностью и совместимостью библиотек и общую одержимость глобальным состоянием. Это стало неприятным даже для проекта такого размера. Мгновенные обновления моделей выглядели довольно круто на бумаге, но я не нашел для них реального применения, кроме функции чата. Я повеселился, потом скопировал на флешку и год не трогал Метеор.

У нас есть дело с несколькими друзьями, когда мы садимся раз в неделю с явным намерением «кодировать». И я решил, что пришло время создать сайт сравнения цен на видеоигры, который действительно работает. Такой проект по сути представляет собой пользовательский интерфейс поверх поисковой системы и базы данных. В идеале html следует загружать только один раз и динамически наполнять контентом. Поэтому я подумал, что философия Meteor данные по сети может оказаться здесь полезной. Если нет, я все еще могу без особых проблем переписать код, чтобы он не зависел от Meteor.

И мальчик сделал я переписал его.

В то время, когда я начал работать над ним, Meteor только что достиг своей первой «взрослой» версии, v1.3. Это выглядело красиво и, похоже, устранило большинство проблем, с которыми столкнулись разработчики. Полная поддержка ES2015 и async/await, система модулей с import и, наконец, npm! Ура! Хотя для некоторых вещей по-прежнему было необходимо использовать пакеты Meteor, по крайней мере, нам не приходилось постоянно форкнуть обертки npm-пакетов только для того, чтобы обновлять их.

Неожиданным последствием этого стало то, что система быстрой сборки Meteor, которая изначально рекламировалась как одна из ее убийственных особенностей, стала невыносимо медленной. Например, я мог бы выпить кофе и поболтать со своим соседом по дому не спеша. После небольшого исследования проблем GitHub я обнаружил, что Meteor начал делать некоторые странные вещи, чтобы оставаться автоматическим, «просто работающим» фреймворком, которым он был раньше.

Например, при сборке он просто копирует всю папку node_modules. Зависимости Dev также. Все это.

Потому что что, если у разработчика есть пакеты, отличные от npm? Что, если их зависимости разработки на самом деле очень сильно зависят от производства? Если система сборки Meteor просто скопирует файлы package.json и вызовет для них npm install --production, все может сломаться, и это будет не очень похоже на Meteor. Отслеживание операторов импорта и встряхивание дерева также невозможно, потому что Meteor хочет быть обратно совместимым с версиями до 1.3.

Недостатком такой универсальной системы является то, что она не может делать каких-либо других разумных предположений. В настоящее время, если вы хотите (как бы) ускорить сборку, вам приходится прибегать к таким хакам:

mv node_modules .node_modules.backup
npm install --production
meteor build
rm -rf node_modules
mv .node_modules.backup node_modules

Но если вам нужно вручную вмешаться, чтобы исправить что-то в автоматизированном процессе сборки, вы также можете развернуть свой собственный с помощью Webpack или одного из других доступных решений для связывания.

Когда Meteor только появился, он хотел исправить экосистему. Я понимаю. Не было единого подхода к созданию веб-приложений. Существовали сотни инструментов и библиотек для решения одних задач, а другие полностью отсутствовали. И в конце нужно было убедиться, что все эти вещи хорошо интегрируются и ничего не ломается.

Но когда стандартом становится экосистема со всеми ее недостатками, единственный способ выжить — это принять ее. Чем более вы самоуверенны, тем на большие компромиссы вам приходится идти.

Meteor был отличной идеей, которая помогла направить веб-разработку в более дружелюбное русло, но, похоже, пришло время двигаться дальше. Могут ли крупные инвестиции Meteor Group в Аполлон и недавняя борьба за то, чтобы разбить Meteor на отдельные полезные пакеты, быть подтверждением этого?

Может быть. В любом случае, я благодарен.