Открытое письмо новым владельцам Meteor

Открытое письмо новым владельцам Meteor

Tiny только что приобрела Метеор. Вот что им следует знать.

Отказ от ответственности: это мои личные взгляды, и я не имею отношения ни к Tiny, ни к ЦРТ. Поэтому отнеситесь к этому совершенно неофициальному мнению с недоверием.

Meteor.js был впервые публично представлен в апреле 2012 года. Шесть месяцев спустя я начал писать книгу об этом с Томом Коулманом, главным создателем (среди прочего) экосистемы управления пакетами Meteor.

Эта книга, Discover Meteor, стала основным справочником для растущего сообщества Meteor и стала моим основным предметом внимания на следующие несколько лет, охватывая бесчисленные обновления, сообщения в блогах, подкасты и даже очень интересные футболка, которую я ношу по сей день.

Параллельно я также запустил Telescope, приложение-клон Hacker News с открытым исходным кодом, созданное с помощью Meteor, которое в свое время было, вероятно, крупнейшим приложением Meteor с открытым исходным кодом с точки зрения звезд GitHub.

Затем Telescope превратился в Vulcan.js, полнофункциональную платформу приложений React / GraphQL, которая жива и здорова и до сих пор использует Meteor под капотом.

Я говорю все это, чтобы дать некоторый контекст и показать вам, что я был связан с Meteor с самого начала.

Крошечный метеор

Итак, учитывая недавние новости о том, что Tiny приобретает Meteor у MDG (Meteor Development Group), я подумал, что сейчас хорошее время, чтобы вспомнить прошлое и возможное будущее Meteor и, возможно, дать новым владельцам несколько советов (и сделайте это. более дипломатично, чем в прошлый раз).

Почему Аполлон добился успеха (а Метеор - нет)

Лучший способ понять, что случилось с Meteor, - взглянуть на Apollo, который был построен той же компанией и большей частью одними и теми же людьми.

Во многих отношениях Apollo почти полная противоположность Meteor: в то время как Meteor - это широкая структура, включающая модули для всего, от отправки электронной почты до шаблонов и управления учетными записями пользователей, Apollo гораздо больше ориентирован на загрузку данных GraphQL.

И в то время как Meteor воспользовался простым подходом «это просто работает», влекущим за собой много магии за кулисами, Apollo оставляет много ручной работы конечному пользователю, иногда до такой степени, что кажущиеся простые операции становятся очень сложными (просто посмотрите на как они оба обрабатывают что-то вроде обновления вашего клиентского кеша после изменения на стороне сервера).

Это сделано намеренно: несмотря на свою популярность в те первые дни, Meteor фактически полностью не попал в цель корпоративного рынка, и поэтому MDG постарались скорректировать свою цель, когда дело дошло до их второго выстрела.

Без корпоративного рынка Meteor просто не могла бы надеяться когда-либо оправдать миллионы долларов финансирования, привлеченного на его основе, что сделало поворот неизбежным.

Корпоративный рынок

Так почему же Meteor не удалось завоевать желанный корпоративный рынок? Есть несколько основных причин.

Восприятие

Первоначально Meteor продемонстрировал функцию, позволяющую любому клиенту изменять серверную базу данных. Хотя эта функция всегда предназначалась для ускорения разработки и, очевидно, никогда не должна развертываться в производственной среде (пакет, который позволял это делать, даже назывался insecure), многие люди не понимали этого, и в результате Meteor приобрел репутацию слабого в безопасности. Тот факт, что Meteor изначально выбрал спорную архитектуру разрешить / запретить, которая позволила очень легко ошибиться и выявить дыры в безопасности в вашем приложении, не помог. В результате Meteor было трудно поколебать свою первоначальную репутацию инструмента прототипирования, который не подходил для более крупных проектов.

Представление

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

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

Проблема монолита

Последним гвоздем в гроб корпоративных надежд и мечтаний компании Meteor стало то, что в конце концов корпоративным клиентам не нужен универсальный монолит, который объединяет их в единую экосистему.

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

Сравните это с React, Vue или даже Apollo, которые нацелены только на одну часть стека, и все они могут постепенно добавляться в существующие приложения.

И это не просто теоретическая проблема: даже сегодня особенности Meteor могут сделать использование сторонних инструментов, таких как Storybook, намного сложнее, чем должно быть.

Кипячение океана

Тем не менее, даже без корпоративного рынка Meteor неуклонно росла за счет хакеров, студентов и малых предприятий, и у MDG мог бы быть хороший бизнес в виде Galaxy, их хостинг-платформы.

Однако в какой-то момент Meteor просто не мог конкурировать с остальной частью стремительно развивающейся экосистемы JavaScript.

• Его шаблонизатор Blaze был хорош, но уступал React или (позже) Vue.
• Его система комплектации могла делать некоторые удивительные вещи, но она не была популярна как Webpack и по сей день не может выполнять горячую перезагрузку модулей.
• Его уровень данных был удивительно простым и легким в использовании, но он не обладал гибкостью и корпоративной привлекательностью GraphQL.
• Его сервер работал, но не мог выполнять SSR так же хорошо, как Next.js, или обслуживать приложения так же быстро, как статические решения, такие как Gatsby.js.

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

Оглядываясь назад, очевидным решением было бы включить все эти новые инструменты в стек Meteor и отказаться от собственных решений Meteor (что, кстати, именно то, что мы делаем с Vulcan.js - подробнее об этом в конце этого поста).

Но как ни парадоксально это не удалось сделать Meteor из-за собственного успеха.

Метеорное сообщество

У Meteor все еще есть небольшое, но активное сообщество, но годы пренебрежения ЦРТ свели его на нет до стойких - и людей, которые используют Meteor потому, что им это необходимо.

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

Я имею в виду таких людей, как основатель Vue Эван Ю или команда Chromatic, которые также поддерживают Storybook, который сам был создан легендарным (по крайней мере, в сообществе Meteor) Арунода, который сейчас работает в Next.js.

(Тот факт, что так много деятелей сообщества JavaScript пришли из Meteor, одновременно вдохновляет и немного грустит. Вы не можете не задаться вопросом, что могло бы случиться, если бы все они остались.)

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

Итак, сегодня сообщество разделено на «консервативных» пользователей Meteor, которые хотят продолжать использовать Blaze и Minimongo, несмотря на то, что эти технологии не имеют нулевого принятия или поддержки за пределами экосистемы Meteor; и «прогрессивные» пользователи, которые приняли React и Apollo - и как таковые уже вышли за дверь.

Метеор сегодня

Таким образом, текущая ситуация несколько парадоксальна: технически говоря, Meteor сейчас в лучшем месте, чем когда-либо, благодаря героическим усилиям Бена Ньюмана, единственного помощника по поддержке Meteor в ЦРТ. Но вопрос в том, какое это имеет значение?

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

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

Следующие шаги

Мне кажется, что Tiny находится в положении тех парней, которые восстанавливают стальные орудия на YouTube. У них в руках какой-то старый заржавевший инструмент, и теперь их задача - превратить его в гладкий, полированный предмет, которым он должен был быть.

• В качестве первого шага я бы, вероятно, попытался выделить основных игроков в сообществе. Почитайте форумы, узнайте, что происходит на GitHub, и поговорите с как можно большим количеством людей.
• Затем определите одну или две основные технические проблемы (отсутствие перезагрузки горячего модуля было бы одной из них для меня) и потратите деньги на эти проблемы, пока они не будут устранены. Хорошим началом было бы удвоить зарплату Бена и нанять его вне ЦРТ, если это вообще возможно.
• Третье: избавьтесь от «старого» Метеора. По возможности сохраняйте обратную совместимость с Blaze, Minimongo и т. Д., Но четко укажите, что они устарели. Примите Apollo и GraphQL. Не бойтесь выбирать чью-то сторону, даже если это кого-то рассердит. Перепишите документы с нуля, чтобы они соответствовали этому новому подходу.
• Четвертое: ребрендинг. Meteor нужен тег как минимум «2.0», если не полное изменение названия, чтобы порвать с его плохим восприятием в последние несколько лет.

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

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

Но все могло пойти совсем не так. Если Tiny приобретет бренд Meteor, не наняв никого из команды Meteor, ему может быть сложно найти достаточно хороших специалистов, чтобы внести необходимые изменения. Если по какой-то причине Tiny не сможет вывести фреймворк на новый уровень, он может в конечном итоге решить закрыть все, чтобы не тратить хорошие деньги на плохие. В конце концов, Meteor - лишь один из многих проектов в Портфолио Tiny, и у них не будет той сентиментальной привязанности к структуре, которая всегда была у MDG.

Так что это будет нелегко, и если MDG - буквально составленная из одних из лучших разработчиков, которых я когда-либо знал или слышал - не смогла бы это сделать, то остается посмотреть, сможет ли Tiny.

Тем не менее, я надеюсь. Итак, вот вам еще семь лет Meteor!

Приложение: Vulcan.js

Я не хотел, чтобы этот пост превратился в рекламу Vulcan.js, но в то же время он все еще очень актуален для обсуждаемого вопроса. Итак, вот краткое объяснение, которое легко пропустить.

Vulcan.js вырос из проекта Telescope. По мере того, как все больше и больше людей принимали Telescope, многие из них начали настраивать его так, как я никогда не думал. Людям действительно понравилась отправная точка, которую дал им клон Reddit или Hacker News, и они смогли легко настроить ее для всех видов сообществ и социальных сайтов.

Поэтому с Vulcan мы решили сфокусироваться на одном уровне глубже и взглянуть на все примитивы современного веб-приложения: загрузка данных, формы, таблицы данных, учетные записи, разрешения, SSR и так далее.

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

И поскольку Meteor делал все возможное, чтобы сохранить свою оригинальную технологию, но постепенно терял из виду свое первоначальное видение, Vulcan пошел противоположным путем: мы сохранили видение, но отказались от Blaze, Minimongo, DDP и всего остального в пользу GraphQL и React.

В результате сегодня единственным видимым остатком Meteor в приложении Vulcan является стек учетных записей пользователей, и даже он скоро исчезнет. По сути, Meteor объединяет и обслуживает ваше приложение, но все остальное остается тем же самым современным технологиям JavaScript, которые также использует остальная часть экосистемы.

Но что делает Vulcan уникальным, так это то, что делает Meteor уникальным и по сей день: его полноценный характер. Поскольку Vulcan и Meteor охватывают весь стек от сервера к клиенту, мы можем объединить обе части уравнения без проблем.

Например, поскольку Vulcan GraphQL API генерируется из центральной схемы JavaScript, мы можем повторно использовать ту же схему для создания форм и таблиц данных, которые автоматически адаптируются к вашим данным.

Другими словами, просто укажите, что поле createdAt имеет тип Date, и не только результирующее поле GraphQL будет иметь правильный тип, но и полученный ввод формы будет использовать указатель даты; и соответствующий столбец с данными также будет содержать элементы управления фильтрацией на основе даты.

Вот что я имею в виду, говоря о сохранении первоначального видения Meteor. Несмотря на недостатки монолитного стека, приложения с полным стеком также предоставляют очень реальные преимущества и делают возможным то, что становится возможным только тогда, когда вы можете контролировать весь стек.

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

Конечно, это всего лишь мое собственное видение. Но если вам хоть немного интересно, я определенно рекомендую вам попробовать Vulcan.js!