Performances using plugin like ember-truth-helpers instead of just the Ember default way

Performance
1

If I use this plugin: https://github.com/jmurphyau/ember-truth-helpers

with many, let’s say,

{{#if (eq model.beautiful true) }}

or

{{#if (or (eq model.beautiful true) (eq model.crazy true) ) }}

what is Ember creating in background? The same javascript works of computedProperties like these:

isBeautiful: Ember.computed.equal('model.beautiful', true); and so on?

If I have 30 computedProperty (Ember macros and custom ones) it’s better to use this plugin or the default Ember way?

I’m wondering because in some templates I can have something like this many many times!:

{{#if (or (eq model.beautiful true) (eq model.crazy true) ) }}

instead of just this one:

{{#if isBeautifulOrCrazy }}

What is the best solution in terms of performances?

2

In our experience I think CPs would be the fastest for something like this. Pre-glimmer2 we had tables that had tons of components and helpers (and AFAIK components and helpers are more or less the same thing to the engine) and we ended up switching most of them to CPs and that helped our performance a lot.

Granted, that experiment and refactor was before Glimmer 2 so it’s probably less a factor than it used to be. The best way would probably just be to make a fiddle or a test app and play around with render times.

Really, you’re just balancing your performance requirements against your maintainability and code aesthetic requirements. If you think the value of ember truth helpers outweighs any performance hits (I usually do think that unless performance is a significant problem) then stick with the helpers. If you find a huge difference in render times between the two maybe refactoring to CPs is worthwhile.