4 ms·

Angular most certainly does not establish any app structure conventions. You're thinking of Ember. Angular does, however, enforce other conventions such as modu

Angular most certainly does not establish any app structure conventions. You're thinking of Ember. Angular does, however, enforce other conventions such as modularity and separation of concerns with its dependency injection and directive-based approach to DOM manipulation. That's a very important distinction to make. It strikes the right balance between convention and configuration, IMO.

GeneralMayhem 13y ago
>modularity You've got to be joking. An Angular "module" is a chunk of code that happens to be given a collective name. There's no namespacing, no encapsulation, and no build/file management.
- lowboy 13y ago
  I'd say the Angular approach is definitely modular in the context of current javascript. Perhaps you're thinking of another language's definition of modular?
  - gedrap 13y ago
    I agree with you. The first thing that comes to my mind when thinking of modularity and ng, is directives.
  - GeneralMayhem 13y ago
    You cannot use two modules that have directives with the same name. Even if you never use them directly, they're only ever dropped in by controller templates as part of what that module does. When "modules" can break each other because of purely internal implementation details, there is something very wrong.
    - lowboy 13y ago
      Huh, I've never come across that before. Yeah, that is a problem, and one that I hope they address soon. Fortunately a workaround exists in the form of naming conventions, tedious as that may be. So the Angular approach is modular, but slightly broken.
      - GeneralMayhem 13y ago
        Naming conventions are a workaround in the same way that "remember to free your pointers" is a workaround for the lack of memory management in C, except that managing your own names has no performance benefit. I really think the whole idea of a global name-based registry is flawed. Again, look at more traditional library/class-based language like Java, C#, and C++ - they have to go to absurd levels of verbosity, and don't even get absolutely guaranteed uniqueness out of it, but the power of dynamic linking makes it worthwhile.
        lowboy 13y ago
        Yeah, agreed on both points.
- warfangle 13y ago
  > no namespacing You don't really need to for angular development. Namespacing Javascript is a cargo cult practice brought over from more traditional OO languages. > no encapsulation There is if you want it to be. You're especially encouraged to separate the concerns of the DOM in directive services, for example. > no build/file management That's kind of up to you, isn't it? You can run with grunt/require if you want a headache, grunt or gulp / uglify if you want easy, you can run with gulp/browserify if you want the new cool ...
  - GeneralMayhem 13y ago
    I agree that you don't generally need namespacing for JS, but you do need namespacing when everything is referred to by name! If the only way to refer to a controller is that it's called "MainController," with all other information about where it came from and what it does completely lost when it gets added to the registry, then you have to have some way to deal with naming conflicts. Angular... just... doesn't. The Angular injection module is global variables by a different name, and there's no way not to use it. Hell, at least globals you can work around with a no-conflict hack. Compare to Backbone, which is not a perfect framework by any stretch, but with Require it does dependency management and modularization really, really right. Also compare to Java, which similarly forces classes to be referred to by one canonical name, but deals with it via the org.apache.commons... spam. You're right about services providing encapsulation. I still wind up with a lot of awkward situations where directives can't work without knowing something about their parent scope. It's possible that's more my problem because it's getting less frequent as I abuse ng-model more and more, but also remember that isolate scope, up until very recently, worked in an incomprehensibly stupid way [1]. >grunt or gulp / uglify if you want it easy Eh... not really that easy. At least, not if you want to anything more sophisticated than concat together every .js file in sight. Require, for all its problems and relative-path headaches, at least makes it dead simple to run in development without having to remember to either add another file to the list or wait for a rebuild every time you change something. [1]: https://github.com/angular/angular.js/commit/909cabd36d779598763cc358979ecd85bb40d4d7 https://github.com/angular/angular.js/commit/909cabd36d77959...

GeneralMayhem 13y ago

>modularity You've got to be joking. An Angular "module" is a chunk of code that happens to be given a collective name. There's no namespacing, no encapsulation, and no build/file management.

lowboy 13y ago
I'd say the Angular approach is definitely modular in the context of current javascript. Perhaps you're thinking of another language's definition of modular?
- gedrap 13y ago
  I agree with you. The first thing that comes to my mind when thinking of modularity and ng, is directives.
- GeneralMayhem 13y ago
  You cannot use two modules that have directives with the same name. Even if you never use them directly, they're only ever dropped in by controller templates as part of what that module does. When "modules" can break each other because of purely internal implementation details, there is something very wrong.
  - lowboy 13y ago
    Huh, I've never come across that before. Yeah, that is a problem, and one that I hope they address soon. Fortunately a workaround exists in the form of naming conventions, tedious as that may be. So the Angular approach is modular, but slightly broken.
    - GeneralMayhem 13y ago
      Naming conventions are a workaround in the same way that "remember to free your pointers" is a workaround for the lack of memory management in C, except that managing your own names has no performance benefit. I really think the whole idea of a global name-based registry is flawed. Again, look at more traditional library/class-based language like Java, C#, and C++ - they have to go to absurd levels of verbosity, and don't even get absolutely guaranteed uniqueness out of it, but the power of dynamic linking makes it worthwhile.
      - lowboy 13y ago
        Yeah, agreed on both points.
warfangle 13y ago
> no namespacing You don't really need to for angular development. Namespacing Javascript is a cargo cult practice brought over from more traditional OO languages. > no encapsulation There is if you want it to be. You're especially encouraged to separate the concerns of the DOM in directive services, for example. > no build/file management That's kind of up to you, isn't it? You can run with grunt/require if you want a headache, grunt or gulp / uglify if you want easy, you can run with gulp/browserify if you want the new cool ...
- GeneralMayhem 13y ago
  I agree that you don't generally need namespacing for JS, but you do need namespacing when everything is referred to by name! If the only way to refer to a controller is that it's called "MainController," with all other information about where it came from and what it does completely lost when it gets added to the registry, then you have to have some way to deal with naming conflicts. Angular... just... doesn't. The Angular injection module is global variables by a different name, and there's no way not to use it. Hell, at least globals you can work around with a no-conflict hack. Compare to Backbone, which is not a perfect framework by any stretch, but with Require it does dependency management and modularization really, really right. Also compare to Java, which similarly forces classes to be referred to by one canonical name, but deals with it via the org.apache.commons... spam. You're right about services providing encapsulation. I still wind up with a lot of awkward situations where directives can't work without knowing something about their parent scope. It's possible that's more my problem because it's getting less frequent as I abuse ng-model more and more, but also remember that isolate scope, up until very recently, worked in an incomprehensibly stupid way [1]. >grunt or gulp / uglify if you want it easy Eh... not really that easy. At least, not if you want to anything more sophisticated than concat together every .js file in sight. Require, for all its problems and relative-path headaches, at least makes it dead simple to run in development without having to remember to either add another file to the list or wait for a rebuild every time you change something. [1]: https://github.com/angular/angular.js/commit/909cabd36d779598763cc358979ecd85bb40d4d7 https://github.com/angular/angular.js/commit/909cabd36d77959...