Great questions, thanks.
> We started using ui-router recently and from quick profiling of rendering it looks like a lot of time is spent in ui-router transitions (chained promises)
I've never profiled transitions specifically, but the number of promises is generally determined by (a) how many templates you have in a target state, and (b) how much asynchronous data (resolves) each state loads.
> and in generating/validating ui-sref links.
State names themselves are validated once on initial template load. If the target is parameterized, we do set up a $watch() on the parameter values to update the href, which is a small incremental perf hit per use (and you'll naturally tend to get more churn the more deeply-nested the scope in which you use them is).
> Do you have any pointers to differences between Component Router and ui-router? I'm especially interested in pitfalls of both.
The biggest differences that I'm aware of are:
- Component Router supports components (naturally), which UI Router does not (this is on the roadmap)
- Component Router's transition pipeline appears to be more flexible than UI Router's (we're refactoring heavily to encapsulate & expose more APIs)
- As with ngRoute, Component Router's configuration binds view components (or controllers/templates in ngRoute's case) directly with URLs, whereas UI Router provides a more sophisticated abstraction in the form of a hierarchical state machine, which many people find more ideally-suited to large, complex apps (see other comments)
- UI Router provides more sophisticated abstractions for encapsulating and modeling your domain in terms of URLs, for example, Type objects [0]
> I haven't debugged ui-router much yet, but maybe I'm doing something wrong
Let me know if you encounter any specific issues, or post to StackOverflow. One or more of us are usually fielding questions there.
[0] https://angular-ui.github.io/ui-router/site/#/api/ui.router....