gistfile1.md

Thoughts on Angular

Overall, very impressed by how far the have come in the last year and a half or so. They have addressed probably the biggest issue I had with it last time I looked (how clunky it was to create even simple directives), the community is MUCH larger then it was, which has mitigated the second biggest issue (insufficient documentation)

The things I don't like thing is kind of big, but thats because its a combination of "dont like" with "don't understand" and "doing completely wrong", and at this point I don't really know enough about it to tell the difference :)

Things I Like

• The view reaching into the JS means there is a class of wiring up / coordination code that doesn't need to exist.

• In general, it gets away from being "Object Oriented" style, which pretty much everything else does, which feels like less fighting the language to me. Units of behaviour are usually functions instead of objects (or methods), and you can go surprisingly far without the lack of a class abstraction even coming up.

• While being a heavy framework, the framework doesn't intrude that much in application code

• Having an IoC container is great

• Each component is very testable

• E2E testing looks like a promising alternative to capybara testing

• since not everything is a component, it means parts of the page tend to be coarser grained, which means that the html tends to live in larger chunks. This is highly dependant on how many directives you extract though.

Things I don't like

• by far, the most problematic part of the framework at this point is the routing. The implementation is just as bad as backbone (rails style pattern matching), with the added constraint that routing can only affect a single ng-view on a page. angular-ui looks like it has a tonne of promise, but there are big warnings in the documentation about how early the project is. This probably wouldnt be a problem with the way we have been building the JS stuff in packman, but it has big implications when writing a single page application.

• by definition, you can't write clean html. You usually end up not clean html anyways for other reasons, but it means giving that up as a goal from day one which kind of sucks.

• controller scope is inherited from its parents, which means any controller property is pretty close to global state. This means you can easily have non-explicit coupling between controllers and their ancestors. I have no idea how big a deal this would be in practice. I could see it being less of a big deal if you keep the controllers very coarse grained (never nest more then 2-3 of them), but even at this point I find I am hitting 3 levels of nesting pretty easily.

• directives are much easier to write now for the 90% case, but dynamic templates are still kind of nasty to implement.

• I am probably misunderstanding modules, but they seem to mainly be a way to share code between projects. They start when they load, can't be stopped, and they register their resources globally. I have a feeling I am not fully understanding their purpose, or missing a key piece on how to use them. Given that they are called "module" I would expect them to encapsulate or represent SOMETHING….

• I am really not sure how to implement complex interactions between different parts of the page. Looking for an equivalent to victors "supervising presenter" post.

Agree with you about most of the things.

On routing
They admit that right now it is super limited and you need something more advanced for serious applications. Angular UI looks promising and they praise it at all events, so I suspect it will get some love soon. You can use other routing libraries (the one from Ember guys seems pretty cool). I was thinking how to do that and it seems pretty straightforward.
It’s not a big deal for Packman, cause we tend not to care about routing within a page.

Clean html:
Html tends to have more application concerns, but less meaningless classes. Overall I agree that html becomes not just markup but the whole view layer. I can see how it can be viewed as a bad thing, but it is debatable.

On scope:
Named controllers (angular 1.2) make the situation MUCH better. I use them and don’t use implicit scopes.

On directives:
Not sure why dynamic templates are nasty to implement, but we can chat about it.

On modules:
Modules are a more complicated topic. They are not fully utilized right now and kind of limited. We can chat about them too.

On complex interactions:
I was thinking about that and I think there are a few ways how they can be modeled (including Supervising Presenter).

@vsavkin

HTML

at the end of the day, html never ends up WITHOUT application concerns, so that as a goal is pretty unrealistic. I don't like giving up before you start, but if you take into consideration you never end up in a good place anyways, and you look at the benefits to moving the logic into the view, its totally worth it. I don't LIKE it, but its worth it :)

Routing

I'm going to try to bring the angular-ui router in and see how it goes. Would be really interested to see how the ember statemanager can be brought in too. I wouldn't be surprised if the angular framework really beefs up its router, whats there right now is kind of a joke.

Scope

Going to start using the "as" keyword. IMO it should be required, or at least have an option to make it required. The default inherited scope really scares me

Modules

Is there anything on the internet on how they can be used? All I can find is people talking about splitting their code up into pieces, which is good, but there doesn't seem to me to be any sort of practical benefit (other then not having to reference the base module in sub modules)

Complex interactions

Super interested in what you are thinking. All I can think of is either explicitly calling methods on outer controllers (not super good), or using event emitters, which I dont think would be great because the wiring up would be all over the place.