3 ms·

>building virtual DOM nodes for static areas of your markup that will never change for every change requires many more allocations and increases GC pressure. I

>building virtual DOM nodes for static areas of your markup that will never change for every change requires many more allocations and increases GC pressure. I'm not familiar with Ember, but why not just store the constant value in a variable to solve this problem? For example, in MithrilJS, you write templates in plain JavaScript, so I just stash large, static parts of the tree in variables and only rebuild vdom nodes for dynamic content. Simple.

colinramsay 12y ago
You appear to have been downvoted; while I don't know whether your potential solution is right or wrong your downvoters should have been polite enough to explain their reasoning.
- mixonic 12y ago
  I am confused what is being suggested. > virtual DOM nodes for static areas of your markup refers to React's virtual DOM implementation, not Ember's. > I'm not familiar with Ember, but why not just store the constant value in a variable to solve this problem? Ember is a complex framework. Suggesting a "solution" to challenges with an acknowledged lack of context, and adding "Simple", shows fairly poor attitude. > I just stash large, static parts of the tree in variables and only rebuild vdom nodes for dynamic content This sounds pretty much like what is already described in the PR. Again, still confused, and still don't know what is being suggested.
- tessierashpool 12y ago
  I hope someone makes you an admin! yesterday, I got downvoted repeatedly for mentioning that I hadn't seen an IIS header in years. ¯\_(ツ)_/¯
simplify 12y ago
Could you provide an example?
Cakez0r 12y ago
I believe they're saying that a virtual DOM is created and updates that would cause a re-render are first applied to the virtual DOM (thus avoiding the over head of a render). The virtual and actual DOM are then compared to see which parts have changed and need to be re-rendered, which results in a net saving of CPU time. There is no constant value to store here. Perhaps you are referring to the templates, which are static and are already stored in memory?

colinramsay 12y ago

You appear to have been downvoted; while I don't know whether your potential solution is right or wrong your downvoters should have been polite enough to explain their reasoning.

mixonic 12y ago
I am confused what is being suggested. > virtual DOM nodes for static areas of your markup refers to React's virtual DOM implementation, not Ember's. > I'm not familiar with Ember, but why not just store the constant value in a variable to solve this problem? Ember is a complex framework. Suggesting a "solution" to challenges with an acknowledged lack of context, and adding "Simple", shows fairly poor attitude. > I just stash large, static parts of the tree in variables and only rebuild vdom nodes for dynamic content This sounds pretty much like what is already described in the PR. Again, still confused, and still don't know what is being suggested.
tessierashpool 12y ago
I hope someone makes you an admin! yesterday, I got downvoted repeatedly for mentioning that I hadn't seen an IIS header in years. ¯\_(ツ)_/¯

simplify 12y ago

Could you provide an example?

Cakez0r 12y ago

I believe they're saying that a virtual DOM is created and updates that would cause a re-render are first applied to the virtual DOM (thus avoiding the over head of a render). The virtual and actual DOM are then compared to see which parts have changed and need to be re-rendered, which results in a net saving of CPU time. There is no constant value to store here. Perhaps you are referring to the templates, which are static and are already stored in memory?