Привет @digitaldominica — это не связано с обновлением Ember, но это известная проблема с новой боковой панелью администратора. Подробнее можно прочитать здесь: Introducing admin sidebar navigation - #37 by martin
Хорошо, принято. Спасибо.
2 лайка
Пост был объединён с существующей темой: Slick Image Gallery
Дэвид, можем ли мы с уверенностью предположить, что следующий релиз stable будет только для Ember 5?
Кроме того, есть ли какие-то мысли относительно приблизительных сроков следующего stable?
5 лайков
Следующая стабильная версия запланирована на 30 января, и, насколько мне известно, мы всё ещё укладываемся в этот срок.
Ember 5, безусловно, станет версией по умолчанию в выпуске 3.2. Остаётся уточнить, будет ли Ember 3 по-прежнему доступен через специальный флаг. Скорее всего, да, но мы постараемся чётко обозначить, что это не «поддерживаемая» конфигурация (например, с помощью предупреждения в панели администратора).
9 лайков
Спасибо
Это было бы невероятно полезно для прояснения ситуации, например, для клиентов.
6 лайков
Извините за ответ на старую тему. Предупреждающий баннер появлялся время от времени и исчезал, прежде чем я успевал понять, что вызывало его появление. Уже несколько недель он не появлялся. 
3 лайка
Спасибо за уточнение, @xJack. Обновление Ember уже несколько недель развернуто на наших хостингах, поэтому, думаю, проблема, о которой вас предупреждали, теперь решена 
4 лайка
Мы теперь убрали флаг функции EMBER_VERSION. В дальнейшем доступен только Ember 5.
Спасибо всем за помощь в проведении этого обновления! 
16 лайков
8 сообщений были перенесены в новую тему: Сайт не работает из-за обновления Ember 5
Вопрос: Это как-то оптимизирует JS или нет? Я спрашиваю, потому что на практически всех тестах производительности сайтов (GTmetrix, Lighthouse, WebpageTest и т. д.), без включенных плагинов, с темой по умолчанию и т. д., всегда сообщается, что общее время блокировки (Total Blocking Time) составляет 2–15 секунд из-за скриптов JavaScript…
Пример:
1 лайк
Само обновление, как ожидается, не повлияет на производительность. Однако оно открывает возможности для использования техник, которые позволят нам в будущем уменьшить размер JS-нагрузки (и тем самым улучшить начальную скорость загрузки).
Один из конкретных примеров — новые технологии сборки, доступные благодаря embroider. Теоретически эти методы позволят нам отложить загрузку JS-модулей, специфичных для маршрутов, до момента их фактического использования.
Мы уже начали применять этот подход для Wizard, что означает, что другие страницы больше не должны нести нагрузку от всего этого кода. В будущем мы планируем расширить это на другие части приложения, но нам необходимо очень внимательно относиться к совместимости тем и плагинов.
6 лайков
Насколько далеко в будущем мы говорим? Спасибо за ответ! Да, я пока что доволен программным обеспечением Discourse как относительно новый пользователь. Моя главная претензия связана именно с оптимизацией JavaScript-кода, так как, судя по моим наблюдениям, это основная причина задержек при загрузке.
1 лайк
Мы постоянно инвестируем в улучшение производительности, поэтому, думаю, никогда не наступит момента, когда это будет «завершено».
Что касается метрик, которыми вы поделились, важно отметить, что они отражают только первый визит на сообщество. Переходы по сайту и повторные визиты в будущем будут значительно быстрее!
5 лайков
Если критично время первой загрузки, используйте вместо этого платформу вроде этой для создания блога:
… которая работает со скоростью молнии.
Если вам нужно чрезвычайно функциональное приложение для форума, оставайтесь на Discourse.
Эта статистика часто упоминается здесь, в том числе совсем недавно.
Оценивать только по времени первой загрузки неразумно, так как при первом посещении загружается значительная часть приложения (похоже на приложения из магазина приложений, но не совсем то же самое), а затем она кэшируется для:
- переходов между маршрутами (не страницами, это приложение!)
- изменения, например, фильтров
Вы заметите, насколько невероятно быстро Discourse реагирует при навигации.
Это происходит потому, что ему не нужно загружать каждую страницу заново — он просто получает сырые данные из API.
3 лайка
Но именно так поступает Google, так что нам придётся с этим смириться.
2 лайка
Надеюсь, они скоро начнут включать «мягкие переходы» в Core Web Vitals 
11 лайков