Angular and Semantic Markup/Separation of Concerns

Question

Perhaps this isn't a good place to ask this, but I'll try to make it as objective and answerable as possible.

I've been playing with Angular.js and really liking it, but I have a question about its philosophy. Here's a snippet of code from the Angular site for a controller.

   <div ng-controller="TodoCtrl">
      <span>{{remaining()}} of {{todos.length}} remaining</span>
      [ <a href="" ng-click="archive()">archive</a> ]
      <ul class="unstyled">
        <li ng-repeat="todo in todos">
          <input type="checkbox" ng-model="todo.done">
          <span class="done-{{todo.done}}">{{todo.text}}</span>
        </li>
      </ul>
      <form ng-submit="addTodo()">
        <input type="text" ng-model="todoText"  size="30"
               placeholder="add new todo here">
        <input class="btn-primary" type="submit" value="add">
      </form>
    </div>

This is basically HTML with Angular directives sprinkled in. The one that I find potentially susupect is this: <a href="" ng-click="archive()">archive</a>.

When Jeffrey Zeldman wrote Designing With Web Standards, it became a best practice to separate markup (HTML), presentation (CSS), and interaction (JS) into different files for maintainability.

My question is, how does Angular not violate that? I'm actually really enjoying it, and finding it quite powerful, but what is the difference between binding a click event to an a element like that in the markup, and writing this vestige of pre-web-standards code:

<a href='#' onClick='showAlert()'>Click here</a>

<script>
    var showAlert = function(){
      alert('hey');
    }
</script>

Helpful answers might refer to documentation in addition to personal experience with using the framework.

Answer 1

I'll start with the piece of code that you find suspect and the fundamental difference between how it is handled in AngularJS vs. plain HTML and Javascript.

This is basically HTML with Angular directives sprinkled in. The one that I find potentially susupect is this: <a href="" ng-click="archive()">archive</a>.

This looks awfully similar to something we would have written 10 years ago:

<a href="" onclick="archive()">archive</a>

However, there is a fundamental difference between the above HTML and the AngularJS implementation. For AngularJS, the archive function is located on a scope that we control and can manipulate through the use of controllers. The raw JS example requires that archive be in the global namespace (which is bad for many reasons).

But, we can still see what the onclick event binding was meant to do; it was meant enable one to declaratively build behavior into a view, and let JS handle the implementation details. AngularJS does this, AND provides a way to organize the difference scopes/contexts of our view in a way that is not possible with regular HTML.

Yes, AngularJS involves extending HTML by moving more of the presentation and binding concerns into the view. The good news is we are heading that way with HTML6. Here are some select quotes from http://html6spec.com/:

Imagine being able to mark something up the way you want to mark it up. Imagine changing <div id="wrapper"> to <wrapper>...

The web is moving towards a giant app store and we need to embrace it. The markup we use shouldn't work against us, it should work for us. This spec is to do just that. To finally break free of fatuous rules and standards and to give us, developers, total freedom to code as we please bringing the web a more semantic, clean, and human readable markup.

In a way, AngularJS brings us all the goodness of HTML6, but allows us to use it today. How the web is used has changed drastically in the past 15 years and our tools are still lagging very far behind. Lucky for us, the future is a beacon of light and hope, and AngularJS brings the future back to the present.

Answer 2

Quite an interresting observation and question, and a good answer by @mortalapeman.

I'd like to add that the function of the html, and our expectations of what it's supposed to do is changing. We've been taught to keep our behaviour completely out of the document (html) and rather set up our code to hook into the document without polluting the document.

With Angular the job of the html isn't simply to be a document, it is to be the presentation layer of an application, which to me is a much bigger job. And to fill this job Angular (and similar frameworks) allows us to do two-way binding with our data and behaviour in a declarative way while, as mortalapeman points out, keeping our data and behaviour nicely scoped and separate, as well as testable.

In fact, now that I think about it, it's actually a bit silly to maintain a position that your html should be a pure document, but at the same time contain buttons and other controls, indicating that it is more than a document. Maybe it's just me, but I find that paradoxical. It makes perfect sense to me that we declare what action should be triggered when operating a control.