AngularJS Performance in Large Applications

https://www.airpair.com/angularjs/posts/angularjs-performance-large-applications

by arnauddri • 12 years ago

107 57 12 years ago

progx2• 12 years ago

Can somebody explain me what "large Applications" are?

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?

rdtsc• 12 years ago

It's a bit like Big Data and Deep Learning. As soon as those terms came around almost nobody is left working on Small Data and Shallow Learning.

exelib• 12 years ago

I think no. I'm working on a application on which working more than 16 teams for more than 11 years. I think it is a large application.

progx2• 12 years ago

We talk about large "Angular" Applications.

lightblade• 12 years ago

Large should be at least 80k lines of code, preferably more than 100k.

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.

nostrademons2• 12 years ago

By the second metric, Google is not a "large" software system because all code must be reviewed by someone with context on it. (Single-developer projects and codebases don't get anywhere at Google...I tried, multiple times.)

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.

CSDude2• 12 years ago

Seems it is down, Google Cache: http://webcache.googleusercontent.com/search?q=cache:www.air...

vegancap3• 12 years ago

"application error" ...is this site written in angularjs? If so I think we have the answer to that title! :)

hhsnopek• 12 years ago

haha if it can't host a simple blog.... then can it really scale?? ;)

vegancap3• 12 years ago

I'm praying for this blog to be Wordpress as I've just started a project in angular!!

soccergee• 12 years ago

I'm not sure if you're saying that blogs are simple or if you're subtly making a jab at his blog. :P

But i actually think you're on to something.... WILL IT SCALE?! Find out in next weeks episode...

CSDude2• 12 years ago

It is the default Heroku error page, displays when your server crashes it has nothing to do with client side code such as AngularJS

gedrap2• 12 years ago

Nit-pick, but I don't agree with his definitions of complexity.

>> 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.

oinksoft• 12 years ago

Also disagree with

  > 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.

A while ago this sort of advice was true (when you'd see people inlining stuff in `eval` to avoid this), but nowadays function execution itself is very fast.

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.

teen• 12 years ago

I disagree strongly as well. For example if you have something like ng-show="is_admin()" and $scope.is_admin = function() { return $scope.logged_in && $scope.role='admin' } or some other complexity reducing function, I don't understand how that would be significantly less performant than copying and pasting the return statement everywhere in your html.

userbinator• 12 years ago

Requiring more memory doesn't make an application slower by default.

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.

jdawg77• 12 years ago

Large and small are fuzzy metrics. A subset of non binary thinking (see Kosko, the model of probability and the hypercube, etc). "Jeremy is short," well - to a 5'0 person, I'm freaking tall.

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.

thruflo• 12 years ago

A couple of times, the article mentions using:

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?

fein2• 12 years ago

I think the only way to do what you want with your service is by injecting rootScope and using $emit, since we're trying to capture a "logout" event and tell our other controllers about it.

Reacting to the specific event would likely waste less resources than pulling out the $watch or $watchCollection sledgehammer.

arvidkahl• 12 years ago

What works well for me is having the service return an object (named `data`) alongside the functions like `logout`, which contains another object with the actual model (`user`). Then, in controllers, I assign it to $scope.data and $watch('data.user') which reflects the changes in the controller since it this object is being shared by reference among all controllers and directive that inject the service.

JDDunn92• 12 years ago

Create an angular factory with a standard observer pattern. So you register the callback with something like MyFactory.register(updateUI()); and call MyFactory.notify(); after userService.logout(); which calls all the registered functions.

uptown• 12 years ago

What's the current best guide for learning AngularJS? Is angularjs.org my best bet, or would you recommend some other resource?

fein2• 12 years ago

Anywhere and everywhere. The Angular docs are notoriously shit sometimes, so finding as many examples as you can from other sources, then deducing the "right way" from those has been the best help for me.

The best resource I found was using ng boilerplate.

squeaky-clean• 12 years ago

I've been using this SO answer[0] as a list of good resources. The egghead.io videos have been most helpful to me, I really enjoy the "bite-sized" videos style and the way the speaker explains how attributes/vars relate to others in the application. Here's their specific page for beginning AngularJS.[1]

[0] https://stackoverflow.com/questions/14333857/how-to-master-a...

[1] https://egghead.io/articles/new-to-angularjs-start-learning-...

Bahamut2• 12 years ago

This has the best collection of resources on Angular: https://github.com/jmcunningham/AngularJS-Learning

DigitalSea3• 12 years ago

Pretty good article, especially in regards to the $digest cycle which can cause some performance migraines. This is something I have seen newbies in Angular encounter pretty quickly, too many watchers and mistakenly triggering tonnes of $digest cycles.

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.

cfontes2• 12 years ago

What about a blog post about all the things you guys learned using Angular? It would be very interesting.

DigitalSea3• 12 years ago

That is actually a great idea. Things are a little busy in the lead up to the holidays, but perhaps in the New Year, we could write up a little article detailing the quirks we encountered and how we fixed them. We have learned a lot of the last year or so.

fngegngkg• 12 years ago

We managed to get a twenty percent speed up in our app that used Angular...

...by removing it and using something bespoke and lean and simple instead!

DigitalSea3• 12 years ago

Not everyone has the luxury of throwing away one years worth of work and choosing something else.

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.

marknutter• 12 years ago

They are only removing the V and replacing it with another V.

coldtea3• 12 years ago

If all you got for bespoke and lean is a "20% speedup" then I don't think it's worth it.

You should be able to get at least 100-200% speedup...

lhorie• 12 years ago

Yeah, I had the same experience (except using Mithril instead of React).

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)

taude• 12 years ago

We'ere using KnockoutJS, not Angular in our app, and it suffers from the same issues. On certain components, especially when applying complex rendering logic, that need to be optimized, like our DataGrids, we've been moving towards a React-based rending flow (might eventually do it serverside). The React version is about 8x faster than our Knockout implementation.

TheAceOfHearts• 12 years ago

The angular core team has mentioned that they may have overstated the performance gains of Object.observe(). I don't think there'll be as large performance gains as people think.

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.)

serve_yay• 12 years ago

There is some good info here. But when your Angular app slows to a crawl, it won't be because you used objects instead of arrays.

exratione• 12 years ago

This is still fairly applicable for the major causes of speed and slowness.

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.

nikon• 12 years ago

Common things I have encountered:

$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.

aturek• 12 years ago

If anyone, like me, didn't know about 'track by' as a way to optimize ng-repeats, here's a couple of articles that explain what it is and why it's beneficial:

http://www.codelord.net/2014/04/15/improving-ng-repeat-perfo...

http://www.bennadel.com/blog/2556-using-track-by-with-ngrepe...

rattray2• 12 years ago

By comparison, it seems that the equivalent article for a React application would be "use immutables and PureRenderMixin", full stop.

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?

thoman23• 12 years ago

If you aren't going to use $scope.$watch, you might want to ask why you're using Angular in the first place. From my own experience building a large-ish hybrid mobile app in Angular, I haven't run into any performance issues. While you should of course understand the implications of how you structure your application, I would also warn against premature optimization. I advise building first for simplicity and ease of maintenance and then tweak for performance if needed.

JDDunn92• 12 years ago

9.4 seems to be an outdated issue. Since version 1.2.16, $rootScope.$broadcast does not go to all child scopes, only those with a watcher. It's very fast, and perfectly fine to use if you need it.

mackraken• 12 years ago

uh... re Loops: "Try and avoid making calls in a loop." This is an over simplification. The author draws the wrong conclusion from the example given:

    for(var x = 0; x < 100; x++){
      var keys = Object.keys(obj); 
      sum = sum + keys[x]; 
    }

The problem here is needlessly invoking the same operation 100 times (Object.keys).

collyw2• 12 years ago

I assume he was just explaining it badly.

s_baby• 12 years ago

Similarly, Angular provides the ability to watch entire objects by passing a third, optional true parameter to scope.$watch. This is, for lack of better words, a terrible idea. A much better solution is to rely on services and object references to propagate object changes between scopes.

How am I supposed to then propagate these changes into the DOM if I'm not using $watch?

dmak• 12 years ago

I disagree with 9.4 as I think you should try to use event emitting more. This is the best way to modularize your application and really separate your concerns.

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.

rattray2• 12 years ago

Interestingly, this is essentially the React/Flux model in a nutshell.

AngularJS Performance in Large Applications

Related Stories