4 ms·

This is a critique of the example, more than the framework itself. The "smart-float" directive is not a native angular directive, but rather a directive made fo

by kayloos 13y ago

This is a critique of the example, more than the framework itself. The "smart-float" directive is not a native angular directive, but rather a directive made for the example. As for the "form.length.$error.float", it probably could be a bit more concise, but is it really that bad? What would be a "more semantic" way? The main strength of angular, is that you are able to point your DOM elements to environment variables in your JavaScript code -- eliminating the need for traversing the DOM to find a mount node. If you are opposed to this functionality and insisting on traversing the DOM from the JS side, I'd love to hear why. You can find small things you dislike in any framework, but rarely are they valid criticisms of the general concept. Often, these details are there for a reason, and just as often, they are flaws waiting to be fixed by an open source developer.

jeswin 13y ago
I'll keep this high level; that's where I have issues with Angular. Angular wants you to learn its vocabulary, and encourages users to expand it further. Like you point out, smart-float is a directive specific to the example. To me, it is a foreign object I don't recognize in html. In fact, directives, scopes? The big one. Dependency Injection, factories, modules. In JS, this is a solution looking for a problem. There are simpler alternatives to DI. They have issues, but only in theory. Clarity matters a lot. ng-show="form.length.$error.float". Is there a more simpler way of doing it? There should be; I can't even tell what that means. I think there are distinctly two camps. I'm in the one which wants frameworks to make me productive with the languages, specs and standards I already know. React (+ router) does this. Backbone does this too, depending on what you're building. (Edit: replaced semantic with clarity)
- reboog711 13y ago
  My interpertation of the AngularJS DI implementation is that it exists primarily to make it easy to swap items out for testing purposes. I believe it solves that problem very well. What alternatives do you recommend to DI?
  - jeswin 13y ago
    Nothing, for swapping things out. :) In my test initialization, I'd probably just replace the value of "ns.someService" worldwide with a mock.
    - nocoment 13y ago
      > just replace the value of "ns.someService" worldwide with a mock. Having a window-wide namespace might make sense in the test, but it is pretty risky/limiting if you are writing a component that should be reused in contexts you don't fully control. There are other ways around that besides DI, but they will probably have similar trade-offs in safety EOU, etc.
- jqueryin 13y ago
  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.
- samizdatum 13y ago
  The philosopher David Lewis had a lot of critics, and they would often cite the fact that they couldn't possibly see how modal realism could be true, to which Lewis would reply, "I don't know how to refute an incredulous stare." Arguments from personal incredulity don't engage substantively with what they ostensibly claim to refute because they import a variable- the argument-maker's conception of what seems plausible- that really should do no work in a logical analysis. The arguments adumbrated in the parent comment seem to have similar failure modes, adorned as they are with premises such as "to me, [the directive] is a foreign object I don't recognize," and "I can't even tell what that means." Someone who has never programmed before could look at some vanilla javascript and plead perplexity, but obviously this isn't an indictment of javascript itself. To really make the point, the parent comment would have to show that the learning curve is disproportionately arduous for the payoff at the summit, but reiterations of personal unfamiliarity were offered instead. Jeswin gives no evidence of having made a reasonable attempt to understand Angular ("directives, scopes?"), but more crucially, displays little understanding of the benefits of Angular. DI is criticised as "a solution looking for a problem" in the context of javascript, as if dependency injection were a bandaid for not being a dynamic language. DI enables testability, and not even mentioning this advantage, let alone not providing a cogent argument for why the learning curve of DI doesn't justify the gains in testability, is to refuse to participate in the discussion entirely. Directives are similarly dismissed as "foreign objects," which they might be to some, but they're hugely powerful foreign objects that allow arbitrary behaviour to be written declaratively. Not knowing the benefits of Angular obviously contributes greatly to a reluctance to learn it, and perhaps a subsequent rationalisation of this reluctance as being provoked by something intrinsic to the framework. Fittingly, after expressing bewilderment regarding Angular scoping, Jeswin goes on to divide the world into two camps, declaring membership in "the one which makes me productive with the languages, specs, and standards I already know", which is about the closest thing to a natural language scoping bug I've come across.
  - jeswin 13y ago
    > DI enables testability, ..... the learning curve of DI doesn't justify the gains in testability Dependency Injection is a redundant, useless pattern in dynamic languages; especially when it comes to testability. In test.js: //paymentService may be an instance or a class services.paymentService = mockPaymentService; .... //use paymentService in your tests here. The above over-simplified example satisfies most test cases. You can convince me with some use-cases. (Edit: You weren't misrepresenting what I said. Removed that claim. I misread, apology.)

by kayloos 13y ago

jeswin 13y ago

I'll keep this high level; that's where I have issues with Angular. Angular wants you to learn its vocabulary, and encourages users to expand it further. Like you point out, smart-float is a directive specific to the example. To me, it is a foreign object I don't recognize in html. In fact, directives, scopes? The big one. Dependency Injection, factories, modules. In JS, this is a solution looking for a problem. There are simpler alternatives to DI. They have issues, but only in theory. Clarity matters a lot. ng-show="form.length.$error.float". Is there a more simpler way of doing it? There should be; I can't even tell what that means. I think there are distinctly two camps. I'm in the one which wants frameworks to make me productive with the languages, specs and standards I already know. React (+ router) does this. Backbone does this too, depending on what you're building. (Edit: replaced semantic with clarity)

reboog711 13y ago
My interpertation of the AngularJS DI implementation is that it exists primarily to make it easy to swap items out for testing purposes. I believe it solves that problem very well. What alternatives do you recommend to DI?
- jeswin 13y ago
  Nothing, for swapping things out. :) In my test initialization, I'd probably just replace the value of "ns.someService" worldwide with a mock.
  - nocoment 13y ago
    > just replace the value of "ns.someService" worldwide with a mock. Having a window-wide namespace might make sense in the test, but it is pretty risky/limiting if you are writing a component that should be reused in contexts you don't fully control. There are other ways around that besides DI, but they will probably have similar trade-offs in safety EOU, etc.
jqueryin 13y ago
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.
samizdatum 13y ago
The philosopher David Lewis had a lot of critics, and they would often cite the fact that they couldn't possibly see how modal realism could be true, to which Lewis would reply, "I don't know how to refute an incredulous stare." Arguments from personal incredulity don't engage substantively with what they ostensibly claim to refute because they import a variable- the argument-maker's conception of what seems plausible- that really should do no work in a logical analysis. The arguments adumbrated in the parent comment seem to have similar failure modes, adorned as they are with premises such as "to me, [the directive] is a foreign object I don't recognize," and "I can't even tell what that means." Someone who has never programmed before could look at some vanilla javascript and plead perplexity, but obviously this isn't an indictment of javascript itself. To really make the point, the parent comment would have to show that the learning curve is disproportionately arduous for the payoff at the summit, but reiterations of personal unfamiliarity were offered instead. Jeswin gives no evidence of having made a reasonable attempt to understand Angular ("directives, scopes?"), but more crucially, displays little understanding of the benefits of Angular. DI is criticised as "a solution looking for a problem" in the context of javascript, as if dependency injection were a bandaid for not being a dynamic language. DI enables testability, and not even mentioning this advantage, let alone not providing a cogent argument for why the learning curve of DI doesn't justify the gains in testability, is to refuse to participate in the discussion entirely. Directives are similarly dismissed as "foreign objects," which they might be to some, but they're hugely powerful foreign objects that allow arbitrary behaviour to be written declaratively. Not knowing the benefits of Angular obviously contributes greatly to a reluctance to learn it, and perhaps a subsequent rationalisation of this reluctance as being provoked by something intrinsic to the framework. Fittingly, after expressing bewilderment regarding Angular scoping, Jeswin goes on to divide the world into two camps, declaring membership in "the one which makes me productive with the languages, specs, and standards I already know", which is about the closest thing to a natural language scoping bug I've come across.
- jeswin 13y ago
  > DI enables testability, ..... the learning curve of DI doesn't justify the gains in testability Dependency Injection is a redundant, useless pattern in dynamic languages; especially when it comes to testability. In test.js: //paymentService may be an instance or a class services.paymentService = mockPaymentService; .... //use paymentService in your tests here. The above over-simplified example satisfies most test cases. You can convince me with some use-cases. (Edit: You weren't misrepresenting what I said. Removed that claim. I misread, apology.)