search

toddmotto / angularjs-styleguide

AngularJS styleguide for teams
https://ultimateangular.com
5.96k stars 700 forks source link

ng-bind vs curly brackets #41

Closed radek-anuszewski closed 8 years ago

radek-anuszewski commented 9 years ago

Hi everybody!

I read this guide and try to follow advices contained here, but today I faced problem with curly brackets, because I had JS imports in <footer> element at bottom of page - I had to move it to <head> section and use ng-cloak on body (which isn't adviced... But works :smile: ). Then I found ngBind directive, which completely removes this problem. As I googled, it is also faster than {{}} but some people are complaining that it created unnecessary boxing with <span ng-bind="something"></span> and isn't as clear as curly brackets syntax (maybe it's only old habit?). I am curious of your opinion - maybe it's worth mentioning in @toddmotto's / @johnpapa's styleguides?

toddmotto commented 9 years ago

I use ng-bind over {{ foo }}, will add this to the styleguide :)

Leave this issue open and I'll get it added + close it.

mackelito commented 9 years ago

Are there any specific use case for when to use {{}} and when to use ng-bind? Would love to understand when to use what! ;)

m5kr1pka commented 9 years ago

Probably, ng-bind is a good use case when you have a syntax conflict, like with laravels blade templates.

mackelito commented 9 years ago

I was thinking more in terms of performance. :)

toddmotto commented 9 years ago

I always use ng-bind, it's faster (http://ng-perf.com/2014/10/30/tip-4-ng-bind-is-faster-than-expression-bind-and-one-time-bind). Rarely use {{ foo }} syntax, if ever.

Also, Angular doesn't evaluate the entire surrounding of the expression (https://speakerdeck.com/toddmotto/angularjs-the-performance-parts?slide=57) - see final example here.

wardbell commented 9 years ago

IGOR MINAR SAYS: ng-bind is faster because it’s simpler. interpolation has to go through extra steps of verifying context, jsonification of values and more. that makes it slightly slower. having said that, in most cases the difference does not matter. use syntax that feels right for the given scenario and when you do run into perf issues, investigate where it’s coming from and then address only that hot code not everything.

... from [the same link you cite]((http://ng-perf.com/2014/10/30/tip-4-ng-bind-is-faster-than-expression-bind-and-one-time-bind).

Given Igor's authority, I'd be loathe to worry about this ... and I don't believe we should be recommending ng-bind. Such a recommendation encourages blind/premature optimization at the expense of productivity. That, IMO, is the evil to avoid.

mackelito commented 9 years ago

Now we're talking... these were the answers I was looking for! :+1: :) Thx for your answers @toddmotto and @wardbell

toddmotto commented 9 years ago

Can't say I agree that it would hinder productivity in any shape or form unless you can elaborate @wardbell ?

Sticking with one syntax IMO only makes it easier for a few reasons:

Benefits to ng-bind:

I don't think it's a "premature optimisation" to use a syntax that's more inline with every other ng-* binding that's also no extra effort required besides a few character presses. Arguably you could say the same for if you wanted to stick to only {{ foo }} syntax, but there will be places that ng-bind is the better option - so why not use it consistently is my reasoning for this.

Be sensible and stick with your conventions - but understand them to be able to make your own judgment :)

wardbell commented 9 years ago

Different stroke for different folks I guess.

I measure productivity in part by what contributes to ease of reading, writing, and maintenance.

9 out of 10 doctors agree that the following is easier to read and write

<div>{{hero.name}} is my hero!</div>

than

<div ng-bind="hero.name + ' is my hero!'"></div>

Certainly took me less time and fewer mistakes to write while in a moving vehicle driving to Thanksgiving dinner 😃

I can count on one hand the number of times that ng-bind felt preferable.

Nor have I once heard someone complain about the "inconsistency" of interpolation and ng-

But let's not fight. This isn't going to be a big deal one way or the other.We've made our points. Let's go out enjoy the day.

Peace out!

nazrhyn commented 8 years ago

As the guide recommends the use of one-time binding, where appropriate, is there a one-time version of ng-bind? I haven't seen one and a cursory glance didn't turn one up. If not, then that's a bit of a hole.

The Angular documentation for ngBind indicates a preference for the mustache syntax, but provides some caveats:

Typically, you don't use ngBind directly, but instead you use the double curly markup like {{ expression }} which is similar but less verbose.

It is preferable to use ngBind instead of {{ expression }} if a template is momentarily displayed by the browser in its raw state before Angular compiles it. Since ngBind is an element attribute, it makes the bindings invisible to the user while the page is loading.

Finally, @wardbell: I would be more likely to write your example as follows, which is, at least, somewhat more attractive:

<span ng-bind="ctrl.name"></span> is my hero!
toddmotto commented 8 years ago

Indeed you can. Just do something like:

ng-bind="::prop"

And you're good to go :)

@toddmotto

On 31 Dec 2015, at 23:04, Chris Harwood notifications@github.com wrote:

As the guide recommends the use of one-time binding, where appropriate, is there a one-time version of ng-bind? I haven't seen one and a cursory glance didn't turn one up. If not, then that's a bit of a hole.

The Angular documentation for ngBind indicates a preference for the mustache syntax, but provides some caveats:

Typically, you don't use ngBind directly, but instead you use the double curly markup like {{ expression }} which is similar but less verbose.

It is preferable to use ngBind instead of {{ expression }} if a template is momentarily displayed by the browser in its raw state before Angular compiles it. Since ngBind is an element attribute, it makes the bindings invisible to the user while the page is loading.

Finally, @wardbell: I would be more likely to write your example as follows, which is, at least, somewhat more attractive:

is my hero! — Reply to this email directly or view it on GitHub.

RickCarlino commented 8 years ago

Hey guys- is the performance argument still valid? This benchmark appears to show handlebars as 20% faster than bind.

Curious if something has changed in recent versions.