Wir haben in unserem Startup Ember CLI eingeführt, und einer der Gründe war, dass wir sahen, wie es in Discourse verwendet wurde (was unsere Aufmerksamkeit darauf gelenkt hat). Wir haben es getestet, der Einstieg war einfach und die Arbeit damit ebenfalls. Aber es war so aufgebläht (abgesehen von anderen Gründen).
Ember CLI hat ein kürzlich veröffentlichtes Update eingeführt, das jede App, die in Versionen vor 3 geschrieben wurde, neu geschrieben werden müsste. Genau damals haben wir beschlossen, es komplett loszuwerden.
Ja, Ember CLI unterstützt Lazy Loading, aber es ist überhaupt nicht effizient (zumindest nicht bei unseren Tests), und die meisten Bibliotheken, die für Ember CLI entwickelt wurden, waren entweder veraltet oder so fehlerhaft, dass wir die meisten Dinge selbst schreiben oder alte Repos klonen und selbst warten mussten.
Ember CLI hat ohnehin immer eine schlechte Renderzeit (was auch nicht hilft, das hier diskutierte LCP-Problem zu lösen).
Abgesehen davon führt die Art und Weise, wie Ember funktioniert, leicht zu aufgeblähten Apps.
Ich wünschte, ich hätte noch die alten Analysedaten, die wir vor der Entscheidung, das Schiff zu verlassen, erstellt hatten. Wir sind vor einigen Monaten von Ember zu Vue migriert und kann mit der Performance unserer Apps und der Entwicklungsgeschwindigkeit nicht zufriedener sein.
PS: Ich hatte bisher keine Gelegenheit, das Discourse-Repo zu prüfen, aber ein Upgrade auf Ember CLI könnte weitere Probleme mit sich bringen, da man später wieder auf Ember Octane upgraden müsste (das noch nicht einmal stabil ist) und eine völlig andere Syntax verwendet usw. Um es gelinde auszudrücken, ist das ein Chaos. Ich bin mir nicht sicher, ob die Argumente, die früher für die Wahl von Ember angeführt wurden, aktuell noch tragfähig sind, @Jeff.
Hoffentlich ergibt das Sinn.