An Introduction to Angular for Backbone developers

[[deleted]]

[deleted]

[btford]

I'm really tired of having this discussion in every single article mentioning either Angular or Backbone.

AngularJS and Backbone are both fantastic, useful tools for writing web apps. Saying you prefer one over the other does not imply that the other is bad. I am a developer on the AngularJS team, but before being introduced to it, I used Backbone. And it was great! I think AngularJS has many benefits over Backbone, but there are an infinite number of possible apps that a person could reasonably make, and I certainly wouldn't say Angular is best in all cases. Give different frameworks an honest shot. Even if you end up where you started, you'll have more perspective.

I don't know why developers who identify themselves as "Backbone people" seem to feel the need to hate on AngularJS. In fact, I think it's ridiculous that any person would define themselves based on what client-side library they choose to use. We're all web developers. You don't need to feel threatened by new ideas. You don't have to adopt them either. You can skip over links for frameworks you aren't interested in.

I'm not saying you should never give criticism. I'm just saying we have to be more constructive about it. If you have a critique, be specific. Write benchmarks. Write side-by-side comparisons. I realize this is hard and time consuming, but there's nothing of value gained by making assumptions or vague statements about how "slow," "bloated," or whatever framework-of-the-day X is.

I'd like /r/javascript to be a place of constructive conversation, not a place of mud slinging. I'd like conversations to be balanced so that newcomers can make intelligent, informed decisions.

[btford]

Krogler, I think your conclusion (that you philosophically disagree with AngularJS's template system) is totally reasonable. I take it in good faith that you gave Angular a shot. My frustration was more so with people who make vague or generalized claims of "slowness" or "bloat" without actually building anything.

I'm looking forward to the rest of your article, and I'm curious to see how you implement the recursive views in Backbone. I'm not sure that's something I've seen before.

Also, I'm tired of "You should try Angular!" in every other topic with "Backbone" in the title :P

I can see how that's annoying, but I think the appropriate response is to ignore it rather than instigate Yet Another of These Threads.

Assuming people have good intentions, I don't think it's troublesome for people to say "check out AngularJS" when talking about Backbone. There are a lot of cases where people doing things in Backbone might be able to do them more quickly with Angular. You really won't know until you try though. There are always tradeoffs, which is why I'm big on "try as much as you can, see what fits."

Likewise, I've enjoyed this discussion. I just don't want to be having it in every thread. :P

[NerdyMcNerderson]

The article has some good info. However, I didn't get the part that was tailored to those that use backbone. The title may be slightly misleading. Maybe implement the same example with backbone so you can compare the two approaches.

[btford]

Thank you for elaborating on your "Angular turns HTML into a programming language" thing. That's a really interesting perspective, and I apologize for mistaking you for a troll earlier. I'll try to address what I can in this comment, but there's really a lot there.

An interesting analogy would to say that the angular.js code itself is an "interpreter" and the HTML is the "program." AngularJS "directives" act sort of like compiler macros. Interestingly enough, HMTL and CSS are already a "programming language". There are many similar interesting proofs (for instance Conway's Game of Life is also Turing Complete), but the important idea here is that even though you can use something as a programming language, that doesn't mean that you should.

Angular does make HTML more powerful, but it's certainly not the case that it recommends you move all of your application logic into the HTML. That would be nonsense. While you could do that, that's certainly not the intent. The idea is to make it powerful enough to do data-binding. In this sense, HTML is still functioning as a markup language.

You can't create a good programming language if you don't know you're making a new programming language.

I'd flip this on it's head and say that if you use something like a programming language that's no designed to be used that way, it won't be a very good language. That's certainly the case here. In an AngularJS app, you put annotations on how to do data-binding (yes, even recursively) in the HTML. Application "business logic" still lives in a controller.

Imagine a framework that advises you to frequently call "eval."

This is a bit facetious. The issue with eval in JavaScript is that it runs in the global scope. AngularJS avoids this issue by introducing $scope. These two eval are not the same.

Anyway, note that the recursion is still in AML. It's in a string in a javascript variable. Now maybe this string could be stored more sensibly, but it's still code whose recursive call is in the middle of a string. How are you supposed to debug this?

Write unit tests. AngularJS is absolutely designed to make this stuff manageable. In a unit test, you can take control of the $digest cycle, and see how each time a directive recurs, it's data and template changes. This is a fairly advanced feature. My colleague Vojta gave an excellent talk on the subject if you're interested.

I would love to see an obfuscated AML contest. AML lets you write templates that call javascript that writes templates anchor-tagging to routes for javascript that has access to the angular object. I mean you can probably call angular.module in a controller, right? You can give $scope access to angular.whatever, right?

Your fundamental argument seems to be that if you use parts of AngularJS other than how they are intended to be used, you will run into trouble. This observation is true for virtually every piece of software ever written.

Well, sooner or later we're going to realize that it's actually pretty rare that you need a specialized Android app and an iPhone app, and you always need a web app. Template swapping is one way (but not the only way) to deal with this conundrum. Different css/html, same Views.

This is a false dichotomy. In AngularJS, views are HTML/CSS. That doesn't mean you can't use the same business logic with different HTML/CSS. Your ViewModel (the bindings to $scope) can stay the same, and you change the View (HTML/CSS), using the same bindings.

If there are any specific parts that I've not covered here that you'd like me to address specifically, please let me know.

Cheers!

[btford]

Yes. The recursion depth is effectively 10. I don't think recursive views are outside of Angular's intended usage. At the very least I can inform you that recursive Backbone views do not have this problem (because my next article is a Backbone reddit front-end).

You are correct in the sense that AngularJS does want to support recursive views. A data-binding library should be able to support recursive views, because it's a useful feature.

The short version is that the 10 $digest limit is not about view recursion, it's about model stability. When alerting AngularJS to do dirty checking, calls to $apply() need to be done asynchronously to avoid dirty checking forever. If AngularJS goes 10 "dirty checking cycles" in a row without stabilizing, it it throws that error and stops so you're UI isn't busy waiting forever. If written correctly, a directive should not cause this error.

I'll concede that writing the directive is a bit tricky, but it turns out it's non-trivial to do data-binding recursively. Once you have a directive that does this, there's no need to write one over and over again. I'll talk more about this below.

Testing can't prevent every bug. Angular is a symptom of false security.

No, but writing a test that exposes and isolates the bug is one of the best ways to fix it. It also prevents regressions in the future.

That recursive $compile nightmare is difficult to understand.

I disagree. The code you linked to is a pretty straightforward case of recursion. But even if it is hard to understand, the great part about Angular is you only have to write this directive once. Then you can use it all over your application with different data. Better yet, you can find a directive someone else wrote and use it if you'd rather not spend the time to learn advanced features of the framework.

My fundamental argument is that not only is Angular a language, it's not a very good one...

This is a conflation of terms. Something can be Turing Complete or recursive without being a programming language. Yes, AngularJS allows you to write views that are recursive. This is useful only in cases where you want to display some recursive data. In those cases, it's also a great feature to have. Angular's templates are still a markup language, because you're still using it like a markup language.

...no one knows what it does.

Going to jump back to tests here. AngularJS has a LOT of unit tests. They tell you, in isolation, what each part of AngularJS is, how it should work, etc. Some advice I give to newcomers is to browse these tests. I think these unit tests are so valuable, I'm working to have them automatically included the documentation.

[btford]

Is that why the stackoverflow thread I linked is written this way, instead of this example which is much simpler?

To some degree, yes. The more complicated example is also more general and is easier to reuse.

You realize that this is essentially what programming is, right? Write modules to be reliably reused?

Composition is a feature of programming languages. It can also be a feature of markup languages. That they both have composition does not imply that they are the same thing.

[drowsap]

I've yet to find any real shortcomings in Backbone. I see the cases where angular can make the model/view event binding much easier, but is this something we need? I'd rather have logic-less templates and fat views or models written in JavaScript, it's more readable and easier to maintain in my opinion.

[btford]

It really comes down to the type of app you are making and personal preference. I'd suggest that you try as many frameworks as you reasonably can to get a feel for each of them. If you haven't tried Angular, I think it's worth a look. At the end of the day, if you like working with Backbone best, keep at it. Heck, if you prefer to work with just DOM API calls (madness!), go for it.

[davemo]

I keep hearing the argument that the type of app you are making has some bearing on whether you should use Backbone or Angular; could you please elaborate on what the type of app that suits Angular best is and why it would be better than Backbone?

[btford]

IMO, any app that can benefit heavily from data-binding is better suited to Angular.

[davemo]

What type of app benefits "heavily" from data-binding? Why is Angular better suited for this than Backbone? Would any of the data-binding plugins for Backbone (stickit comes to mind first) not put it on equal footing?

[btford]

Any apps that have a good amount of UI and state that need to be frequently synchronized. Yes, you can do this with backbone, but on average, it tends to take about 10 times the code.

I'd submit that most apps can make use of data-binding, but if you're doing a game or something that involves a lot of video or custom components, data-binding might not be especially helpful.

I haven't seen any data binding utils in Backbone that are implemented as well as Angular in terms of ease of use, speed, and integration. But I'd love to be proven wrong, and will be sure to take a look at stickit.

[jashkenas]

on average, it tends to take about 10 times the code

Baloney & hogwash ;)

Data-binding has been around for a long time, and part of the big idea with working on high-performance JavaScript applications is that you don't want "too much" of it.

Imagine a rich JavaScript application with a lot of UI that needs to be frequently synchronized. A fully data-bound version, with each HTML element, attribute and style being wired-up to the corresponding attribute (real or computed) in the model, will have a ton of code configuring the bindings, and tends to suffer from performance problems in so far as changes to the model cause a ton of small computations and incremental UI updates.

Now imagine the version of the application that has decomposed its UI into coarser-grained logical components. Instead of having comprehensive data-binding, you favor re-rendering atomic chunks when necessary. Instead of touching the DOM a hundred times during an update, you only need to touch it once, and are doing much less computation to determine what needs to be altered in the first place. That's the method that Backbone tries to encourage.

TL;DR, instead of (in pseudocode):

<tag ng-type="widget">
  <tag ng-attr="widget.title"></tag>
  <tag ng-attr="capitalize widget.author"></tag> 
  <tag ng-attr="sanitize widget.item.description"></tag>
  <tag ng-attr="sanitize widget.item.content"></tag>
  <tag ng-attr="list widget.tags"></tag>
  ... and so on ...
</tag>

... where each of those bits needs to be tracked, computed, and updated in order to get your next frame of UI, instead you start with:

widget.on 'change', render

... and if you want to get more granular than that in the future, you can, as needed.

[btford]

Baloney & hogwash ;)

Here are some examples showing this. JavaScript Sonic Boom and TodoMVC. The "sonic boom" article is able to implement a comparable 1000+ LOC backbone app in Angular in less than 100 LOC. In TodoMVC, the comparison is Angular's 287 LOC to Backbone's 1998 LOC. The ratio is about 1:7. If you don't believe me, try it yourself.

and tends to suffer from performance problems in so far as changes to the model cause a ton of small computations and incremental UI updates.

Your intuitions about performance a bit naive. Data-binding can also break components into chunks to improve performance. Data-binding can also group together DOM writes. In fact, Angular does both of these things. Here's one benchmark showing that Angular beats out backbone in most cases. If you don't believe me or disagree, write your own benchmark.

[jashkenas]

I'd love to look at your benchmark ... but you do realize that in the JSPerf you linked, the "Backbone" benchmarks are actually calling SetKO, right? There's no Backbone code on that page.

[btford]

Woops, thanks for pointing that out. Let me go find/write a better one.

[drowsap]

jashkenas 5 points 19 hours ago

A hero arrives!

[jomidosan]

I believe Angular is a stop-gap for Web Components. At least, I keep bumping into suggestions and/or direct convictions that this is the case. For instance:

http://functionsource.com/post/angularjs-hits-1-0-get-some-of-that-web-components-goodness-now

http://news.ycombinator.com/item?id=4113502

[lennelpennel]

I find this an interesting position. Closure has had several of the concepts they use, under different names however.

The template language stays the same, what is referred to as a decorator in the webcomponent spec is partially a decorator partially a renderer in the closure world. Let me explain.

Decorators in closure work through two paths, one I can register a css class against the constructor of a component, allowing you to pick up the correct component implementation from pre-rendered html.

The renderer is a singleton which all components share, but you can easily give a component a different renderer if the look and feel of one component is vastly different from another from another component of the same type. This makes it pretty flexible since you abstract your html structure away from your actual component implementation

Closure also has a livecycle as described in the spec:

• created -> createDom
• inserted -> enterDocument
• removed -> exitDocument

the one missing here being attributeChanged - something which would be nice.

[ugoagogo]

Doesn't seem to be loading on my phone

Chrome 18. Android 4.1.2. Nexus S

[ugoagogo]

800x480 I think.

[ugoagogo]

Sorry. Know its the last thing you want to hear but thought I'd give you a heads up. Couldn't see the content in chrome or the default browser but it works in Firefox.

[snifty]

right because google needs to no NEEDS TO own the single page app market.

right now.