There were about a half dozen responses for Dart and 1 for Closure Compiler.
In other words, at least 7 Googlers submitted survey responses.
I can't imagine why, though. The loading gear on page load is infuriating enough, and now there is a giant sliding page too.
Frankly I'm leaning towards avoiding all blogspot.com domains from now on, these silly things are more annoying than anything else.
UI Router is basically what made Angular viable for 2 massive projects I've done. How it isn't a core part of Angular yet, blows my mind.
Component Router will be the stock router in Angular 2, it is supposed to fix most of the problems with the Angular 1 router.
I've personally held off refactoring my Angular 1 routing code to UI Router because I didn't want to do it again once Component Router is released for Angular 1.3, oops I meant 1.4, oops again I think I mean 1.5. But I am starting to reconsider.
Do you have any pointers to differences between Component Router and ui-router? I'm especially interested in pitfalls of both.
I haven't debugged ui-router much yet, but maybe I'm doing something wrong (which sometimes happens in Angular world, e.g. when people use $timeout(fn), when in given situation they should actually do $timeout(fn,0,false)...).
> 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....
As for the ui-sref, there should be only one watcher per, and should only really impact perf if the target params change. Does that align with what you remember seeing?
Lack of "routing state" - integration with the history API or means to go to "previous" state etc.
No clarity in handling errors from "resolve" - Since there is no controller any failed AJAX request fails silently.
Ability to pass data (not params, more like a model) between states. This I think sparks the debate of having services to share data. But there are use cases wherein you would want to transition to-fro controllers (eg. multi page form).
To send data in a transition, add a non-url param to the target state. We added objects-as-params (url based or not) in I think 0.2.12
This is interesting. Could you post a GitHub issue describing your use case and an pseudocode example of how you'd see it working?
Your code is good but not sufficiently better than component router to justify the friction.
Either way, thanks for the compliment on the code. :-)
Angular 2 should have been a new framework, IMHO.
I have no intention of migrating V1 apps to V2 - it would be a waste of time and money.
And until I see real world examples of V2 performance or adoption, I'll continue to use V1 due to the incredible amount of 3rd party code that works with it - which I'm assuming, is alllll gonna need to be re-written to work with V2.
What if PHP 7 broke all backwards compatibility with PHP 5 unless hacks were used. The world would be un an uproar (if not all the Wordpress devs out there)
I was late to adopt V1 - I'll be late to adopt V2.
http://angularjs.blogspot.com/2015/08/angular-1-and-angular-...
As for little/no benefits, that is certainly not true. Angular 2 is going to be better in almost every way from Angular 1 and there are many great apps built off Angular 1. If you haven't tried Angular 2, I suggest giving it a go once the they get to beta.
Perl 6, PHP 6 (which was never released), the disaster that is Python 2/3 (many standard libraries were renamed breaking a ton of libraries, and now Angular.
PHP, which is hated by many here because it isn't hip, at least allows you to run 4 code on the 5 interpreter with no issues.
When Microsoft did this with VB back in the 90s, which caused DLL hell, the community raged. Now it's a normal part of development.
I feel like it's only about the money. Many open source communities make money on support only and can charge companies lots of money to make the shift. It also means tutorials, books, speaking engagements, etc.
Speaking as someone who at one time made a living porting PHP4 code to PHP5, that's not even the same ballpark as reality. No non-trivial code base made that transition without effort. But it is of course possible to write code that runs on both versions, which may be the source of the confusion.
Guess why all cheap web hosting companies only offer ancient versions of PHP? "I downloaded $crap from teh Internet and it doesn't work" is nobody's favourite idea of customer support.
If I were to think of a scripting language (to exclude C) that has kept backwards compatibility well, I think Perl 5 has done a decent job. Fifteen year old code bases is at least within the realm of possibility to get up and running, and the language has evolved quite a bit in the meantime.
Sure it can be possible to run PHP4 code on PHP5, but only AFTER you have tested and debugged it on the newer PHP version.
Angular was arguably the state of the art for a while. I suspect the core team would rather pursue that position again than spend years focusing on legacy support.
I'm not terribly familiar with the perl, php, or python communities, but my understanding is that a lot of the changes made were to "fix" things and "clean up". Aka, there wasn't a "I need this to get my job done" reason to upgrade. On the other hand, client side development has progressed rapidly since Angular 1.0. Things like isomorphic javascript just won't work with the old APIs.
Ofcourse, that's also one of the reasons PHP has so much ugliness still.