The status of {{unbound}}

With the final release of a project approaching, I’m trying to optimize and improve the project for the production build. So I came across unbound:

My new car is {{unbound color}}

But after some research I found out that the unbound helper is… still there but deprecated in a way.

The unbound helper is mostly a legacy API in Ember, although it is not being removed in 2.0. It was almost exclusively used to manage performance issues which are well addressed in Ember 1.13’s new rendering engine.

But apparently it’s still being used by some big companies, as this lightning talk (from 2:40) suggests.

So does anyone know what the status of unbound is? Will it be deprecated for real in the future? Is there enough optimization to justify spending time on refactoring the project?

I too would be curious about this. At one point, we saw a great performance improvement by using unbound where possible. But in the past year or so I’ve heard a few people say it’s mostly negligible with the introduction of streams and glimmer.

In Glimmer v1 (Ember 1.13 through at least 2.8) {{unbound has much less impact than it did in Ember 1.0 through 1.12, but still does provide some improvement in certain circumstances.

This is still somewhat conjecture on my part (I’m certainly no rendering layer expert), but I believe that in Glimmer v2 (coming to an Ember version near you “soon”) even that small amount of improvement will be gone (since there is essentially no extra observation work setup for each bound property).

1 Like

@rwjblue That validates what I had suspected. Thank you!

Thank you for the clear answer. For now, I’ll ignore {{unboud}} and spend my time better. :slight_smile:

So we’ve upgraded our app to Glimmer 2. We have a lot of unbound helpers and we’re wondering if we should keep them or just go ahead and remove them. Any idea who might know about this for sure?

Hello there! Join to @workmanw request about how to deal with unbound helper in templates.

Here is ember-template-lint rule:

But I can’t find any example about: How to deprecate it. Is it playable to just remove this helper with no issues? Appreciate any help with clarifying this.

I think this bit implies that it is perfectly safe to just remove it so that’s what I would recommend as long as your code (for whatever reason) isn’t depending on only getting the initial value of a property and having it update would “break” it. I’ve only seen unbound used for performance reasons and in that case you should definitely be able to just remove it.

Thank you! @dknutsen. I got the passed build after removing it, but I was about to confirm that: just removing is a way here. Thanks, I owe you one.

I wouldn’t say it offers zero benefit. The helper works on the compiler level. The needed refs for dynamic bound properties are not there. Instead, it uses const refs like =“8”

The runtime benefit is probably minimal. But it does offer some benefit on memory usage.