Improving Angular performance with 1 line of code
medium.com
medium.com
Heck, I shouldn't even be saying this as it'll cut into my very lucrative field but unless you've got a confirmed performance problem, you shouldn't think about it at all. Really. Leave all of the fancy perf tweaks behind. Sure, you might get ridiculed on Medium but that's par for the course here on the internet. I'm afraid articles like these will cause lots of cargo-cult 'optimization' that just makes the job harder for future devs.
Make it work, make it work well, THEN make it work fast.
[0] I wrote Batarang's new perf panel before Google abandoned the project
I optimize one module at a time, and I optimize it deeply. The number of people whose stuff I might break is kept to a minimum, the surface area of regression testing is controlled, and next quarter when they ask me for more power I can repeat it, until I run out of modules (hopefully someone will write some more in the meantime).
The whole idea of the Tall Tent Pole is pretty enticing, but the thing is nobody is ever gonna buy into going back for the last 20% in any one part, and these things always have a multiplicative factor. If you're in a field with no competition, this isn't a big deal, but how often does that happen?
Unfortunately a bunch of inherited legacy code uses angular.element().scope() in a lot of places which then breaks without this turned on, so I had to revert it.
-Donald Knuth [1]
[1]https://books.google.com/books?id=SJHvCgAAQBAJ&pg=PT471&lpg=...
Would you mind linking a few of these studies? I'm curious as to what the point of diminishing returns is.
nngroup [0] says that 100ms feels instantaneous. A good digest cycle run (the basic unit of Angular performance) is 16ms, a mediocre one is 20ms. So a mediocre application has 5x space to grow before the app stops feeling instantaneous.
[0] https://www.nngroup.com/articles/website-response-times/
Not really. Those 100ms are from click to render done, so you also need to account for the physical transmission latency, the transmission of the data and finally the rendering (which is where your 16-20ms are).
I take your general point but battery life is also a problem I have with React Native. Sure, you can drive animations from the JS thread and on modern devices in some cases you can't even tell the difference. But your battery can.
I like to write high quality code that I'm proud of. This means code not just works, but works efficiently and fast. It goes back to what Steve Jobs said once:
“When you’re a carpenter making a beautiful chest of drawers, you’re not going to use a piece of plywood on the back, even though it faces the wall and nobody will ever see it. You’ll know it’s there, so you’re going to use a beautiful piece of wood on the back. For you to sleep well at night, the aesthetic, the quality, has to be carried all the way through.”
That said, this is more of an ideal to strive towards and it's not always possible. Sometimes there are tight deadlines that need to be met, and something has to give. In such scenarios, I agree with your order of priorities: 1) code that works, 2) code that works well, 3) code that works fast.
Given the chance, we'd all like to write perfect code but reality tends to interfere.
Steve Jobs may have missed the mark on some of his products during his long tenure at Apple, but his focus on quality in every possible area of what he had a part in creating has paid its benefits
Where would you say these come from?
Tell that to my Nexus 5 struggling to render a basic news article of 1000 words and a few images.
If you're going to complain about the slowness of pages due to trackers and ad servers regardless of which library (or none at all) is used for primary content formatting, then complain about that.
You're talking apples while holding up an orange.
2) ???
3) Make it work fast
THIS!
This is why battery life on mobile sucks
everyone who thinks this way is the reason
.
As everything moves to the web, the performance of your code matters
.
So what if my phone has just enough CPU to render your site? You should not be content with that - you should strive to use less, so my CPU can go to sleep faster.
.
Your job is supposed to be hard. you're an engineer! Please consider the consequences of your actions.
Yes developers your developer-time is the most precious thing in the universe but please consider your user's time and their computing resources as well.
You're actually harming your business if you choose to do shitty work for small bucks and good work for big bucks. If you take your standards very seriously it improves the capabilities of your team and let's you take on more lucrative contracts.
> And developers don't like to work for free.
Oddly enough, the highest earning developers I know don't think like that.
Maybe those developers earn so much that they can provide quality even if their customers don't explicitly demand it. But we can look at it in another way: their customer pay so much because they also pay for that quality and take it for granted. Deliver to them an unpolished product (in any way) and somebody else will code the next one.
Unfortunately not all customers are like that. Many of them fight for every single dollar/euro/whatever. They know they are compromising on quality and accept the tradeoff. After all, it's their privilege to decide the limits of their budget and maybe there is nothing they can do about it. The developer must accept it too, get the job done as quickly as possible and take another job. Or do very few and very long high quality jobs at unbearable costs and end up bankrupt quickly (and possibly piss off the customer because you're taking so long to deliver.)
Btw: customers give constraints also on time. There is no time to provide much quality when they want a feature delivered in a couple of days on a system you never saw before. It happened to me a few weeks ago. I made it but I could have done it better if I had at least one week? Sure. Would they pay me twice as much? Nope.
My clients pay my wages and they are the ones who choose what my priorities should be. Where are these mythical developers who get to choose how long to spend on optimising working code without any financial imperatives? Outside of hobby projects there's always someone counting the pennies.
I probably take this to a weird degree for some, but I actively think about my client's software quite often, and frequently toss ideas their way whenever they hit me. You'd be surprised how often those ideas--which I thought were cool, hence the sharing--come back later as something they want. It's just basic sales.
Of course, I'm always building large, custom projects from scratch, not taking on projects that ask me to optimize "working code without any financial imperatives". On the other hand, when I identify a part of their software that can gain performance or some other kind of improvement—say, some dependency has improved that will ease X, making priorities Y and Z easier to implement—they listen to me and put it in their list of priorities.
Everybody wins.
When it was released and we tried to use it, it broke our site entirely due to third-party libraries we were using.
> Note: by default, React will be in development mode. The development version includes extra warnings about common mistakes, whereas the production version includes extra performance optimizations and strips all error messages.
> To use React in production mode, set the environment variable NODE_ENV to production. A minifier that performs dead-code elimination such as UglifyJS is recommended to completely remove the extra code present in development mode.
You may want to disable this in production
for a significant performance boost
I'm inclined to believe the engineers who wrote the docs on this.
It's a great tool to have in your belt for optimizing angular apps, most people working with angular are not aware of this unfortunately.
That said, I'm not sure it made much perceptible difference as the app already performed adequately and the reduction is amortized across all of the interactions the user makes.
Seems like a weird design choice
Angular.js in a nutshell.
(Or at least it used to when last I checked. It does it by calling toString on the function and parsing the result.)
For instance:
myApp.service('foo', function (bar, baz) {
This isn't all callback functions (in fact, Angular is built on Promises, not callbacks) but rather functions when you register a new component.
You can override what gets injected (say, mocking things out in tests).
DI is a fantastic pattern that reduces or otherwise eliminates all sorts of snarls that can come up.
I say this naively as a non-user, but in my case this specifically is what made me decide not to use Angular. I was trying it out for a new project and running through tutorials, but when I realized it was being that clever behind the scenes I decided that learning all its quirks would take longer than the rest of the project, and switched to something way simpler.
myApp.service('foo', ['bar', 'baz', function (bar, baz) {
Sorry to hear you felt you weren't up to learning Angular & DI patterns. It can be tough for some folks who are still learning programming & JavaScript in general, so there's no shame in passing. Maybe next time - challenge yourself!
I'm sure you don't mean that to sound condescending, but that's really not what I said. It was a question of magicalness vs. payoff - I needed a front-end framework that would handle a bunch of databinding and stay out of my way, and halfway into my first tutorial I found none of the sample code worked (either because I changed a local variable name or because my project already had minification set up, I don't recall). Either way the docs and tutorial I was using didn't even mention the function was being introspected, I had to go source-diving to find that out.
It all worked out to make Angular feel less like a framework and more like a career choice - I couldn't just give it idiomatic javascript and expect things to work. If this introspection thing is the one and only magical part of Angular and I just happened to trip over it, maybe I got the wrong impression.
There are plenty of times you'd want to enable various debug features, even in production, even if it means leaving them always on. The only real question is if the tradeoffs are worth it - the performance hit, if any, and the security implications, if any, versus the productivity gains.
If you don't have a benchmark, you don't have a performance boost.
I love moments like this.
#nevertrusttheclient
Off the top of your head, do you remember any examples of sites that expose paywalled content like this?
I've also been known to take a couple minutes off a build process or fix something that is annoying everybody to break the ice.
http://i1.kym-cdn.com/photos/images/newsfeed/000/633/254/14f...
The only way I was ever able to get an angular project built/tested/deployed was by using something like yeoman. It's kind of shocking that the default project templates set up everything that you need except for this one thing.
I do notice that the made with angular site isn't even minifying their code:
https://www.madewithangular.com/static/js/main.js
Though that may be intentional so that people can see how it is written.
I like to blame developers who don't read the friggin documentation on the software they are using.
This particular suggestion is literally the very first one in the developer guide for running Angular in production: https://docs.angularjs.org/guide/production
if you've applied that trick and still find yourself wondering what's taking up time, we just released a performance monitoring tool. We're looking for feedback, so please let me know how you find it: https://opbeat.com/angularjs
* have this off by default and you have to turn it ON in prod? * have it cause a Console.Log("DEBUG IS ON Y'ALL");
Either way, I mean, there's ways to give folks the heads up, right? It seems odd to have to ADD this in Prod.
https://github.com/angular/protractor/blob/master/CHANGELOG....