Regarding point 7.1 - sometimes in my experience, an application might have many elements inside of an ng-repeat which cannot be avoided. It is one thing to say keep your lists small, but when you're dealing with a whole bunch of data that is loaded in via an infinite scroll, you can't just stop the content at 50 results.
Honestly, the only solution the team I currently work with have come up with is using React.js (swapping out Angular for React completely would be too expensive). If you take the heavy UI work away from Angular and use React.js, it honestly makes your lives easier. Even just for rendering a whole lot of content inside of an ng-repeat, you will see the performance issues vanish. Using track by in your ng-loops will also save you more migraines.
Don't get me wrong, Angular without-a-doubt has some issues, but there hasn't really been an issue that the team hasn't been able to work around so far. Most issues you encounter in Angular are caused by a limited understanding of the framework and its strengths. The documentation is pretty bad, but you find the more you use Angular, the better you get at it.
Most of the limitations you encounter in Angular, they are in every single other front-end framework as well. This is because browsers currently do not support some of the niceties in ES6 and many of us have to support older browsers like IE9, etc. But even so, ES6 won't fix everything, but it will make things a lot less painful. Things are getting better, but front-end frameworks are just a little too ahead of their time at the moment.
While Angular has issues now with performance (mainly two way binding and watching) when ES6 is supported in Angular 2.0 and object.observe() is used, we are going to see a dramatically more powerful framework without all of the dirty checking Angular currently has to make binding and watching work. This will be the case for other frameworks like Knockout and Ember as well.
Am I the only one not holding my breath for Object.observe? I see people mention it so casually, but the fact is it's still a long way from being anywhere close to production ready[1]
[1](http://kangax.github.io/compat-table/es7/#Object.observe)
Even once it's widely available, it'll probably take a long time to optimize.
There's a discussion about it here: https://github.com/angular/angular.js/issues/3601
On a personal note, after using angular for around two years... You can write good angular code, but in my experience, a lot of people (especially libraries) are writing really bad stuff. I've been playing around with this whole Flux+React ecosystem and I'm starting to think the patterns it presents are more sensible.
On top of that, this whole magic of two-way data-binding is certainly cool and fun, but I noticed that for most cases I know exactly when a value is changing, so notifying of a change manually is not a big deal (even if it's more work, it usually brings good performance). I'd be really happy if angular had a built-in way of doing something like event-based bindings. Right now we have regular bindings, and one-time bindings. I want a way to bind to a property where it'll wait for the property to stabilize and then remove the watcher unless I manually notify it that it changed.
So here's a trivial example: let's say I have a Stack Overflow styled app. When I open a post, it'll load the title, question, and answers. Now I could use one-time bindings so the title and question aren't being watched anymore. But I know that after loading this page I could receive a websocket notification that the title has been updated. I'm going to have to keep a watcher on the title even though it can only change in that one condition! It'd be great to just have something built in to handle this. (And I can think of many ways to solve this, such as making my own directive in which I add a listener for an event and then update it manually; but it'd be great if we had a built-in solution.)
...by removing it and using something bespoke and lean and simple instead!
Once you understand how Angular works internally and not just in a tutorial sense, it can be very powerful. Most of Angular's quirks can be worked around using common sense, and as in some cases, using the right tools, understanding Angular isn't a silver bullet goes a long way too. The issues my team encountered won't be encountered by everyone, we were dealing with potentially thousands of items being in the page caused by infinite scrolling.
I get that some people think Angular is difficult, learning the basics is easy, learning how to use Angular the right way is the hard part. I think a lot of the issues people encounter using Angular are due to their own limited understanding of the framework. The documentation leaves a lot to be desired, but there are a lot of good blog posts out there like this which tell you upfront the issues and best practices.
The beautiful thing about Angular is that it is not difficult to get it to shows its warts, so you can work around or fix them. Combined with Batarang, you can get a pretty insightful look into your application and where you can improve it as well. A lot of the issues we've encountered were due to the fact someone on the team did something wrong expecting it to work, not Angular itself. Like a good woodworker, you've got to go with the grain, not against it.
I think if our application were being built from the ground up today, the team unanimously agrees that we would use something like React + Flux. But in our case, the business wouldn't be too happy with us throwing away old unit tested and battle-tested code in favour of something new and lean for the sake of a few milliseconds of browser performance.
You should be able to get at least 100-200% speedup...
I read it many times, but when i compare it to the "little" Tools i write for my company, it seems that this "large" Applications are really really tiny.
So what did you understand under large Applications?
Another metric I go by is there is no one on team have overlapping knowledge of the code base. In other words, no other teammate is suited to review your code because they have no context of it.
I think a decent definition is "software where no one person has the whole system in her head", i.e. where reading existing code takes as least as much time as writing code, and any change may have unforeseen ramifications on the system as a whole.
But i actually think you're on to something.... WILL IT SCALE?! Find out in next weeks episode...
>>> The second reason software is slow is known as space complexity. This is a measure of how much 'space' or memory a computer needs to run your solution. The more memory required, the slower the solution.
Requiring more memory doesn't make an application slower by default. It simply means it requires more memory to run as expected.
Similarly, when he's talking about run time complexity, he calls it "a measure of how many comparisons a program needs to make to achieve a result". It can be any action, not necessarily a comparison. Be it number of times cycle needs to be executed, number of expensive calls to external service, etc. Number of comparisons to make is commonly used in introductory courses when studying sorting algorithm but doesn't make much sense without a context.
> 6.2 Watching Functions
>
> Another common problem is the utilization of functions
> in watchers or bindings. Never bind anything (ng-show,
> ng-repeat, etc.) directly to a function. Never watch
> a function result directly. This function will run on
> every digest cycle, possibly slowing your application
> to a crawl.
You don't want to watch a slow function, but just watching a function will not "[slow] your application to a crawl."
Interesting post, but I'd take this author's advice with some salt.
On a cacheless system, that would be true. On a typical system with multilevel caches (and an application that does not fit completely in the smallest one), the number of cache misses will tend to go up as the memory usage increases, and that will affect performance. At the extreme end, when it's too big to fit completely in physical memory and the swapfile starts being used, the speed difference becomes night and day.
> services and object references to propagate object changes between scopes.
There are so many ways to wire things up in Angular -- references, watches, broadcast/emit -- that I'd love to see some examples from the author, who seems to really know what he's doing.
For example, say I have a `userService` that maintains a small `user` model with username, name and roles properties. What's the most performant and maintainable way of "binding" to changes to this object so when I call, e.g.: `userService.logout()` somewhere, some component I write can pickup the change and adjust it's state / UI accordingly?
Reacting to the specific event would likely waste less resources than pulling out the $watch or $watchCollection sledgehammer.
[0] https://stackoverflow.com/questions/14333857/how-to-master-a...
[1] https://egghead.io/articles/new-to-angularjs-start-learning-...
The best resource I found was using ng boilerplate.
For example, given a service in charge of dealing with the a part of user's data. All mutations should be done through the helpers given by the service and then it should emit an event telling everyone subscribed to deal with it and update themselves.
Doing it this way, you maintain much more sanity when you have to create a really reactive application.
for(var x = 0; x < 100; x++){
var keys = Object.keys(obj);
sum = sum + keys[x];
}
I've been developing with React for the past several months and the idea of going back to Angular is already painful.
I've been looking for opinions on why Angular would be preferable to React. I haven't found any; can anyone else who's used both comment?
$scope.$watch()ing large arrays unnecessarily will be the death of you
Using ng-show where there is complex render logic in that element, consider ng-ifs to remove from DOM completely
Using track by in ng-repeats can help
We had simple screens which would hide any symptoms of bad practices but once you have an 'overview' screen with 10 different lists, many different show/hide forms etc the page can get slow very quickly.
http://www.codelord.net/2014/04/15/improving-ng-repeat-perfo...
http://www.bennadel.com/blog/2556-using-track-by-with-ngrepe...
https://www.exratione.com/2013/12/considering-speed-and-slow...
My impression is that Angular-specific issues are way more important than pure Javascript speed concerns in terms of relative impact on an application. Number of watchers and ng-repeat declarations are the most important aspect of an AngularJS application.
How am I supposed to then propagate these changes into the DOM if I'm not using $watch?
To Yao Ming, I'm short. Trouble is, we each of us technologists tend towards introversion (been struggling since...well, take my age and then subtract however many years my communication skills were less than stellar).
Ever try to raise money for an idea based on numbers? It's like trying to land a date based on the size of your...real estate. Sooner or later, another yutz shows up, plops his drink on the counter and announces that the yacht he just stepped off was twice the size of yours.
Ya, it's never a fun game because it necessitates that binary outcome. Suffice to say good tools in the wrong hands can still be used to chop off your own feet if you don't pay attention.