3 ms·

I'll agree it's not pretty to view source and see an inordinate amount of fluff in what was once your beautifully handcrafted semantic HTML. Much of this can be

I'll agree it's not pretty to view source and see an inordinate amount of fluff in what was once your beautifully handcrafted semantic HTML. Much of this can be alleviated with templating (ng-view). Have you taken the time to play around with angular before airing your grievances? My hunch is yes and that you may just be simplifying things for others who haven't used it yet. For those of you who haven't had the pleasure of working with angular: Once you've familiarized yourself with the verbiage, most of jeswin's concerns here come second nature just by glancing in one's source code. Let's take the example: form.length.$error.float The name form, albeit horribly chosen in this case, represents the parent form's identifier in angular (the form's name attribute). It would've made more sense to use <form name="formLengthValidationDemo"> or something more insightful so you could more easily see the name matching from HTML to JS. $error is simply the representation of any form validation errors that may have occurred. It's standard in angular, and there's plenty of documentation. Just google for "angularjs form validation" and you'll find a million resources at your disposal. form.length.$error.float is checking if an error exists for the validation rule float. Given the limited amount of code in the sample, we'd have to arbitrarily assume that the "smart-float" directive is implicitly setting a custom validation rule via: ngModel.$setValidity('float') I'll have to agree to disagree regarding pattern usage and dependency injection. They do have a place, and it tends to be in larger applications which become a burden to maintain as your application grows. To be quite honest, I believe angular brought a simplicity to DI that has yet to be seen in many other frameworks. It entirely lowered the barrier to entry for writing testable code and heavily promoted unit testing at the same time.

Bahamut 13y ago
Agree 100% with your post - some of these complaints are misrepresenting the aspects that are not as desired in Angular. I've used Angular quite extensively for the past 1 1/2 years, and most of the complaints I have with it are more nuanced, such as having to dynamically inject some custom directives via $compile in a service method provided to a controller due to the complexity of being able to alter the attributes present dynamically in a template. The declarative style that Angular coaxes you into makes things incredibly easy to understand - you can write code like <header> <navbar></navbar> </header> <main> <sidebar></sidebar> <content></content> </main> <footer> <company-info></company-info> <credits></credits> </footer> And instantly understand what the purpose of these elements are - they're easy to read, they're descriptive, and they're clearly custom elements not part of the normal HTML5 spec, so you can instantly recognize that they must be directives. I can also do simple directives like <loading-spinner></loading-spinner> and create a nice template for CSS to hook into by using the loading-spinner element tag without having to distract from the rest of my DOM with a nesting of 8 divs that can easily be tucked away in a reusable template.
- talmand 13y ago
  I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something? The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That might muck things up a bit. At least visually, as I would imagine the directives would likely continue working the same as before. It's just that the "they must be directives" logic would fail in that instance.
  - spankalee 13y ago
    Actually, it's a little more complicated than this even. Not only might HTML add more tags, but a non-standard tag might be a W3C custom element: http://www.w3.org/TR/custom-elements/ http://www.w3.org/TR/custom-elements/ When users gain the ability to define their own tags, you might not know which ones are driven by directives, the custom element, or both even.
  - goblin89 13y ago
    Good point. I, too, enjoyed using custom tags like <zoomer> or such, but I'm going to think twice in future. Interestingly, out of the box Angular provides directives as a, input, or form—meaning that when you write <input> you are, in fact, invoking a directive that provides extra features along with native tag's functionality. While using Angular, you may as well consider every HTML element a directive. Nevertheless, Angular uses ng- prefix with their built-in directives that don't replicate some existing tag's functionality closely.
  - craigching 13y ago
    You can make your custom directives HTML5 compliant, see [1], you can use the HTML5 data- prefix. For instance: <sidebar></sidebar> can instead be coded as: <span data-sidebar></span> or something similar. [1] -- http://docs.angularjs.org/guide/directive http://docs.angularjs.org/guide/directive
    - 13y ago

Bahamut 13y ago

Agree 100% with your post - some of these complaints are misrepresenting the aspects that are not as desired in Angular. I've used Angular quite extensively for the past 1 1/2 years, and most of the complaints I have with it are more nuanced, such as having to dynamically inject some custom directives via $compile in a service method provided to a controller due to the complexity of being able to alter the attributes present dynamically in a template. The declarative style that Angular coaxes you into makes things incredibly easy to understand - you can write code like <header> <navbar></navbar> </header> <main> <sidebar></sidebar> <content></content> </main> <footer> <company-info></company-info> <credits></credits> </footer> And instantly understand what the purpose of these elements are - they're easy to read, they're descriptive, and they're clearly custom elements not part of the normal HTML5 spec, so you can instantly recognize that they must be directives. I can also do simple directives like <loading-spinner></loading-spinner> and create a nice template for CSS to hook into by using the loading-spinner element tag without having to distract from the rest of my DOM with a nesting of 8 divs that can easily be tucked away in a reusable template.

talmand 13y ago
I agree with you that since your elements appear to not be a part of the HTML5 spec they must be custom and are directives, wouldn't it be a good idea to mark them as such in some way? Maybe prepend them with "an-" or something? The reason being, considering that HTML5 is an ever evolving spec that it might be possible for a new element to be introduced that could be using the same name as one of your examples. That might muck things up a bit. At least visually, as I would imagine the directives would likely continue working the same as before. It's just that the "they must be directives" logic would fail in that instance.
- spankalee 13y ago
  Actually, it's a little more complicated than this even. Not only might HTML add more tags, but a non-standard tag might be a W3C custom element: http://www.w3.org/TR/custom-elements/ http://www.w3.org/TR/custom-elements/ When users gain the ability to define their own tags, you might not know which ones are driven by directives, the custom element, or both even.
- goblin89 13y ago
  Good point. I, too, enjoyed using custom tags like <zoomer> or such, but I'm going to think twice in future. Interestingly, out of the box Angular provides directives as a, input, or form—meaning that when you write <input> you are, in fact, invoking a directive that provides extra features along with native tag's functionality. While using Angular, you may as well consider every HTML element a directive. Nevertheless, Angular uses ng- prefix with their built-in directives that don't replicate some existing tag's functionality closely.
- craigching 13y ago
  You can make your custom directives HTML5 compliant, see [1], you can use the HTML5 data- prefix. For instance: <sidebar></sidebar> can instead be coded as: <span data-sidebar></span> or something similar. [1] -- http://docs.angularjs.org/guide/directive http://docs.angularjs.org/guide/directive
  - 13y ago