I might be misunderstanding you but Angular behaviour isn't defined in markup. The views are, as well they should be, but they're just representations of the model behind the scenes.
This just does not jive with me. My template knows that submission should be handled by `addTodo()`? Or even worse, looping. I want all of my logic to live in code, not some abstract framework specific attributes that don't add much in the way of clarity (context switching between template and view just to follow the workflow, for example).
I use (and love) Backbone because the DOM is considered a pure presentation layer, nothing else. Any behavior, logic, whatever that the code controls is defined only in the code.
>My template knows that submission should be handled by `addTodo()`? Or even worse, looping.
Most template engines support loops. Would be very weird without that capability, really.
Also, you have to add hooks to buttons and the like somehow. There isn't much of a difference between adding a class like "js-addWhatever" or using Angular's in-your-face approach.
you have to add visual styles somehow too. you might as well add them right in the html attributes, along with the <font> tags and <center> tags. We'll have js-addToDo and class="white big helvetica" and call it a day.
The best thing you can do is to connect those parts by one semi-generic identifier. There is no actual difference between using a class, an id, a data-attribute, or a ng-* attribute as hook. If you want to rename it, you have to rename it. If you want to move things around, you have to move them around. There is no way around it.
Your template will also use names of properties, arrays, and objects directly. There also isn't a way around that.
At some point you have to connect your pieces. They can't float around in mid-air forever.
The presentational things you mentioned are different. We can separate those things more, we can use abstractions, and we can make it extremely reusable.
I think you missed my point. Unless you really think there's no difference between naming an html element, and giving it an inline named function handler.
There is no difference. There is one identifier which ties them together. If you change that identifier on one side, but not the other, it will stop working.
It doesn't matter if that identifier is a class or something else.
Well, if it's a class people may feel inclined to reuse that identifier on the CSS side, which is a bad thing, because now you've tied 3 parts together instead of just 2. If I use classes for this, I prefix them with "js-" to indicate that they are only meant for scripting purposes.
with performAcceptanceRoutine(), that cooresponds to an actual global javascript function that must exist, and specifies how (imperative) not what (declarative).
With a class "acceptButton" you are specifying what it is, semantically and declaratively, without reference to some specific procedure that will be carried out, if anything will be done at all. This frees up to a great degree the range of code that you can write to "activate" This html, and also, makes it so that the HTML is not bound to some specific code base, and it can be parsed in situations that explicitly ban javascript.
To each his own. I don't think it's that big of a deal either way.
You don't actually have to do it that way in angular if you don't want to. You can put it all in code instead. The framework specific attributes you're looking at aren't exactly framework specific, they're kinda application specific (just happens they ship with the framework).
You can write your own ones to move any of that stuff into code instead of markup. I personally think that loops should be in markup - I happen to prefer templating systems with less restrictions.
