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.

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.

• javascript
• html
• angularjs
• standards

• 1 first thought is try writing a state saving single page app using jQuery and semantic markup and compare amount of code , time spent and headaches to same app written with angular... testing? Far simpler in angular....amount of code and code fragmentation- far less in angular. Modularity and ease of maintaining or enhancing...far simpler in angular. Trade off is well worth some combining of concerns IMO – charlietfl Commented Oct 27, 2013 at 17:09
• 2 Youre right, this isnt the right place for this question. It seems more like a conceptual question and those belong in programmers.stackexchange.com – qodeninja Commented Oct 21, 2014 at 19:54

4 Answers 4

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.

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.

I was studying Angular recently and had the exact same thoughts, doesn't this violate separation of concerns? The examples they give at their site "Do violate separation of concerns!" After being involved with MVVM and MVC over the past 10 years, I'm thinking that Angular is a step back to the Cold Fusion days. Not that Cold Fusion and Angular are not strong, they just are enablers for bad design.

All SDLC studies show that 50-60% of total cost of software is in maintenance, not development! But most developers think (because of due dates) they just have to get it out there, and to their credit, they do! However, projects end, developers leave and the rest are left wondering how to support this code base.

We've know about OOP and OOD for years and just recently saw attempts to bring Javascript into this concern with extensions like JQuery Although until Javascript truly becomes an OOD language it and all extensions of it, will not truly get there. The comment above "gloabal variables are bad" is a good comment, but in strongly typed languages, it's NEVER a concern. The only time these types of issues happen is when the framework supports it out of the box! Strongly typed languages can have global vars if needed but scoping is king in those languages and it is one of the first things taught.

My experience over the years is that programmers are first 1) Quick to get the job done before they recognize the patterns that make up good technique. 2) There are tons of code in every major institution that needs severe re-factoring 3) Problems in extensible are not seen until many years later 4) The effort to re-tool is huge! All of this is good news for job security, yet at the same time, why not just do it correctly from the start?

JQuery, Javascript and even Angular have their place, but they are also frameworks that encourage bad design for those unaware. I've found the single most important pattern in all of programming is the "Observer Pattern" which we see in the ability to create Event Handlers and to create Events. Decoupling then becomes very high on the list as well. If you have code that is big on events and event handling chances are, you are headed in the right direction. If you are reusing code and being strict about not repeating things you are doing well. Finally if you are into re-factoring with a passion and really understand the power of interface based programming techniques you are doing well. Oh yes one other thing, if you know what dependency injection is all about, you are a 5 star general in the Army of Programmers. March on, good soldiers!

I have been using Knockout.js (which is pretty similar to angular regarding the data-binding concepts) for the past two years on a large project. The main advantage I see in having only some function names in the markup, instead of the entire function implementation is that the implementation can be easily changed without altering the markup. Especially if the markup is not fully controlled by you, as was in our case.

The designer altered the markup to suit the visual requirements, while we just told him not to mess with data-bind attributes. Of course, sometimes he changed the markup so heavily that we needed to alter the data-bind attributes, but this mostly meant moving them from one tag to another, the implementation was unchanged.