Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

daemon.co.za

Post reply on HN
Print view View original

31–40 of 59 posts

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

#31

Post by frou_dh »

AdrianRossouw wrote: post #30
frou_dh wrote: post #28

Earlier quoted context omitted.

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

maybe, except that I try to improve how I do things on every iteration. i've been finding that it helps me to think about these things in a more concrete manner, so that i can vocalize to myself what I didn't enjoy in the recent experiences.

I found Rich Hickey's dissection of simplicity to be dynamite as usual: http://www.infoq.com/presentations/Simple-Made-Easy

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

#32

Post by Bahamut »

AdrianRossouw wrote: post #27
Bahamut wrote: post #24

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.

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.

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.

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

#33

Post by etherealG »

frou_dh wrote: post #31
AdrianRossouw wrote: post #30

Earlier quoted context omitted.

maybe, except that I try to improve how I do things on every iteration. i've been finding that it helps me to think about these things in a more concrete manner, so that i can vocalize to myself what I didn't enjoy in the recent experiences.

I found Rich Hickey's dissection of simplicity to be dynamite as usual: http://www.infoq.com/presentations/Simple-Made-Easy

spot on. his way of putting it that simplicity is objective and ease subjective really nails it. most people say simple and mean easy.

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

#34

Post by wbillingsley »

AdrianRossouw wrote: post #25
wprl wrote: 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…

How I feel about angular now is that it's a vision of what web development could be like in the future. A lot of this stuff only really makes sense once the entire environment is present. Polymer is actually fairly similar, but trying to tackle the problem from a different angle. It has the potential to do less in the future, and I think right now it's an interesting proving ground for and ideas and teaching people t…

Thematically, I'd say Angular's dependency injection is "supposed" to be resolved by the tooling. If you look at Angular.dart, it doesn't have this particular hack because it uses the type system to resolve what to inject. But Javascript doesn't have static typing... "specify it twice (as a list of strings, and then a list of arguments)" is a fairly ugly and error-prone solution. Specify it once and let the tooling do the work seems like a reasonable idea.

I tend to find that most of the awkwardnesses I come across in Angular likewise come from the underlying nature of Javascript and HTML. As a concept, Angular.js seems to me to be fairly straightforward -- client-side compositing of templates against data (without imposing constraints on the type of data), plus routes and a promises library for http calls.

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

#35

Post by adambratt »

carsongross wrote: post #3

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/ 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 che…

I just created a post about this on StackOverflow...

Awesome!

http://stackoverflow.com/questions/22386214/whats-the-best-w...

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

#36

Post by cmbaus »

grrowl wrote: post #22
wprl wrote: 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…

One of the first things that "broke my brain" when starting with Angular.js (during its wild 0.x days) was inferred injection — I know Javascript. I know how arguments are passed. What the fuck is happening here?? At that time documentation was sparse and often incorrect, but I'm very glad they're moving to a more predictable and sane DI model.

I had this exact experience yesterday.

I was reviewing the code spit out by a Yeoman generator, while reading some Angular docs (admittedly out of order), and I has confused about how variables were being defined. I finally read something that explained what to do (add a variable using a specific naming convention to the function declaration). I realized the framework was doing some sort of backhanded meta-programming, and I didn't feel so bad for not understanding what was going on.

The problem with this is you can be a pretty knowledgable JavaScript programmer and still not understand the code or the documentation. For this reason, I've never been a fan of meta-programming in general. Not only do you (as an application programmer) have to understand the language as defined, you have to understand other frameworks' reinterpretation of the language. If you bring in multiple frameworks that do this, it quickly becomes more difficult to reason about what a program does by simply reading the code.

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

#37

Post by AdrianRossouw »

wbillingsley wrote: post #34
AdrianRossouw wrote: post #25

Earlier quoted context omitted.

How I feel about angular now is that it's a vision of what web development could be like in the future. A lot of this stuff only really makes sense once the entire environment is present. Polymer is actually fairly similar, but trying to tackle the problem from a different angle. It has the potential to do less in the future, and I think right now it's an interesting proving ground for and ideas and teaching people t…

Thematically, I'd say Angular's dependency injection is "supposed" to be resolved by the tooling. If you look at Angular.dart, it doesn't have this particular hack because it uses the type system to resolve what to inject. But Javascript doesn't have static typing... "specify it twice (as a list of strings, and then a list of arguments)" is a fairly ugly and error-prone solution. Specify it once and let the tooling d…

"specify it twice (as a list of strings, and then a list of arguments)" is going to result in localized errors, in your own code, not spread through all 7 levels of dante's museum of abstractions.

Doing it at build time is also preferable to trying to do it at runtime, like it does now.

I would agree with your assessment, otherwise. I just think that this specific technique was railing against JS a bit too much, and was ultimately a dead end.

Interestingly, the new DI framework also uses ES6 and traceur.

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

#38

Post by klochner »

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.

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

#39

Post by AdrianRossouw »

klochner wrote: post #38

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.

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

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

#40

Post by calinet6 »

EricDeb wrote: post #21
Encosia wrote: post #19

Earlier quoted context omitted.

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.

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.

You're right, simplicity is undervalued.

The problem is, simplicity is often not a possibility. The problems we're solving are complex, not simple. Simple solutions to complex problems are to be sought after and cherished, but they are also incredibly difficult and idealistic.

Instead, we value pragmatism. We favor structure which simplifies, rather than structure that is simple in itself. We do this because it increases our productivity in solving highly complex problems; problems that simpler foundations would not support or would not assist.

Angular simplifies, hands down. It does this by swallowing the complexity into itself, and dealing with it in some rather intelligent ways so you don't have to. This, above all, you need to understand to use it effectively. Some complexity leaks; a great deal of it is contained and managed well.

You may love a handsaw and hammer and nails for their simplicity and clarity, and there is merit to that, but they can only build so much so quickly.

Angular is not a combination of those simple tools: it is more like a 3D printer, enabling you to build components of things and use them to make final products as fast as you can dream them up. It knows what it is, and so should you. Please excuse the lofty analogy.

Post reply on HN