Complexity Creeps: Why I'm Concerned for the Future of Angular.js
1–10 of 59 posts
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#2This 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 acknowledged the issue, saying it was no longer part of angular 2.0
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#3It 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:
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.
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#4It'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.
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#5This 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.
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#6I 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.
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#7It'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…
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.
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#8It'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…
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…
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.
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#9I 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.
Re: Complexity Creeps: Why I'm Concerned for the Future of Angular.js
#10Earlier quoted context omitted.
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…
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…
Yeah. I was mostly concerned about the fact that nobody was pointing this out.
If you read the [1] previous post you will see that I am remarkably positive about it. My concern was that the answer to working around the DI hack was always "dont do that".
Even ngmin is just a really elaborate way to 'dont do that'. With it's own issue queue and grunt plugin and almost 22000 hits on google.
From working on open source for a long time, I know that existing code also sets precedent. And i couldn't think of any way that you could keep using that code for the next 5-10 years without somebody thinking of something else 'clever' to do with it.
They devs realized that though, without me. which is great news. You are in awesome hands imo.
[1] http://daemon.co.za/2014/03/why-wrong-to-be-afraid-angular