В ASH мы любим Эмбер. Но мы больше не полностью любимы Эмбер. Мы неразлучны семь лет. Фаза медового месяца давно прошла, но даже после этого мы все равно прекрасно провели время с Эмбер. Это отличный фреймворк, который может и используется для создания отличных приложений, таких как Apple Music, LinkedIn, PlayStation Store, Square, Discourse и других. Мы использовали его для создания большинства наших веб-сайтов, которые состоят из общих компонентов, написанных как Ember Engines или addons. Эти компоненты собираются вместе, как блоки Lego, в любой форме, которую вы хотите, для создания веб-сайтов, которые мы используем как внутри, так и снаружи. Мы любим Эмбер. Я люблю Эмбер. Я просто не знаю, что я влюблен в него, как раньше.

Эмбер, нам нужно поговорить

Хотя Ember сослужил нам хорошую службу, несколько лет назад произошло нечто, что определило наше нынешнее положение. Некоторые команды не считали, что это подходящий инструмент для их нужд. Одной из причин было то, что им не хватало онлайн-поддержки, когда она им была нужна. Поэтому они выбрали Angular, еще один очень мощный и даже более популярный фреймворк, с которым у этих команд уже был опыт. Проблема возникла позже, когда проектам нужно было интегрироваться друг с другом (изначально это не планировалось). Команды смогли заставить его работать, но мы никогда не были полностью удовлетворены решением. Веб-сайты содержали фрагментированные маршруты, и в некоторых случаях командам приходилось разрабатывать дублирующие функции в обеих средах. Нам не нравилось ощущение наличия двух партнеров — пора было выбрать одного.

Много рыбы в море

Если бы мы ограничились только Ember и Angular, у нас был бы выбор из двух отличных фреймворков. Но что, если бы для нас было что-то еще? Выбор одного фреймворка — важное решение. Мы хотели убедиться, что сделали правильный выбор. Теперь выбор был больше, чем когда мы впервые выбрали Ember. Не говоря уже о том, что мы уже другая компания, чем была, когда выбрали ее. Мы рассмотрели все варианты, но в конечном итоге остановились на Ember, Angular, React, Vue и Svelte. Мы также заглянули в Blazor и Flutter из любопытства и интриги, но быстро решили, что выбор стоит между первой пятеркой.

Это не ты, это мы

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

Поддержка сообщества

У Ember отличная основная команда, которая проделывает большую работу, сообщая о направлении развития фреймворка и прислушиваясь к сообществу. Он не принадлежит какой-то одной компании, как Angular и React. Но есть компании, в которые вложены значительные средства и в которых много членов основной команды, а именно LinkedIn, которые вносят свой вклад в Ember. И они проделали огромную работу, чтобы Ember оставался открытым, современным и обновленным. Но что произойдет, если LinkedIn тоже передумает и решит использовать другую структуру? Сообщество Ember небольшое, но сильное. Он потерял бы значительную часть своего сообщества. И одна из наших проблем заключается в том, что в сообществе не так много разработчиков, чтобы заполнить пустоту, как это могло бы произойти, если бы Facebook перестал использовать React.

Кроме того, ответы и поддержку найти не так просто, как в случае с другими технологиями. Ember перенесла свои основные платформы поддержки сообщества в Discord. Будем честными, многие инженеры обращаются к Stack Overflow, когда не могут найти ответ в документации (хорошо, а в некоторых случаях даже до документации). На Stack Overflow для Ember просто не так много обновленного контента.

Объедините это с меньшим сообществом, и может быть сложно найти ответы на вопросы. Точно так же, если вы ищете курс или статьи об Ember, вы можете их найти. Но количество обновлений просто не соответствует другим фреймворкам. Конечно, если бы больше людей из сообщества (по общему признанию, таких как я) активизировалось, это могло бы быть лучше. Но спрос не так сильно стимулирует предложение, как для других фреймворков. Это не суждение о сообществе или команде, просто наблюдение, полученное от других разработчиков, которых я видел.

Итог:справка по Ember, особенно для новичков, становится менее доступной и до нее сложнее добраться по сравнению с другими фреймворками.

Новые возможности

Ember всегда чувствовал себя немного отстающим в возможности писать современный JavaScript и использовать новые функции. Например, мы не могли использовать классы в компонентах Ember до тех пор, пока они не использовались в React. Да, многое в React уходит от классов, но нам пришлось расширять Ember.Object для каждого компонента, так что у нас даже не было выбора. Динамический импорт и ленивые маршруты загрузки были недоступны, если кто-то не использовал Ember Engines (которые мы любим и любим) или пока не поддерживался ember-auto-import. И если движок поддерживает ленивую загрузку, это должно было стать решающим изменением для команд, интегрирующих его. Между тем, я проводил начало своего утра за чтением статей, знакомящих с функциями других фреймворков, и чувствовал себя Эбенезером Скруджем, стоящим на морозе, заглядывающим в окно и наблюдающим, как все внутри празднуют Рождество.

Так что же представляет собой наше решение по замене React для Ember Engines и какие функции нам в них нравятся?

Ничего.

В отличие от Ember Engines, с React Router мы сможем лениво загружать любой компонент другой команды без необходимости что-либо активировать. Важность этого изменения для команд, создающих распределенные компоненты, не должна быть упущена. В настоящее время, если у команды А есть движок (не отложенная загрузка), который смонтирован в приложении Ember команды Б, команда Б может увидеть возможность повышения производительности и запросить задачу для включения отложенной загрузки… в бэклоге команды А.

Затем команде А необходимо расставить приоритеты и внести изменения, распространить новую (ломающую) версию своего движка всем командам, которые его используют. Каждой команде, не только команде B, необходимо установить последнее критическое изменение в свое приложение. Это означает, что команда C, команда D, команда E и т. д. должны добавить задачи для обновления до последней (сейчас) лениво загруженной системы. Что делать, если некоторые команды не могут сразу обновить движок? Команде А потребуется двойное окно обслуживания для поддержки версий 1 и 2. Довольно легко увидеть, как это подрывает производительность и моральный дух. Инженеры предпочитают работать над более крупными и сложными проблемами.

Идя дальше, мы, наконец, можем лениво загружать наши собственные компоненты в наши приложения, чтобы уменьшить размеры пакетов с помощью React.lazy. Это то, что на данный момент не поддерживается в основных функциях ember-cli. Как лидеру трудно возлагать слишком большие надежды на производительность команды, когда наша основная структура делает некоторые из этих усилий более сложными, чем в идеале. Автоматическое встряхивание деревьев — это то, о чем мы мечтали много лет — и теперь это доступно!

Итог: React, похоже, предлагает более современные функции, которые соответствуют нашим потребностям, быстрее и с меньшими трудностями.

Так много хороших людей забрали. Или не хотите, что мы можем предложить

Как лидер команды Front End, одна из моих самых важных обязанностей — помогать команде расти и находить новых замечательных людей, которые присоединятся к нам. Существует реальная проблема, связанная с тем, что инженеры слишком сосредоточены на одном конкретном фреймворке JavaScript. Любой, кто задавал базовый вопрос о JavaScript в интервью, вероятно, получил ответ вроде «ну, в Angular мы делаем это» или «я знаю, как ответить на это только тем, что мы делаем в React».

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

Итог:Одним из моментов, которые мы учитывали при выборе структуры, было ее влияние на рекрутинг. И это повредило рейтингу Эмбер в нашем списке.

Это слишком большое обязательство

Одна из замечательных вещей, которая происходит после запуска ember new [appname], заключается в том, что большинство инструментов, необходимых для сложного приложения, готовы к использованию. Маршрутизация, тестирование (модуль и пользовательский интерфейс), выборка API и управление состоянием уже установлены и гарантированно работают друг с другом. Пока вы не используете другой фреймворк и не должны выяснить, какие инструменты использовать (сейчас мы находимся в этом процессе), вы не понимаете, как здорово это иметь. Особенно, если вы ждали, пока ваш проект не начнет масштабироваться.

Наличие всех этих инструментов означает, что вы должны прочитать документацию и изучить ее, прежде чем приступить к работе над проектом. И они (в основном) принадлежат Ember. Так что, если вы используете готовые инструменты (например, Ember Data), но знакомы с Redux, вы можете либо установить сторонний аддон (о, и надеюсь, что он стабилен и поддерживается) или изучите Ember по умолчанию. Это множество новых инструментов для новых инженеров, которые нужно изучить сразу, и это означает, что вы, вероятно, станете более сосредоточенными на своих знаниях о техническом стеке. Это также увеличивает время выхода на проектную мощность для проектов и новых инженеров.

Итог:уникальный набор инструментов Ember иногда мешает некоторым инженерам легко освоить инструменты, с которыми они знакомы, и требует больше времени для освоения.

Мы никогда не забудем времена, которые у нас были

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

Но дело в том, что сегодня мы другая организация, чем была, когда мы приняли Ember. И наши потребности изменились. Я надеюсь, что другие продолжат использовать Ember. И Угловой. И все остальные фреймворки, которые существуют сегодня и появятся в будущем. Чем больше вариантов (конечно, в меру), тем больше они могут продолжать учиться, конкурировать и помогать друг другу, так что все они могут продолжать становиться лучшими инструментами. И, в свою очередь, сделать Интернет лучше.

Мы любим тебя, Эмбер, но пора двигаться дальше. Это не ты, это мы.

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

Так как же мы решили внести изменения?

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

В ASH у нас нет преданных архитекторов. У нас есть группа старших инженеров из каждой продуктовой группы, которые собираются еженедельно, чтобы обсудить новые потребности команды и порекомендовать решения. При выборе фреймворка мы использовали процесс этой группы и принимали решения через него. Но группа также состояла из всех, кто хотел присоединиться, включая инженеров среднего и младшего звена. Затем эти инженеры начали работать над рекомендуемым путем миграции для команд, а также решать, какие инструменты заменят наши текущие инструменты Ember (и Angular).

Я напишу об этом подробнее в следующем посте. А пока давайте просто отметим хорошие времена, которые у нас были с Ember, и с нетерпением ждем будущего с React.

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