I think as one uses Angular more, a person will move most of their code out of `ng-click` style directives into their own components which might include click handlers on them.
This is an example for brevity but certainly misleading if you're not familiar with Angular. You're right that this is typically an anti-pattern, but it's one that Angular tries to eliminate, even though it is using a similar looking mechanism. Angular controllers expose an API for the widget they enclose, but it leaves the wiring up to the designer. Sometimes it makes sense to sprinkle event bindings onto the DOM via code, but there are many cases where it doesn't. My code almost never needs to know exactly what element(s) are bound to a method, so it makes sense to me to just declare that stuff right in the document.
As a side point, you can't evaluate arbitrary JavaScript in Angular attributes. Angular parses the attributes and evaluates them as in a JavaScript-like way, but with some exceptions. See http://docs.angularjs.org/guide/expression
Didn't we learn that static files for serving websites are so uncool many many years ago and stuffed the content into databases and served off them? And what is seeing a great resurgence these days?
More things change, more they remain the same.
PS: I am not saying JS in attributes is a good thing, but just that these things keep happening, for good or worse.
I'm pretty sure the linked site is using code inside ng-click directives for illustrative purposes. It makes documenting and demonstrating the project much easier.
This is a bit tangent to your question, but, I think you can still run with ng-click if you deploy Content Security Policy, whereas onclicks will be banned.
Definitely similar problems, but in a somewhat different way. This library looks more featured than Angular UI Bootstrap, though in mostly small ways.
The popovers allowing external templates and custom scopes is one example, and the inclusion of navbars, date and time pickers instead of pagination, accordions and carousels is another.
If it works, I'd say I like it more than Angular UI's version, which is probably simpler to get up and running but something that you'd run into the limits of more quickly.
UI Bootstrap does not depend on AngularUI. It's just a set of Bootstrap directives built by the AngularUI team.
The main difference between the two seems to be how they handle templates. UI Bootstrap has a set of default templates that can be overwritten, whereas AngularStrap doesn't. AngularStrap also includes date/time picker directives.
I don't believe ui.bootstrap actually depends on angular-ui, the project is just rolled into angular-ui's brand/github org. They could probably be more clear about that.
All three of them (angular-ui, ui.bootstrap, angular-strap) have been a pleasure to work with.
Can we please stop posting links to this project? It's a really good example of how not to write Angular code.
The (official) AngularUI project has a much better solution (as has already been linked to in previous comments, but I feel the need to re-iterate): http://angular-ui.github.com/bootstrap/
1) Size and dependencies. Let's say you want to use buttons directive. If you decide to go with angular-ui/bootstrap you will need this https://github.com/angular-ui/bootstrap/blob/master/src/butt... only - 62 LOC. If you decide to go with Strap you will need jQuery + 100 LOC of Bootstrap's JavaScript + 163 LOC of Strap's wrapper (!!!). Please note that the the wrapper itself is _longer_ than the original version. Native version is 1/3 of the size (!).
2) Customization - try to change a template for say, a typeahead. With the strap solution it is hard-coded in Bootstrap's JavaScript, no way to customize. With angular-ui/bootstrap template is here: https://github.com/angular-ui/bootstrap/blob/master/template... and is fully customizable
3) Integration with the AngularJS ecosystem - since anngular-ui/bootstrap directives are native ones they seamlessly work with all the AngularJS goodies like $q promises. This means that you can provide a promise as a source for, say, typeahead or data for modal.
4) wrapping existing jQuery plugins is not always obvious as lifecycles are really different. As the results you need to do hacks - just search Strap's code for setTimeout and $timeout to see what I mean.
At the end of the day just choose a project that works for you but we've started angular-ui effort since we believe that native AngularJS directives offer much lighter and cleaner solution.
Just a wild guess (just looked at the first snippets quickly) but it looks like AngularStrap generate itself the html (for the dropdown for example).
It's not neccessary (bootstrap HTML is pretty straightforward) and it prevent you from doing a lot of things like custom html inside dropdown menus (icons, ni-click, etc).
So IMO, It abstract the things at the wrong level (too high)
AngularJS is very interesting, simple and powerful, but can anyone give some insights of how to properly use it for just a part of the website? I don't want to have JS only webapp, but to serve full server-generated pages. Or maybe it's wrong tool for the job?
It works just fine for that purpose. Just include angular.js and add an ng-app and ng-controller directive to a div you want angular to be concerned about and you're on your way. We are going to transitioning our javascriptMVC app over to an angular.js app piecemeal by following the same strategy.
We have been using it quite successfully for a interactive application. Independent of Angular Bootstrap we have made our own reusable widgets for common and generic components such as modals.
I actually haven't thought of using it for static pages but that poses an interesting experiment to try with my blog. It could bridge the gap often seen with non-interactive pages - mainly caching on S3+CF and yet wanting to pull in a Twitter feed.
