We are currently porting backbone + jQuery spaghetti app to Ember/EmberCLI. We are making good progress, and really like the benefits that Ember is providing - the app is becoming much easier to reason about.
However, we have hit quite a serious performance bottleneck in one of our main views, probably related to this issue. We need to display a grid with ~30 columns and ~100 rows. Each individual cell has a very rich content, composed of multiple components, possibly containing additional nested components, {{each}} blocks, etc.
Only ~10 rows are visible in browser viewport simultaneously, so we only need to render ~ 30 X 10 = 300 cells initially; other cells are rendered on demand as user scrolls the grid. However even with lazy-rendering of rows, rendering is taking to long (e.g. ~1 sec for 300 cells on MB Pro), thus initial load and scrolling of grid is performing so badly that it is almost unusable. In this JsBin there is an example of individual cell component and a simple benchmark, demonstrating the perf issue.
We are considering the following work-arounds:
a) Simplify structure of cell component
We could probably simplify structure of individual cell, e.g. avoiding some {{#each}} or component calls, substituting them for e.g {{#if}} blocks.
I do not like this solution as it would make things harder to maintain. Also, components for cell would have to be designed according to perf-tests on specific Ember version - there is no guarantee that specific helpers used in one version of Ember will still be most/adequately performant in next versions.
b) Render HTMLBars template with no databinding
We are using components only to render templates, we do not need any data-binding functionality as data for each cell does is not changing after it is rendered. Also, we do not need Ember to handle any Events/Actions on cell components. However I am not sure how to render component-less/view-less templates with HTMLBars as it seems quite deeply integrated with Ember views/components.
Is it possible to do something like this in Ember/EmberCLI:
domOrString = HTMLBars.render('templateName', cellContext);
myTarget.append(domOrString);
where cellContext contains e.g. Ember.Object or ordinary js object?
c) Use Handlebars templates
Similar to b), however using pure Handlebars templates to render each cell. I have an impression that Handlebars templates are more easily used outside Ember context. I would like for templates to be precompiled on server, so this would require HTMLBars and Handlebars compiler in EmberCLI, not really nice and probably quite some work to configure properly?
d) Wait for issue to be solved in Ember
As we do not have strict deadline for the release of migrated app, we could just continue migrating other parts of the app and then return to this issue if still not fixed in Ember. In the mentioned issue there is not much info yet on whether this is something that will (maybe) be solved in near future. Should Glimmer rendering engine improve perf or this scenario also, or does it affect only re-rendering perf?
Thank you in advance for any suggestions/insights on the given issue!