Comment by altcognito | Hacker News Reader

Comment by altcognito | Hacker News Reader

"Most of the time, as soon as you touch the DOM inside your Angular app, Angular will throw a few errors your way..."

"Rightfully so, because I would have destroyed the DOM that Angular was using as its template. Angular doesn't use string-based templates; it uses the DOM itself."

Up until now, string based templates have been far better performing. Using the DOM as a template engine has been clumsy and laced with oddities. (ng-cloak) Not really what it's designed for.

Everything seems to be either written as code (URL handling) or coded into the DOM. Do I really want my HTML to be Angular specific?

I also like this about the article:

"Another way to look at Angular is to give it the sheriff's star in the cowboy land of frontend development. The lack of official documentation and the ever decreasing differences between browser implementations groomed a culture of "whatever gets the job done."

Then he proceeds to write:

"The documentation leaves a lot to be desired, because it's sometimes incomplete or out of sync, leaving the actual source code as the only source of truth. Now this is not cumbersome for an experienced engineer, but it's daunting for a new engineer to even read, much less understand. The Angular source code is not the most straightforward implementation."

So, Angular's got that going for it.

You make good points, and I'll try to explain myself as best as I can. (I'm Sean, I wrote this article).

String templates outperform DOM, this was very true in the past and as far as I know still is true. The great advantage of it, is the "live" data bindings, which I think depend on the template being the actual live DOM. (I can be wrong here, and if I am then I need to go learn more about this choice)

As for the documentation point, you are right I contradict myself. What I meant to say is that angular suggests a way to structure your application versus backbone for example that only gives you the tools and no structure.

Thanks for pointing these out, I'll have to be more careful on how I express myself next time I write something.

Thanks for writing the article. I hadn't considered the design reason to protecting the DOM like this, especially when you consider the core data live binding of Angular. Whether I agree or disagree with the approach, knowing the reasoning behind it helps everything to fit together.

This definitely seems to be the direction everything is going with web-components.

I dont see how angular suggests a way to structure your application more than backbone did.

In Backbone you had very rigid definitions of models, collections and relationships between them, whereas in Angular any JS object can be a model and relationships between models can also be very flexible(although scope hierarchy is something u need to wrap your head around).

The documentation does leave a lot to be desired and I often find myself going back to the 1.1.5 directive documentation to look up different scope data binding options etc.

Reply on news.ycombinator.com