Its called declarative user interfaces. Angular is not yet another technology if you've programmed in Silverlight or WPF.

Its one of the standard ways of developing WINDOWS applications. One example of declarative UI is HTML and CSS. You never write any "HOW TO LOGIC" when you are "printing" buttons, textboxs etc. on browsers. You just say <button> and there you go, you've a button there. You say <button class="red"> and lo and behold your button turns red. In that way you don't care "how" to print UI elements, you just focus WHAT YOU WANT TO DO rather HOW YOU WILL DO IT.

Declarative UI makes overall application highly testable and maintainable. You don't think how to "print" things on screen (write tons of binding code). Writing tests for the UI specific code is not only hard but messy. Without strong test-ability you can't scale your app without pains.

There is a reason why Google adopted this approach because world has learned the "best way" for building UIs. Google has probably half a decade of experience of building Google Web Toolkit. Right now Google Web Toolkit GWT has lot of similar concepts to AngularJS. Microsoft has probably 20 years experience of building UI framworks. Right now WP8 and WPF are all declarative UIs. In near future you'll see almost every UI framework across all devices technology will employ more or less the same concepts as AngularJS has now.

AngularJS is solving the testability & maintainability problem of large scale Javascript apps.

Few problems with your argument.

1) The first example is a template/view. It is reactively updated automatically when the values referenced are updated. It maps to markup on the page. The second example is a basic control structure that does nothing.

2)

    <span ng-bind="foo == bar ? '...' : '...'"></span>

You mean like literally every other template language for the web?

Not sure why this is being downvoted. The fact that people keep creating template languages like this doesn't mean they're an elegant solution.

The same thing everyone else is trying to solve - connecting data to display and keeping the two synchronized in the browser environment.

Which is a hard and important problem; nothing trivial.

If you're not sure what problem it's trying to solve perhaps you should forgo commenting upon it.

I work as a javascript programmer, so I'm trying to do my small part to stem the tide of crapware before it makes my job less pleasant (too late in the case of angular).

I feel that as a js programmer you probably owe it to yourself to understand this space better. These frameworks are coming in fast because they're very powerful - and they're here to stay. Looking at your example definitely feels like you don't really understand how to use angular. Obviously it's your choice to make, but calling it crapware without really getting it, when it's going to directly effect your job is doing an injustice to nobody but yourself.

It's posts like yours that caused me to originally dismiss Angular out of hand and waste time with other frameworks until I came back around and took a better look at it.

Please reconsider whatever it is you think you're doing, it's seriously not helping anyone.

How can you judge it with so little understanding of the subject matter?

It's better because you get nice stuff like two way binding which your js won't give you. Also, building templates in html is definitely nicer and more expressive than doing it in js. That specific example doesn't look great - but it's probably not the best way of doing it either.

On the performance - it's going to be slower than doing everything in specifically optimised code, but it's almost certainly not going to be a problem. My project has a million+ objects in js once the interface loads and I have watches on a big chunk of that data and the interface is still snappy. Granted, there are bits where I have to be careful to make it snappy, but that's life. Development time is so much faster I wouldn't make the tradeoff for the world now.

He didn't mention other frameworks - but how JS doesn't give you two-way bindings. Which it doesn't. Your second point is about Handlebars, which isn't even mentioned in the comment you replied to.

My parent suggests two way binding requires manually annotating the DOM, implying that it's an Angular-exclusive feature.

Furthermore, those who don't like annotation aren't writing JavaScript views, they're writing HTML templates and annotating them with some JS, which means the parent offers a false dichotomy.

Incorrect. I was saying that the joke example presented didn't in anyway show the difference in power that Angular gives you over raw js - nothing at all about Angular exclusivity.

Word. I think we can all agree that EVERY framework is far better than plain old JS; the comparison is so nonsensical to me that I assumed you couldn't possibly be making it. Seems good!

No, that wasn't implied. He's just saying that's what it's there for in this example.

I guess we just read it differently, then.

We did, and he just corrected you, so there's that.

This is a bad example. Why do that when you could just bind directly:

  <span>{{ someValue }}</span>

And in the controller JS file do

  switch (foo) {
    case 'bar':
      scope.someValue = 'hello';
      break;
    ...

I feel like despite its dirty checking, it ends up being faster than most ember/backbone apps.

The only reason to ng-switch/ng-switch-when is because you have to bind to DOM nodes (Angular decided they do the views this way) and you can't have DOM subtrees (those `{ ... }` branches in your `if ... else ...`) without elements.

I take it you haven't worked with angular that much. You can put as much code in your controllers as you like if you don't like decorating your views like in your example.

Huh?