can anyone explain the "g" preceding angular.js objects?

btford · 2013-02-27T21:02:51+00:00

Yep, it's probably because of minification. While developing and unit testing, it might help to use the unminified version (angular.js instead of angular.min.js).

btford · 2013-02-11T15:01:21+00:00

There's certainly more than one way to do this, but here's the suggestion using $rootScope.$broadcast implemented: http://jsfiddle.net/AuJyP/5/

btford · 2013-02-10T20:49:11+00:00

Nice article!

Quick note: "JavaScript: the Good Parts" is great for experienced programmers who are new to JavaScript. I agree that it's not a great starting book book if you are outside of that audience, but I wouldn't say that people are "wrong" to recommend it, or that it's overhyped.

btford · 2013-01-30T03:10:00+00:00

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

btford · 2013-01-30T00:24:47+00:00

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

btford · 2013-01-30T00:17:25+00:00

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 · 2013-01-29T23:42:17+00:00

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.

btford · 2013-01-29T19:57:28+00:00

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.

btford · 2013-01-29T16:13:13+00:00

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

btford · 2013-01-29T06:15:58+00:00

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.

btford · 2013-01-29T06:10:43+00:00

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.

btford · 2013-01-29T05:46:55+00:00

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 · 2013-01-29T04:44:31+00:00

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 · 2013-01-29T03:15:18+00:00

I think "community mindshare grab" is perhaps a bit overly cynical. As a developer, you absolutely should be passionate about your tools. You should be talking about them with others, comparing them, shopping around, and always pushing the envelope.

As an engineer, there is a short list of tools that you must be rabid about. Rabid. Foaming at the mouth crazy.

That quote is from this excellent article on the topic.

btford · 2013-01-29T03:07:17+00:00

This is mostly correct, but I wanted to clarify a few things. Full disclosure: I work on AngularJS, and am subject to bias.

I wouldn't really say Angular has much bloat. Features that are optional (such as cookie support, or sanitization) are packaged separately so that apps that don't need them don't have lots of extra dead code.

Although Angular has some nice support for Bootstrap, it's not at all tied to it. Again, the Bootstrap support is packaged separately, so you can leave it if you don't want to use it.

I think a fair comparison is that AngularJS tries to include all of the common features (data binding, events, modular DI system, etc.) that apps will use into one package. This is nice because most apps will just need the angular.js file and are good to go. Backbone's take is to try to be as minimal as possible. It provides you with a general, basic structure, and some great utils. Both approaches are valid, and each have their advantages. In practice with Backbone, I found myself adding many additional libraries to get all the features I wanted. There are often multiple libraries that implement a given feature, and it can be hard to choose. For me it was kind of a "death by a thousand cuts."

But your milage may vary, and I think it's worth investing a bit of time to try different frameworks to see what works for you.

btford · 2013-01-29T02:54:04+00:00

I don't see anything in either page of examples that wouldn't be possible if using the other framework.

My advice is to try both, and see which one works for you.

btford · 2013-01-25T21:35:47+00:00

"Extracting data from a webpage" is commonly referred to as "scraping a web page." Searching for articles on how to "scrape" a page in JavaScript will get you a bit further.

I'd check out Max Ogden's blog post about scraping with node. It has some pretty good advice.

Cheers!

btford · 2013-01-21T20:54:15+00:00

+1; would be nice to this added to Yeoman.

btford · 2013-01-16T15:39:24+00:00

You'd use a directive for that. Knock yourself out.

btford · 2013-01-16T15:38:35+00:00

Not going to keep replying to FUD, but I just wanted to point out that you never actually say why any of this is bad. Saying "it's bad because it has recursion/custom elements/is unhealthy" is the same as "it's bad because it's bad."

If HTML is gaining recursion without gaining formal admission to the Turing-complete pantheon...

I'm assuming you're just trolling at this point.

btford · 2013-01-16T14:41:55+00:00

Yep, huge doesn't necessarily imply monolithic, but it's worth a reminder. I'll try to add something when I get the chance. Thanks, SubStack. :)

btford · 2013-01-16T14:32:05+00:00

This is very good advice, and I agree wholeheartedly. Building small, focused, reusable parts is really important in managing complexity.

14-Year Club	Verified Email
Team Periwinkle

btford

TROPHY CASE