Live data from Hacker News

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

daemon.co.za

11–20 of 59 posts

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

#11
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).

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

#12

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 map…

You need DI to do unit tests properly.

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

#13

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 map…

You need DI to do unit tests properly.

Isn't the problem Automatic DI, and not DI?

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

#14

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…

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.

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

#15

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 2. why i was wrong to be afraid of angular.js 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 ack…

>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....

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

#16
post #11

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…

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.

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

#17
post #15

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 2. why i was wrong to be afraid of angular.js 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 ack…

>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 the…

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.

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

#18
post #15

Earlier quoted context omitted.

>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 the…

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 t…

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

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

#19
post #9

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 f…

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.

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

#20
post #18

Earlier quoted context omitted.

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 t…

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

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-brow...

Post reply on HN