In the top example blurCallback references the current $scope object, which is a powerful feature of AngularJS that helps keep things modular. In the second you are referencing a global blurCallback function, which is definitely a bad idea.

If you're talking about the general idea of binding events in HTML, they are the same, but combined with Angular's design the choice has a lot of advantages. From the docs (http://docs.angularjs.org/guide/concepts):

"The separation of the controller and the view is important because:

1. The controller is written in JavaScript. JavaScript is imperative. Imperative is a good fit for specifying application behavior. The controller should not contain any rendering information (DOM references or HTML fragments).

2. The view template is written in HTML. HTML is declarative. Declarative is a good fit for specifying UI. The View should not contain any behavior.

3. Since the controller is unaware of the view, there could be many views for the same controller. This is important for re-skinning, device specific views (i.e. mobile vs desktop), and testability."

I'm not so sure; I have to agree with heme. "ui-keypress="{13:'keypressCallback($event)'}" seems a whole lot like the UI is specifying behavior (on key 13, call a function called keypressCallback). This is no different than [pseudocode] "onkeydown='if(e.key==13){ keypressCallback(e) }" with a slightly cleaner syntax, except that you're calling it on an arbitrary this instead of the window. It's just as dirty. The event bindings belong in the js, not the html.

In my brief experience with Angular the difference is that while you can do "ui-keypress="{13:'keypressCallback($event)'}" that is more of the lazy way of doing things. The benefit of using the View and the way it should be used is in a declarative form such that someone looking at the View can know immediately that some element has some interactive behavior attached to it, but the proper way is to abstract it via a directive so that you don't pollute your view with the imperative details.

So, instead of using

<input "ui-keypress="{13:'keypressCallback($event)'}">

where keypressCallback does a form submit or something, you would write a directive that is just "form-submitter" and you would have your DOM be

<input form-submitter >

So that way you can easily scan your view to see what elements have what behaviors, but not how.

And Angular also allows you to bind events within javascript and really that is what the "form-submitter" directive in this example would be doing as well, but it should not be happening in general within the view/dom.

Although many times it is too heavy weight to make a directive for everything, but that is where the scope concepts of Angular comes in as well as the controllers so that at least the functions that are being triggered are still more expressive as they are localized to the containing scope. So, for instance you could have a directive "my-form" which is just an enhancement of the standard html form. In my directive I can then define a "validate()" method which validates the inputs. So, instead of having a "form-validator" directive I can instead do:

<my-form> <input type="text" >

  <button ng-click="validate()"/>

</my-form>

Because of the scoping rules of Angular it is generally easier to infer the behavior of the method that is being called as it is scoped to my-form and as long as you are playing by the best practices there is not any real concern for functionality within that method to leak outside of "my-form" thus maintaining the ability to look at the DOM and have a pretty good idea of what the application is doing without digging through javascript as well.

That makes more sense. I disagree with the general principle of defining javascript actions by using properties like "form-submitter" or "validate()". I think that there is more than enough room in html5 to define an entire application without writing attributes specifically for binding, but that's the point of Angular- being able to easily bind to a view, which you can't do easily otherwise.

Thanks for the explanation! That helped shed some light.

It's not better. But Angular tries not to step on your toes by starting to interpret onblur attributes differently from how they are defined by standards (as other's have said, blurCallback resolves to different things in your examples).

As I understand, Angular is its team's vision on how browsers will natively support client-side apps in the future, in which case there will probably be a more streamlined syntax for such things.