It can’t be understated that all performance issues are about tradeoffs . I think Ember does the right thing here and focuses on apps that are organized and scale up as you add more features. For the vast majority of views in your application, the framework overhead will not concern you. However, if you are rendering many nested components with many bindings, the situation can become pathological.
While Discourse might look simple on the surface, each post is rendered with quite a few components. We have many dynamic buttons, links and effects applied every time a post is rendered with over 150 attributes involved.
I saw this in the blogpost that @eviltrout wrote. It seems like Ember performance is no problem in general, but just in the specific case of discourse topics, right? Discourse topics are a very long list of components(posts) that have lots of components inside them (reply button, like button etc). This is what leads to render performance degradation.
vdom/widgets alleviate this issue somewhat, because it makes the render process less expensive. But at some point the amount of DOM elements becomes so large, that they need to be reduced by cloaking them.
Recycling components means avoiding this problem all together, by only having a fixed number of DOM elements on the screen, that get repurposed as the user scrolls across the content.
Please correct me if I mischaracterized anything.
Thanks,
Spirobel ![]()