Angular 2 Survey Results
angularjs.blogspot.com There were about a half dozen responses for Dart and 1 for Closure Compiler.
In other words, at least 7 Googlers submitted survey responses.
Just because someone likes dart, doesn't mean they are from google. As an example I really enjoy dart, and I am not from google
It's a joke
Dartisans are sensitive. Trust me. I felt their wrath just two months ago.
OT: Is this supposed to happen on page load? [1] Not sure if it's intentional, but if it is, it's probably the most useless animation I've seen. Blogger's standard templates seem to get worse every month.
That would be Blogger -- it's loading the homepage and then loading the article on top.
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.
Who makes color-coded pie charts, but doesn't provide a color legend?
Do'ah. Valid criticism. We generated the pie charts from Google Forms (where we had the survey), but we didn't like they way they displayed the results (they were out of order). We should have added the color legend to our sorted results. I will add that later tonight after work. Apologies.
Not only that but the pie charts are all inconsistent about where they start and where the largest portion is shown.
Hey, UI Router lead dev here. I'm interested in any & all feedback people have regarding Component Router vs. UI Router, what they like/don't like, and whether or how much they'd like to see UI Router support for Angular 2.
By component router, are you referring to the stock router in Angular? If so...
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.
By component router, are you referring to the stock router in Angular?
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.
If you hold out on refactoring to UI Router until 1.0 is released, I'm pretty confident at this point that I can promise you a smooth upgrade path well into the future. (Come to think of it, I'm still pretty confident even if you start now on 0.2.x).
When UI Router 1.0(beta/stable) will be released?
Well, we're pretty close to an alpha release. [0]
After that, it's just a matter of users testing it and telling us what's broken, and us fixing it. A few weeks, maybe?
[0] https://twitter.com/ChrisThielen/status/638040557718126592
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) and in generating/validating ui-sref links. I don't know if this will get linearly worse with increasing size of application, but anyway this is why I'm interested in checking out Component Router.
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)...).
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....
Another ui-router dev here. I've also never profiled transitions for performance (frankly, I don't think I've seen it mentioned before). I'd love to hear anything else you recall about your findings.
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?
Just wanna say, huge fan of UI Router, thank you so much for your hard work! Makes my life so much easier :)
Same boat here. Really like UI Router. $stateParams saves me so much time.
Hi, I've been using AngylarJS & UI-Router for about 2 months. It's great. Some of the shortcomings that struck me were-
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).
Hi, ui-router dev here. 1.0 is adding a global transition error handler which you can customize. The handler will be noisy by default (log to the console).
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
> But there are use cases wherein you would want to transition to-fro controllers (eg. multi page form).
This is interesting. Could you post a GitHub issue describing your use case and an pseudocode example of how you'd see it working?
My vote is for the Angular team to stay away from ui-router because you are difficult to deal with, based on multiple discussion threads I've seen 'round the net.
Your code is good but not sufficiently better than component router to justify the friction.
You're right. Sorry about that.
Either way, thanks for the compliment on the code. :-)
I was really hoping this was a survey to Angular 1.x developers asking how annoyed you are that Angular 2 completely changed everything.
Angular 2 should have been a new framework, IMHO.
I'll defend ebbv
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.
v2 cemented the fact that I will never willing build another angular app. I have no interest in frameworks that do not provide clear upgrade paths.
The Angular team listened to the community and has been working on an upgrade path. I found this blog post useful in convincing my team that we are not going to be wasting time as long as we continue to follow angular and JS best practices:
http://angularjs.blogspot.com/2015/08/angular-1-and-angular-...
That would be a waste of a good brand name.
A friend also asked me to think of all the recruiters and managers who just placed thousands of Angular devs over the last year. How will they look when the C-level finds out that their team consists almost entirely of people specializing in an aborted product (oh, and their product is now locked-in to some now-aborted Google product)? My friend's point was that perhaps Google is just attempting to paper over any unpleasantries by sticking the old name on a different product.
yes but the changes allowed the framework to be the fastest out of all of ones currently right now as well as making sure it's more future proof
Not an Angular user, but I'm quite interested- what about it would make Angular 2 faster than Ember or React?
All the benchmarks seem to indicate that Angular 2 is vastly faster than the other frameworks - the Angular team has achieved O(1) change detection, which large DOM node benchmarks are remarkably consistent with in terms of Angular 2's performance. For large numbers of repeated elements, it turns out that Angular 2's performance is worlds away from even libraries like React. For more normal situations of smaller # of DOM nodes, Angular 2 still manages to outperform by around 3-5 times as fast - all the benchmarks I have saw was pre-web worker support though, so it may be even better with that enabled.
I don't remember Ember's performance, but React's seems to slow down significantly in jumps at certain marks, similar to Angular 1, which seems to suggest they have some at least one place where optimization could be made. It should be noted though that Angular 2 builds on top of many rock solid principles that React introduced, and has ruthlessly optimized upon that with continuous benchmarking and careful planning.
What benchmarks? You say all the benchmarks but provide no links and I know for a matter of fact that your statement is simply not true. Also, be wary of benchmarks, they tend to optimize one framework while leaving the other ones not optimized. Also to note, I've used React for very complicated things, even having to optimize under the 50mb limit in one tab and the performance did not slow down as you claim. I've been using React on a production app > 1 year. I used Angular 1.x before that.
And the only way I see every change detection being O(1) is using something like Immutable js or serializing the "state" and comparing strings.
Just by this blog post alone, it seems the Angular community is quite split on what they want. Wouldn't it make sense to just maintain Angular 1.x and start on a new framework, which would basically be Angular's version of React and Ember, with a new name. Performance difference will be negligible.
Where's your proof that is simply not true? Every talk where people have done actual benchmarks with has shown otherwise. I have also discussed benchmarking techniques with the main Angular developer in charge of them, as I noticed some statistical issues with the original approach when they started presenting them, and they refined ruthlessly from there.
Different people have presented on them - Uri Goldshtein gave a talk within the past month at the AngularJS Mountain View meetup where he personally benchmarked React, Angular 1, Angular 2, and one other library using Meteor with all of them, and the findings were very interesting - React started struggling around two marks, including around the 20k element mark (I may remember that number slightly wrong) & 50k element mark (which is a bit of a contrived benchmark IMO), but the remarkable aspect was how linear Angular 2's performance was. React's showed a more complicated picture, at times behaving like a quadratic. Angular 1.x also shows similar patterns, which is consistent with every benchmark people have presented in talks or blog articles. At large numbers of DOM nodes in a simple flat tree, most libraries showed issues - React would take over 3.5s to render at over 100k elements, whereas Angular 2 performs amazingly at under 100ms on the same test. Unfortunately, this talk was never uploaded due to Google having had video issues, but it looks like the findings were made available here: http://info.meteor.com/blog/comparing-performance-of-blaze-r... .
The Angular team has also done presentations on Angular 1.x vs. 2 - Misko mentioned in a talk in April that Angular 2 was already 2-10 times as fast as Angular 1, and they have made massive strides since that time. Other people have reported React being roughly 2x as fast in many situations, which is strongly suggestive that it does not keep up with Angular 2.
The Angular team has adopted immutable data structures internally I believe - they have talked about it at ng-conf and numerous times afterwards, and Victor Savkin has written an article on it here: http://victorsavkin.com/post/110170125256/change-detection-i... . They using observables to handle this in Angular 2 .
Out of curiosity, what would you say your experience level is with Angular 1.x? (based on the criteria in the survey)
It's a new framework, hence the major version bump.
Seems like 2.0 is the worst of both worlds: little/no continuity from 1.0 and little/no benefits of starting from scratch.
Did you see the blog post from last week on Angular's efforts to help developers transition from 1 to 2?
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.
At a first glance the link you provided promotes double insanity: angular 1 mixed with angular 2 (because angular 1 was not complex enough when angular 2 decided to simplify it with new syntax and requiring typescript which seems to require node.js). Is there some documentation for angular 2 with plain javascript (no typescript) for people who want to keep it simpler ? Can you provide some links ? Thank you.
Each code sample here has an ES5 ("plain javascript") version that you can get to with the buttons on the top:
if you consider a "node.js" requirement (read: a build step) too complex for your projects, you're probably correct in that you don't need any version of angular, react, ember, or anything else.
Complex or not, I don't care. I don't want to install node.js and npm and that's it. If I know the names of those two apps is already too much.
It's a shame that jQuery was included within "What frameworks other than Angular 1.x do you use regularly today? (choose multiple)". Why not throw lodash/underscore in too?
I can kind of see how jQuery + mainstream jQuery usage patterns would get grandfathered in as a sort of ad hoc, primordial framework.
Because they are libraries, not frameworks.
And jQuery is... surprise! A library.
It does have some framework properties, like the whole plugin mechanism.
That barely qualifies imo. The plugin mechanism is just prototypical inheritance - you're just adding methods to a prototype, nothing more.
Typo: "Meteor 9.7% 1967" has an extra digit, since 1967 would be far above 9.7%. I'd comment on the page, but comments are limited to team members. Also, why even show the option for comments if I can't make them?
Shoot, yeah, you are right. I am one of the authors. I just updated this, but it looks like the page is cached so will take a couple minutes for it to correctly show 196.
Quite the slap in the face for Dart, damn.
Hopefully we didn't come off as too harsh. We were more poking harmless fun than trying to criticize. The Googlers I know that use Dart love it and swear by it.
So much fragmentation in all those answers.
Blogger's mobile template has chopped off the left side of the page so the first two letters of every line are hidden, making this virtually unreadable on mobile. Thanks blogger mobile template!
Fixed now. I am not a fan of blogger.
Angular 2 can't come soon enough! The ability to move heavy diffing processes to web workers is what I need. Change detection for large number of DOM nodes is slow and inefficient in Angular 1.
Awesome survey! I develop with AngularJS and I thought it was interesting that TypeScript pulled away, I've been hearing more and more about it. I hope you guys do a follow up so we can see if anything changes.
Unrelated to this specific survey, but as somebody unfamiliar with Angular, having both angular.io and angularjs.org with neither making the version difference clear at a glance is confusing as heck.
In the Features analysis section, points 5 and 6 have the same heading, Dependency Injection. Should point 6 be Server Rendering or something similar?
Yes. Updated now. It should have read "6. Server Rendering"
Wow, very informative!
thanks! :)
It's funny how so many development communities feel like they need to start over and create an entire new framework.
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.
> PHP [...] at least allows you to run 4 code on the 5 interpreter with no issues
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.
Yeah I remember occasions when PHP x.y.z patch releases would break existing code.
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.
It's definitely a risky move as your examples demonstrate, but aren't most of the Angular core developers working for Google? I don't think they have an interest in generating more consulting work.
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.
There is a big, big difference between Angular and the other frameworks you mentioned. Angular is part of a larger ecosystem (i.e. JavaScript) that is going through massive changes on its own (i.e. ES6 and all the other new JavaScript goodness). Angular can stand pat and do nothing while the world around them changes, but that is probably not the best strategy either.
PHP breaks things all the time (just check the migration guides for any release), but the difference is that they break only what they must, and deprecate things in a timely way so you can evolve your codebase instead of having to rewrite it. Other platforms tend to see a broken piece that needs replacement as a good opportunity to redesign everything else as well, even the stuff that worked fine, and don't put as high a value on easy migration paths.
Ofcourse, that's also one of the reasons PHP has so much ugliness still.
You have no idea what you're talking about.
Yes, yes I do. All of the examples I gave come from actual experience. You also added absolutely nothing to the discussion.