Hey @digitaldominica - Ember 업그레이드와는 관련이 없지만, 새로운 관리자 사이드바의 알려진 문제입니다. 자세한 내용은 Introducing admin sidebar navigation - #37 by martin 확인하실 수 있습니다.
네, 확인했습니다. 감사합니다
2개의 좋아요
게시물이 기존 주제에 병합되었습니다: Slick Image Gallery
David, 다음 stable 릴리스가 Ember 5만 포함될 것이라고 안전하게 가정해도 될까요?
또한 다음 stable의 대략적인 타임라인에 대해 어떤 생각이 있으신가요?
5개의 좋아요
다음 안정 버전은 1월 30일에 출시될 예정이며, AFAIK(본인의 지식 범위 내) 그 일정에 맞춰 진행되고 있습니다.
Ember 5는 3.2 릴리스에서 기본적으로 사용될 것입니다. 플래그 뒤에 Ember 3가 여전히 사용 가능한지는 아직 결정되지 않았습니다. 가장 가능성은 높다고 보지만, 이것이 ‘지원되지 않는’ 구성임을 명확히 하도록 노력할 것입니다(예: 관리자 경고 등을 통해).
9개의 좋아요
감사합니다
예를 들어 고객에게 상황을 명확히 설명하는 데 매우 도움이 될 것입니다.
6개의 좋아요
오래된 게시물에 답글을 남기는 것이라 죄송합니다. 경고 배너는 간헐적으로 나타났다가 제가 원인을 파악하기도 전에 다시 사라졌습니다. 이제 몇 주 동안은 나타나지 않고 있습니다. 
3개의 좋아요
@xJack 님, 후속 조치해 주셔서 감사합니다. Ember 업그레이드가 이미 몇 주 전에 저희 호스팅 환경에 배포되었기 때문에, 이전에 경고받았던 문제가 이제 해결되었을 것으로 예상됩니다 
4개의 좋아요
이제 EMBER_VERSION 기능 플래그를 제거했습니다. 앞으로는 Ember 5만 사용할 수 있습니다.
이번 업그레이드 배포에 도움을 주신 모든 분들께 감사드립니다! 
16개의 좋아요
8개의 게시글이 새로운 주제로 분리되었습니다: Site broken due to ember 5 upgrade
질문: 이렇게 하면 JavaScript가 더 최적화되나요? 아니면 전혀 효과가 없나요? 모든 사이트 성능 테스트(GTmetrix, Lighthouse, WebpageTest 등)에서 플러그인 비활성화, 기본 테마 사용 등의 조건에서도 JavaScript 스크립트로 인해 총 차단 시간(Total Blocking Time)이 2~15초라고 항상 표시되기 때문에 질문드립니다.
예시:
1개의 좋아요
업그레이드 자체는 성능에 영향을 미치지 않을 것으로 예상됩니다. 다만, 이를 통해 향후 JS 페이로드 크기(따라서 초기 로드 성능)를 줄이는 데 활용할 수 있는 기법들이 가능해집니다.
구체적인 예로, embroider를 통해 가능해진 새로운 빌드 기술이 있습니다. 이론적으로 이러한 기법들을 사용하면 라우트별 JS 모듈을 실제로 필요할 때까지 로드하는 것을 지연시킬 수 있습니다.
우리는 이미 마법사(Wizard)에 대해 이를 적용하기 시작했으며, 이는 다른 페이지가 해당 코드의 부피를 부담하지 않아도 된다는 것을 의미합니다. 향후 애플리케이션의 더 많은 부분에 이를 확장할 계획이지만, 테마/플러그인 호환성에 대해 매우 신중해야 합니다.
6개의 좋아요
미래라고 하셨는데, 구체적으로 얼마나 먼 미래인가요? 답변해 주셔서 감사합니다! 저는 디스코urs 소프트웨어를 비교적 새로운 사용자로써 지금까지 꽤 마음에 들어 하고 있습니다. 다만, 제 주요 불만은 JS 관련 부분의 최적화인데, 로딩 시간 측면에서 제가 느낀 가장 큰 문제점이 바로 그것이기 때문입니다.
1개의 좋아요
성능 개선은 우리가 지속적으로 투자하고 있는 부분이라, 특정 날짜에 "완성"될 일은 없을 것 같습니다.
공유해 주신 지표와 관련하여, 해당 지표는 커뮤니티에 처음 방문했을 때의 상태만을 반영한다는 점을 참고해 주시면 좋겠습니다. 사이트를 둘러보거나 나중에 다시 방문하게 되면 훨씬 더 빠르게 느껴질 것입니다!
5개의 좋아요
첫 로딩 시간이 중요하다면, 블로그를 만들 때 이 플랫폼을 대신 사용하세요:
… 이 플랫폼은 번개처럼 빠릅니다.
매우 풍부한 기능의 포럼 앱을 원한다면 Discourse를 유지하세요.
이 통계는 여기에서, 심지어 최근에도 자주 언급되었습니다.
라우트(페이지가 아닙니다. 이건 앱이니까요!) 간 이동
예: 필터 변경
이러한 상황에서 앱의 상당 부분이 첫 방문 시 다운로드되고(앱 스토어의 앱과 유사하지만 완전히 같지는 않습니다) 이후 캐시되기 때문에, 단순히 첫 로딩 시간만으로 판단하는 것은 합리적이지 않습니다.
Discourse를 둘러보며 탐색할 때 얼마나 놀라울 정도로 빠르게 반응하는지 주목해 보세요.
그것은 각 페이지를 다시 로드할 필요가 없으며, API에서 원본 콘텐츠만 로드하기 때문입니다.
3개의 좋아요
하지만 구글이 그렇게 하므로, 우리는 이를 받아들여야 합니다.
2개의 좋아요
곧 코어 웹 바이탈(Core Web Vitals)에 '소프트 내비게이션(soft navigations)'도 포함되기 시작하길 바랍니다. 
11개의 좋아요