If your grid needs to display data a different way than what is given, isn't that a view thing not a data thing?

Well, standard aside, my question really comes down to performance? Rearrange the data a dozen different ways in the store and use a templatecolumn or have the minimum neccessary fields in the store and use a rendered on the column which call a function to arrange data for you and apply it to a tpl?

Best performance is to get the data exactly how you want from the server. After that it's best to do it in the model. Lastly the view.

Just depends on what you are going to be doing with the data as there isn't a silver bullet to work with all use cases. For example, say you have 15 views using the same store (yes, I've done it and more for enterprise needs) but not all of them may display; maybe 7 of them get displayed for a particular user session, the other 8 aren't used very much. Are you going to bloat your data to fit all 15 views or should each view handle itself. If you used a convert function and added extra fields to the model then you have a large up-front performance hit where as if you did it in the views it would be smaller performance hits as the application is used. Sure the smaller hits may add up to more than the up-front hit but since it's spread out over the application usage it isn't felt by the user as much as the up-front hit is.

Regarding card/tab layout optimizations by deleting invisible nodes

mitchellsimoens originally offered up the concept of removing tabs or cards that were not visible.

Our team is interested in this concept, as we are in the process of moving from a "desktop" layout with individual windows to one that uses a card layout to swap between the views. To make for a better UX, we are considering not forcing the user to "close" the cards they aren't looking at, so they can just focus on the task at hand rather than managing a slew of windows/cards/tabs/whatever. This could potentially mean a big memory footprint, but in testing it seems to be well within the thresholds we can handle. The real problem is the hugely cluttered DOM, which is now full of hidden elements, and I imagine the event listeners that are polling with no results (though I'm not as familiar with those types of optimizations so I could just be stretching there).

When you mention "deleting" the views not visible, are you talking about creating an override or modification to the card layout that removes the dom nodes and caches them somewhere for re-entry? If so, how can you re-add event listeners and cache references/etc after an Ext.removeNode has occurred? Or are you more specifically saying that you completely delete everything and force a re-load if they re-visit those tabs/cards later? Or are you talking about something completely different? Can we see a code example?

I'm new to EXT JS, but having done years of embedded systems development. Always, the rule of thumb for increased performance was never copy data (e.g. never move it from point to point, or reformat it in anyway). In looking over the various comments here, that seems to be the jest of many comments.

A second group of comments seems to be don't use certain EXTJS functions over other EXTJS functions. I wonder if this just boil down to two main points: