7 ms·

Complexity Creeps: Why I'm Concerned for the Future of Angular.js

96 points by bcrawford 13y ago

AdrianRossouw 13y ago
This is part 3 of this series of articles 1. i was wrong to be afraid of angular.js https://news.ycombinator.com/item?id=7384937 https://news.ycombinator.com/item?id=7384937 2. why i was wrong to be afraid of angular.js https://news.ycombinator.com/item?id=7394959 https://news.ycombinator.com/item?id=7394959 This is where i discovered the exact thing about angular that freaked me out the most, and how I was finally to get down in words what I felt about it. I made a github issue about it, and the devs acknowledged the issue, saying it was no longer part of angular 2.0
- batoure 13y ago
  >I made a github issue about it, and the devs acknowledged the issue, saying it was no longer part of angular 2.0 Ok so I read all both of your other articles and found them to be interesting. I was disappointed that there wasn't some kind of afterword to go with the sabre rattling. Seeing that you put in an issue makes me feel alot better about the whole series. As I read these I kept thinking... yeah but... and then thinking of a feature that annoyed me that changed from release to release. And ultimately I think the biggest thing I have always liked about angular is how quickly the community has learned from potential mistakes and shed chaff code....
  - AdrianRossouw 13y ago
    I was always going to need to put this into an issue, once I identified why it bothered me. I think angular is really special because I can see it getting simpler. I almost never see that in software. They have shown that they are willing to change, and I think that they have the right people in charge to do it. I think you are going to see some serious changes for 2.0 though. Now they are on semver, stuff is going to have to shift pretty majorly between major releases. You can see some of that in angulardart already. I look forward to it.
    - batoure 13y ago
      I'm also pretty excited to see the next release. I have read about potentially including lazy loading in the base which personally would be really huge. Not having to integrate Require would be a pretty interesting to me if it happens
      - AdrianRossouw 13y ago
        have you met my friend [1] browserify? I'm probably not the audience for require.js, because I've never had a situation where I was forced to not have a build step. Once you just accept that there's always a build step, life becomes so much easier. [1] http://daemon.co.za/2014/03/subtly-meta-introduction-to-browserify http://daemon.co.za/2014/03/subtly-meta-introduction-to-brow...
        batoure 13y ago
        >Once you just accept that there's always a build step, life becomes so much easier. Sigh... but I don't want there to be a build step... :(
        AdrianRossouw 13y ago
        I feel for you man. I really recommend you just try to build something, even if it's a little demo of some sort, with the assumption that you are going to have a build step. I just found that the result of that assumption ends up with something that is a lot easier to work with and reason about, than trying to rail against it by using something like r.js.
carsongross 13y ago
It isn't ready yet (another few weeks until a 0.1) but I'm working on a simpler UI framework that lets you bind HTML elements directly to REST-ful URLs, cutting out a big swath of complexity for many apps: http://intercoolerjs.org/ http://intercoolerjs.org/ Again, this is not ready yet and I'm actively changing things, but if you are interested in an AJAX framework that is concerned with keeping complexity to a minimum, it might be worth checking out. Comments and criticisms very welcome.
- adambratt 13y ago
  I just created a post about this on StackOverflow... Awesome! http://stackoverflow.com/questions/22386214/whats-the-best-way-to-convert-server-side-html-into-a-javascript-mvc-on-page-lo http://stackoverflow.com/questions/22386214/whats-the-best-w...
apinstein 13y ago
It's interesting that he has a visceral reaction to the "hackiness" of Angular's clever way to do runtime DI but no visceral reaction to the fact that the problem was created by a third-party program which was instructed to purposefully obfuscate the actual source code of his program before delivering it to the runtime... the JavaScript world is indeed a funny place. That said, I am empathetic to his argument. But as a very happy Angular user, the benefits that are gained by having a runtime DI layer that works such that it can be built into the entire platform so far outweigh the one-time tooling change that it doesn't bother me at all. The rest is a slippery-slope argument that I don't think is fair. If you trust Angular as a project, then you have to trust to some extent that they'll make sane decisions. Since this particular clever hack is the only one that won't get "better" over time as runtimes improve, I think that they deserve the trust so far.
- AdrianRossouw 13y ago
  DI is fine, i was just concerned that they have something that breaks as the first recommended way to do something. Much less that they have it at all. Minification pretty much counts as 'normal use' these days, as much as we all have a distaste for it, we really can't change it. You should watch the video on my post and tell me you are still comfortable with it doing that at runtime. And the slippery slope thing? I spent 10 years of my life building open source projects with thousands of contributors and untold thousands of users. That's experience talking there. My point was that you can't deny the sufficiently promising excuse to abuse it further, without admitting that it is flawed to begin with. My suggestion was that now that the ngmin exists, make that the only way to do it and remove all the crazy stuff out of the main execution. I also said that clever hack is the only one that could never get better. There's no standards path for it. They have been shown to deserve the trust. they are removing the hackiness from 2.0.
  - apinstein 13y ago
    Great ideas! Sounds like we generally agree. I read the whole post but didn't watch the video or read all of the 2.0 stuff... though I am aware how their DI hack works. That said, the title of your post makes it sound like you think they're heading off a cliff, but your response to me sounds like the opposite... I was just responding to the tone set by the article. I'll also agree that it is frustrating early in the AngularJS experience to hit that minification bug. But it's easy to get over also.
jcampbell1 13y ago
This seems like a one-sided overthinking of the auto dependency injector (which is like 30 lines of code). 1. The auto DI means beginners can get to "Hello World" in angular without learning some wonky injector syntax. If Angular's goal was to bring some of the jQuery crowd on board, then it was a smart move. 2. The auto DI doesn't survive minification, so not all code can be copy-pasted, and there are two different syntaxes. Unnecessary complexity? I see no reason to make a bunch of analogies to argue on one side.
- AdrianRossouw 13y ago
  Are you sure you're not just under-thinking it? Those 30 lines of code require the hundred or so lines of ngmin to actually work correctly, and then results in the extra (im assuming) hundred or so lines of grunt-ngmin and all the tooling around that. And then all the tests, the issues for the main project and all of the related projects, every bug that anybody has ever faced with minification of angular apps. The auto-di is not that much simpler than the array format, and the array format is also actual valid javascript. They are abusing language features in such a way as to bypass the semantics of the language itself. The fact that it doesn't survive minification is a sign that you shouldn't really be doing it to begin with. There are 3 different formats, and one of them introduces some crazy magic into the main framework, that is all really unnecessary and could just be as easily avoided. Auto-Di is the 'wonky' format in any reasonable context, I'm afraid.
badman_ting 13y ago
I think DI in Angular should be an opt-in thing, too confusing otherwise. I've had moments where I thought I was just writing a regular function, and then Angular started throwing exceptions because it was trying to inject dependencies based on the argument names. (And the solution was to write a function with no arguments that returned the actual function with arguments!) There are conventions around what string maps to what thing, so that sometimes strings like "controller" or "provider" are inferred and not required to be specified. This is bad -- things should just be referred to by their full names. It would be nice to have the ability to ask for things directly in require-style function calls instead of having them be parameters to a function. It's actually sort of crazy that you can define a controller (for example) with angular.controller('MyController', function(){}), but then you can't ask for it back with angular.getController('MyController'), or whatever. All this makes it a lot harder to try things out in the console, and lengthens the feedback loop of determining what works and what doesn't. And I didn't even know about the minification thing. That is legitimately terrible.
- johnny635 13y ago
  You need DI to do unit tests properly.
  - zwily 13y ago
    Isn't the problem Automatic DI, and not DI?
wprl 13y ago
I too think Angular is overly complex and "magical." The JavaScript world should be learning from the mistakes of monolithic and semi-monolithic frameworks such as ASP.NET and SEAM not trying to recreate them. For my part I'd like to see separate libraries for events, views, models, syncing models to persistent storage, and binding models to forms. Small micro-libraries allow maximum flexibility and efficiency, and facilitate more maintainable code. The way that Angular violates separation of concerns between presentation and view is another symptom of a monolithic approach, and a step backwards in HTML client software design.
- Encosia 13y ago
  I wish I could give this comment a million upvotes. From my perspective as someone who has developed on the MS stack for 15+ years, frameworks like angular and ember strike me as (retroactively) following right in the footsteps of Silverlight and ASP.NET WebForms. To be clear, I don't think that's a good thing.
  - EricDeb 13y ago
    I think simplicity is undervalued in the programmer world in general. It takes so much more mind-energy for someone to implement/refactor/add-to/test complex code written by someone else as opposed to simple/verbose code.
    - AdrianRossouw 13y ago
      yeah man. when i subtitled my blog sensible complexity, I didn't realize that it was actually something I cared so deeply about.
    - frou_dh 13y ago
      > I think simplicity is undervalued in the programmer world in general. I imagine every programmer will claim to value simplicity. Trouble is, they're all talking past each other because their working definition is "the way I personally do things".
edanm 13y ago
While I do the think author makes too big a deal about this, I very much agree with them. The main issue is whether or not we should be teaching people, as a first brush with Angular, to code things with "automatic Dependency Injection", where the types are inferred from variable names. The alternative, and only way to code a "real" application, is to pass the names of things you want injected as strings. For people unfamiliar with Angular, this difference means turning: myFunction(Dep1, Dep2) into myFunction(['Dep1', 'Dep2', Dep1, Dep2) (more or less). Doesn't seem like a big deal, does it? But I think the decision to teach people the "bad" way to do things, all for the sake of making things "simpler", is completely wrong, and misunderstands what kinds of complexity people have a problem with. Complexity isn't telling people "write the same word twice, cause that's how it works". Complexity is telling people "here's another thing you have to learn about this framework". This is a small matter, but it isn't trivial, and is a common mistake with Angular.js (hiding the wrong kinds of complexity).
- AdrianRossouw 13y ago
  I'm only making a 'big' deal about this because I have given this serious thought. This is the third part in a series of articles where I was trying to understand why my intuition was telling me that there was something not quite right about angular. I finally managed to track it down to this specific little thing, and how the unintended consequences of a feature like this could have far ranging consequences to it as a viable platform. My reasoning was not about how crazy this is now (which it is), but how this could end up 5-10 years from now if it doesn't get removed now.
  - ilaksh 13y ago
    Why would you expect Angular or any current platform to be relevant in 5 years?
    - edanm 13y ago
      Most platforms, at least major ones, ARE relevant for many years. Of course we have yet to see if Angular will be one of them, but it's looking like it will.
Bahamut 13y ago
I'm a huge fan of dependency injection, it makes life infinitely better when designing your code & testability. That said, I'm somewhat sympathetic to this complaint - it turns me off towards Backbone. However, I argue that it isn't nearly as bad as views with Backbone. In addition, this is changing in 2.0 with a much cleaner injection mechanism.
- AdrianRossouw 13y ago
  dependency injection is fine. just the magic argument detection wasn't a good idea. Backbone views has nothing to do with this, imo. The thing I miss the most when using backbone, and I use it a _LOT_, is observables. Binding and unbinding model events can get really tedious. Marionette really does help for that, but this stuff can still get out of hand.
  - Bahamut 13y ago
    It does when it comes to not leaving your views in an ugly string representation of html - you use a build process of some sorts to get around that fundamental flaw so that you can still use a nice html template file. That alone was enough to sour me on Backbone, hence the comparison. This flaw in Angular isn't nearly as deep was my point.
    - iLoch 13y ago
      HTML is HTML, why does it matter what file type it resides in? All my templates are stored according to the view's type within my ./templates folder. If I want to include the HTML in an "actual" HTML file I can do that too. Have you even used Backbone?
klochner 13y ago
I still can't decide if angular dependency injection is more amazing or revolting. It's magic, it's non-intuitive, it breaks the standard paradigm that function arguments have no external significance, and it doesn't add much real value by just saving one extra line per function - inject(fn, ...) On the other hand, it's elegant if you ignore all the above criticisms.
- AdrianRossouw 13y ago
  just the inferred dependency injection. and it's warped. as i stated in my article. i don't mind the DI myself too much, but then, I also prefer commonJS =P
TempleOSV2 13y ago
You cannot club these niggers hard enough. I want to beat you, you're so stupid. Maybe it would help. retard nigger. http://www.nist.gov/itl/csd/ct/nist_beacon.cfm http://www.nist.gov/itl/csd/ct/nist_beacon.cfm ---- First, the Beacon-generated numbers cannot be predicted before they are published. Second, the public, time-bound, and authenticated nature of the Beacon allows a user application to prove to anybody that it used truly random numbers not known before a certain point in time. Third, this proof can be presented offline and at any point in the future.
ilaksh 13y ago
As far as the particular issue he picks on, he is making a big deal about something that's not, at least if you accept the general premises of Angular, and trying to pin the core of his whole argument on that. Which is dumb. Anyway, I have used many, many different UI frameworks on different platforms over the years. Including different .NET systems, Backbone, Angular and to some degree web components. And many other lightweight and heavyweight systems. I am actually amazed that developers are not immediately seeing the obvious advantages of Web Components (with Polymer for now). I am amazed that people are still trying to master AngularJS when we have Polymer. (At least the people who can tell their users to use a new version of Firefox or Safari, which is actually quite a lot of web apps these days, although obviously not all). Angular is very obviously more complex than necessary. Very few people are going to be with me on this, but this whole idea of separating out scope and avoiding global variables at all cost has got to the point where it is just ludicrous. And the only explanation is that this stigma about global variables has a religious and un-questioned association with incompetence. Unfortunately that particular cargo cult can lead to things like Angular DI. Why aren't more web developers excited about Polymer and Web Components? Because many web developers, despite experience with Angular, get distracted by DI and other over-complex topics and somehow fail to completely grasp the basic concepts and advantages of what a user interface component is and does.
- grumblestumble 13y ago
  Web developers are excited about Polymer and Web Components. However, using a product still on release 0.2 for building real-world, production apps is generally frowned upon by anybody over 16.
  - STRML 13y ago
    I've built a few projects with Polymer, including this public-facing one (http://securesha.re http://securesha.re), which is a poster child for why you shouldn't use pre-alpha software (see the blown stack in the console; this was working just fine a few browser releases ago). Thankfully, it's not a critical app and it's more of a proof-of-concept than anything else. The source is available below [1]. It was a joy to build Secureshare with Polymer and it really made me rethink what an HTML element can be and what it can do. You have to unlearn years or decades of assuming that an HTML element has almost no useful API; with Polymer, you're likely to define many core application functions directly on DOM elements themselves. It's a lot of fun once you get used to it. <polymer-localstorage> and <polymer-media-query> really opened my eyes to what was possible with this new paradigm, and it is unquestionably cleaner than what has come before. More than anything, I'm excited for the inevitable deluge of web components; finally, UI libraries that can that be mixed and matched in any web application without regard for what other JS and CSS is on the page. True isolation allows us to create truly fantastic projects. [1] https://github.com/STRML/securesha.re-client https://github.com/STRML/securesha.re-client
meric 13y ago
The author is concerned about the future of Angular because of the idiosyncrasies of one method of including dependencies. I mean, really? Is it so bad, the stench of automatic dependency injection, it overcomes all other beneficial features of Angular, it would jeopardise it's future as a web framework, such that it would lose compatibility with future browsers and your web app built in angular will stop working, with no support available? IMO it's a bit hyperbolic to suggest this is the case.
- AdrianRossouw 13y ago
  no. i was worried about the fact that people weren't questioning the logic of it, and that once this kind of magic takes hold ... it's really hard to take it out again. Nobody said anything about future browsers and losing compatibility. I do think that if this kind of thing grows, the system will become complex enough that developers will move to different frameworks that do similar things but don't have all this magic and baggage.
grumblestumble 13y ago
- AngularJS is a tool for building complex single-page web applications, not brochureware. - If you're building complex SPAs, you're going to require a decent level of tooling. - If you have a decent level of tooling, the points in this article are meaningless. As an aside, ngMin is the most trivial thing in the world to set up, and if you can't figure it out, array notation is slightly painful but well worth it for all of the tools Angular provides.
camus2 13y ago
AngularJS is not complex , when I think complex , I think SpringMVC or Struts complexity. AngularJS has problems ,but complexity is not one of them, definetly. Seems like JS programmers who only know JS think they can get away with ignoring patterns like dependency injection, Guess what, in order for code to be maintainable and testable it needs it. Front-end is about GUI dev,and that's where OOP shines. It's high time for JS folks to read classics like "Design Patterns" books, and embrace SOLID principles , or AngularJS wont even help when developping their so called "fairly large" apps.
- AdrianRossouw 13y ago
  Nope. agreed. I just felt that this little thing was complex, and that something like this can spread over time. I had no issue with dependency injection either, just the magic format.

96 points by bcrawford 13y ago

This is part 3 of this series of articles 1. i was wrong to be afraid of angular.js https://news.ycombinator.com/item?id=7384937 https://news.ycombinator.com/item?id=7384937 2. why i was wrong to be afraid of angular.js https://news.ycombinator.com/item?id=7394959 https://news.ycombinator.com/item?id=7394959 This is where i discovered the exact thing about angular that freaked me out the most, and how I was finally to get down in words what I felt about it. I made a github issue about it, and the devs acknowledged the issue, saying it was no longer part of angular 2.0

batoure 13y ago
>I made a github issue about it, and the devs acknowledged the issue, saying it was no longer part of angular 2.0 Ok so I read all both of your other articles and found them to be interesting. I was disappointed that there wasn't some kind of afterword to go with the sabre rattling. Seeing that you put in an issue makes me feel alot better about the whole series. As I read these I kept thinking... yeah but... and then thinking of a feature that annoyed me that changed from release to release. And ultimately I think the biggest thing I have always liked about angular is how quickly the community has learned from potential mistakes and shed chaff code....
- AdrianRossouw 13y ago
  I was always going to need to put this into an issue, once I identified why it bothered me. I think angular is really special because I can see it getting simpler. I almost never see that in software. They have shown that they are willing to change, and I think that they have the right people in charge to do it. I think you are going to see some serious changes for 2.0 though. Now they are on semver, stuff is going to have to shift pretty majorly between major releases. You can see some of that in angulardart already. I look forward to it.
  - batoure 13y ago
    I'm also pretty excited to see the next release. I have read about potentially including lazy loading in the base which personally would be really huge. Not having to integrate Require would be a pretty interesting to me if it happens
    - AdrianRossouw 13y ago
      have you met my friend [1] browserify? I'm probably not the audience for require.js, because I've never had a situation where I was forced to not have a build step. Once you just accept that there's always a build step, life becomes so much easier. [1] http://daemon.co.za/2014/03/subtly-meta-introduction-to-browserify http://daemon.co.za/2014/03/subtly-meta-introduction-to-brow...
      - batoure 13y ago
        >Once you just accept that there's always a build step, life becomes so much easier. Sigh... but I don't want there to be a build step... :(
        AdrianRossouw 13y ago
        I feel for you man. I really recommend you just try to build something, even if it's a little demo of some sort, with the assumption that you are going to have a build step. I just found that the result of that assumption ends up with something that is a lot easier to work with and reason about, than trying to rail against it by using something like r.js.

carsongross 13y ago

It isn't ready yet (another few weeks until a 0.1) but I'm working on a simpler UI framework that lets you bind HTML elements directly to REST-ful URLs, cutting out a big swath of complexity for many apps: http://intercoolerjs.org/ http://intercoolerjs.org/ Again, this is not ready yet and I'm actively changing things, but if you are interested in an AJAX framework that is concerned with keeping complexity to a minimum, it might be worth checking out. Comments and criticisms very welcome.

adambratt 13y ago
I just created a post about this on StackOverflow... Awesome! http://stackoverflow.com/questions/22386214/whats-the-best-way-to-convert-server-side-html-into-a-javascript-mvc-on-page-lo http://stackoverflow.com/questions/22386214/whats-the-best-w...

apinstein 13y ago

It's interesting that he has a visceral reaction to the "hackiness" of Angular's clever way to do runtime DI but no visceral reaction to the fact that the problem was created by a third-party program which was instructed to purposefully obfuscate the actual source code of his program before delivering it to the runtime... the JavaScript world is indeed a funny place. That said, I am empathetic to his argument. But as a very happy Angular user, the benefits that are gained by having a runtime DI layer that works such that it can be built into the entire platform so far outweigh the one-time tooling change that it doesn't bother me at all. The rest is a slippery-slope argument that I don't think is fair. If you trust Angular as a project, then you have to trust to some extent that they'll make sane decisions. Since this particular clever hack is the only one that won't get "better" over time as runtimes improve, I think that they deserve the trust so far.

AdrianRossouw 13y ago
DI is fine, i was just concerned that they have something that breaks as the first recommended way to do something. Much less that they have it at all. Minification pretty much counts as 'normal use' these days, as much as we all have a distaste for it, we really can't change it. You should watch the video on my post and tell me you are still comfortable with it doing that at runtime. And the slippery slope thing? I spent 10 years of my life building open source projects with thousands of contributors and untold thousands of users. That's experience talking there. My point was that you can't deny the sufficiently promising excuse to abuse it further, without admitting that it is flawed to begin with. My suggestion was that now that the ngmin exists, make that the only way to do it and remove all the crazy stuff out of the main execution. I also said that clever hack is the only one that could never get better. There's no standards path for it. They have been shown to deserve the trust. they are removing the hackiness from 2.0.
- apinstein 13y ago
  Great ideas! Sounds like we generally agree. I read the whole post but didn't watch the video or read all of the 2.0 stuff... though I am aware how their DI hack works. That said, the title of your post makes it sound like you think they're heading off a cliff, but your response to me sounds like the opposite... I was just responding to the tone set by the article. I'll also agree that it is frustrating early in the AngularJS experience to hit that minification bug. But it's easy to get over also.

jcampbell1 13y ago

This seems like a one-sided overthinking of the auto dependency injector (which is like 30 lines of code). 1. The auto DI means beginners can get to "Hello World" in angular without learning some wonky injector syntax. If Angular's goal was to bring some of the jQuery crowd on board, then it was a smart move. 2. The auto DI doesn't survive minification, so not all code can be copy-pasted, and there are two different syntaxes. Unnecessary complexity? I see no reason to make a bunch of analogies to argue on one side.

AdrianRossouw 13y ago
Are you sure you're not just under-thinking it? Those 30 lines of code require the hundred or so lines of ngmin to actually work correctly, and then results in the extra (im assuming) hundred or so lines of grunt-ngmin and all the tooling around that. And then all the tests, the issues for the main project and all of the related projects, every bug that anybody has ever faced with minification of angular apps. The auto-di is not that much simpler than the array format, and the array format is also actual valid javascript. They are abusing language features in such a way as to bypass the semantics of the language itself. The fact that it doesn't survive minification is a sign that you shouldn't really be doing it to begin with. There are 3 different formats, and one of them introduces some crazy magic into the main framework, that is all really unnecessary and could just be as easily avoided. Auto-Di is the 'wonky' format in any reasonable context, I'm afraid.

badman_ting 13y ago

I think DI in Angular should be an opt-in thing, too confusing otherwise. I've had moments where I thought I was just writing a regular function, and then Angular started throwing exceptions because it was trying to inject dependencies based on the argument names. (And the solution was to write a function with no arguments that returned the actual function with arguments!) There are conventions around what string maps to what thing, so that sometimes strings like "controller" or "provider" are inferred and not required to be specified. This is bad -- things should just be referred to by their full names. It would be nice to have the ability to ask for things directly in require-style function calls instead of having them be parameters to a function. It's actually sort of crazy that you can define a controller (for example) with angular.controller('MyController', function(){}), but then you can't ask for it back with angular.getController('MyController'), or whatever. All this makes it a lot harder to try things out in the console, and lengthens the feedback loop of determining what works and what doesn't. And I didn't even know about the minification thing. That is legitimately terrible.

johnny635 13y ago
You need DI to do unit tests properly.
- zwily 13y ago
  Isn't the problem Automatic DI, and not DI?

wprl 13y ago

I too think Angular is overly complex and "magical." The JavaScript world should be learning from the mistakes of monolithic and semi-monolithic frameworks such as ASP.NET and SEAM not trying to recreate them. For my part I'd like to see separate libraries for events, views, models, syncing models to persistent storage, and binding models to forms. Small micro-libraries allow maximum flexibility and efficiency, and facilitate more maintainable code. The way that Angular violates separation of concerns between presentation and view is another symptom of a monolithic approach, and a step backwards in HTML client software design.

Encosia 13y ago
I wish I could give this comment a million upvotes. From my perspective as someone who has developed on the MS stack for 15+ years, frameworks like angular and ember strike me as (retroactively) following right in the footsteps of Silverlight and ASP.NET WebForms. To be clear, I don't think that's a good thing.
- EricDeb 13y ago
  I think simplicity is undervalued in the programmer world in general. It takes so much more mind-energy for someone to implement/refactor/add-to/test complex code written by someone else as opposed to simple/verbose code.
  - AdrianRossouw 13y ago
    yeah man. when i subtitled my blog sensible complexity, I didn't realize that it was actually something I cared so deeply about.
  - frou_dh 13y ago
    > I think simplicity is undervalued in the programmer world in general. I imagine every programmer will claim to value simplicity. Trouble is, they're all talking past each other because their working definition is "the way I personally do things".

edanm 13y ago

While I do the think author makes too big a deal about this, I very much agree with them. The main issue is whether or not we should be teaching people, as a first brush with Angular, to code things with "automatic Dependency Injection", where the types are inferred from variable names. The alternative, and only way to code a "real" application, is to pass the names of things you want injected as strings. For people unfamiliar with Angular, this difference means turning: myFunction(Dep1, Dep2) into myFunction(['Dep1', 'Dep2', Dep1, Dep2) (more or less). Doesn't seem like a big deal, does it? But I think the decision to teach people the "bad" way to do things, all for the sake of making things "simpler", is completely wrong, and misunderstands what kinds of complexity people have a problem with. Complexity isn't telling people "write the same word twice, cause that's how it works". Complexity is telling people "here's another thing you have to learn about this framework". This is a small matter, but it isn't trivial, and is a common mistake with Angular.js (hiding the wrong kinds of complexity).

AdrianRossouw 13y ago
I'm only making a 'big' deal about this because I have given this serious thought. This is the third part in a series of articles where I was trying to understand why my intuition was telling me that there was something not quite right about angular. I finally managed to track it down to this specific little thing, and how the unintended consequences of a feature like this could have far ranging consequences to it as a viable platform. My reasoning was not about how crazy this is now (which it is), but how this could end up 5-10 years from now if it doesn't get removed now.
- ilaksh 13y ago
  Why would you expect Angular or any current platform to be relevant in 5 years?
  - edanm 13y ago
    Most platforms, at least major ones, ARE relevant for many years. Of course we have yet to see if Angular will be one of them, but it's looking like it will.

Bahamut 13y ago

I'm a huge fan of dependency injection, it makes life infinitely better when designing your code & testability. That said, I'm somewhat sympathetic to this complaint - it turns me off towards Backbone. However, I argue that it isn't nearly as bad as views with Backbone. In addition, this is changing in 2.0 with a much cleaner injection mechanism.

AdrianRossouw 13y ago
dependency injection is fine. just the magic argument detection wasn't a good idea. Backbone views has nothing to do with this, imo. The thing I miss the most when using backbone, and I use it a _LOT_, is observables. Binding and unbinding model events can get really tedious. Marionette really does help for that, but this stuff can still get out of hand.
- Bahamut 13y ago
  It does when it comes to not leaving your views in an ugly string representation of html - you use a build process of some sorts to get around that fundamental flaw so that you can still use a nice html template file. That alone was enough to sour me on Backbone, hence the comparison. This flaw in Angular isn't nearly as deep was my point.
  - iLoch 13y ago
    HTML is HTML, why does it matter what file type it resides in? All my templates are stored according to the view's type within my ./templates folder. If I want to include the HTML in an "actual" HTML file I can do that too. Have you even used Backbone?

klochner 13y ago

I still can't decide if angular dependency injection is more amazing or revolting. It's magic, it's non-intuitive, it breaks the standard paradigm that function arguments have no external significance, and it doesn't add much real value by just saving one extra line per function - inject(fn, ...) On the other hand, it's elegant if you ignore all the above criticisms.

AdrianRossouw 13y ago
just the inferred dependency injection. and it's warped. as i stated in my article. i don't mind the DI myself too much, but then, I also prefer commonJS =P

TempleOSV2 13y ago

You cannot club these niggers hard enough. I want to beat you, you're so stupid. Maybe it would help. retard nigger. http://www.nist.gov/itl/csd/ct/nist_beacon.cfm http://www.nist.gov/itl/csd/ct/nist_beacon.cfm ---- First, the Beacon-generated numbers cannot be predicted before they are published. Second, the public, time-bound, and authenticated nature of the Beacon allows a user application to prove to anybody that it used truly random numbers not known before a certain point in time. Third, this proof can be presented offline and at any point in the future.

ilaksh 13y ago

As far as the particular issue he picks on, he is making a big deal about something that's not, at least if you accept the general premises of Angular, and trying to pin the core of his whole argument on that. Which is dumb. Anyway, I have used many, many different UI frameworks on different platforms over the years. Including different .NET systems, Backbone, Angular and to some degree web components. And many other lightweight and heavyweight systems. I am actually amazed that developers are not immediately seeing the obvious advantages of Web Components (with Polymer for now). I am amazed that people are still trying to master AngularJS when we have Polymer. (At least the people who can tell their users to use a new version of Firefox or Safari, which is actually quite a lot of web apps these days, although obviously not all). Angular is very obviously more complex than necessary. Very few people are going to be with me on this, but this whole idea of separating out scope and avoiding global variables at all cost has got to the point where it is just ludicrous. And the only explanation is that this stigma about global variables has a religious and un-questioned association with incompetence. Unfortunately that particular cargo cult can lead to things like Angular DI. Why aren't more web developers excited about Polymer and Web Components? Because many web developers, despite experience with Angular, get distracted by DI and other over-complex topics and somehow fail to completely grasp the basic concepts and advantages of what a user interface component is and does.

grumblestumble 13y ago
Web developers are excited about Polymer and Web Components. However, using a product still on release 0.2 for building real-world, production apps is generally frowned upon by anybody over 16.
- STRML 13y ago
  I've built a few projects with Polymer, including this public-facing one (http://securesha.re http://securesha.re), which is a poster child for why you shouldn't use pre-alpha software (see the blown stack in the console; this was working just fine a few browser releases ago). Thankfully, it's not a critical app and it's more of a proof-of-concept than anything else. The source is available below [1]. It was a joy to build Secureshare with Polymer and it really made me rethink what an HTML element can be and what it can do. You have to unlearn years or decades of assuming that an HTML element has almost no useful API; with Polymer, you're likely to define many core application functions directly on DOM elements themselves. It's a lot of fun once you get used to it. <polymer-localstorage> and <polymer-media-query> really opened my eyes to what was possible with this new paradigm, and it is unquestionably cleaner than what has come before. More than anything, I'm excited for the inevitable deluge of web components; finally, UI libraries that can that be mixed and matched in any web application without regard for what other JS and CSS is on the page. True isolation allows us to create truly fantastic projects. [1] https://github.com/STRML/securesha.re-client https://github.com/STRML/securesha.re-client

meric 13y ago

The author is concerned about the future of Angular because of the idiosyncrasies of one method of including dependencies. I mean, really? Is it so bad, the stench of automatic dependency injection, it overcomes all other beneficial features of Angular, it would jeopardise it's future as a web framework, such that it would lose compatibility with future browsers and your web app built in angular will stop working, with no support available? IMO it's a bit hyperbolic to suggest this is the case.

AdrianRossouw 13y ago
no. i was worried about the fact that people weren't questioning the logic of it, and that once this kind of magic takes hold ... it's really hard to take it out again. Nobody said anything about future browsers and losing compatibility. I do think that if this kind of thing grows, the system will become complex enough that developers will move to different frameworks that do similar things but don't have all this magic and baggage.

grumblestumble 13y ago

- AngularJS is a tool for building complex single-page web applications, not brochureware. - If you're building complex SPAs, you're going to require a decent level of tooling. - If you have a decent level of tooling, the points in this article are meaningless. As an aside, ngMin is the most trivial thing in the world to set up, and if you can't figure it out, array notation is slightly painful but well worth it for all of the tools Angular provides.

camus2 13y ago

AngularJS is not complex , when I think complex , I think SpringMVC or Struts complexity. AngularJS has problems ,but complexity is not one of them, definetly. Seems like JS programmers who only know JS think they can get away with ignoring patterns like dependency injection, Guess what, in order for code to be maintainable and testable it needs it. Front-end is about GUI dev,and that's where OOP shines. It's high time for JS folks to read classics like "Design Patterns" books, and embrace SOLID principles , or AngularJS wont even help when developping their so called "fairly large" apps.

AdrianRossouw 13y ago
Nope. agreed. I just felt that this little thing was complex, and that something like this can spread over time. I had no issue with dependency injection either, just the magic format.