Live data from Hacker News

Improving Angular performance with 1 line of code

medium.com

81–90 of 118 posts

Re: Improving Angular performance with 1 line of code

#82
post #22

Dude should have made a small fortune selling optimization services to those big corps.

There was a 3 job string in the late nineties where the first impressive thing I did was go fix the log levels of the code and get transaction times down by 50%. Sometimes the simplest tricks are the best.

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.

Re: Improving Angular performance with 1 line of code

#85
post #71

As someone who's specialized in AngularJS optimization [0], this doesn't surprise me in the least. Developers leave plenty of performance optimizations on the table, some worse than this one. The truth of the matter is that in the general case, it doesn't matter. We engineers like to go on and on about this or that perf efficiency but most of the time the code runs fast enough (and the majority of the time when it do…

> most of the time the code runs fast enough Tell that to my Nexus 5 struggling to render a basic news article of 1000 words and a few images.

I'd put dollars to doughnuts the slowdown is caused by ads & trackers, not a lack of framework-specific perf tweaks.

Re: Improving Angular performance with 1 line of code

#86
post #72

Earlier quoted context omitted.

This is known as Dependency Injection and makes testing and codebase componentization a breeze. You may have seen it called "inversion of control" elsewhere. In essence, my components define what they need to run (through the function params) and Angular hands it to them. For instance: myApp.service('foo', function (bar, baz) { registers a service named `foo` that depends on the `bar` and `baz` components. My service…

Cheers for the explanation, but this isn't so much "DI", as "reflection for the sake of DI", right? I mean, libraries can have DI without being quite this magical. 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…

Sure, Angular has strict DI, which looks like this:

  myApp.service('foo', ['bar', 'baz', function (bar, baz) {
Now it doesn't need to read the function params as it has the strict strings. This'll survive function param mangling (a typical minification step).

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!

Re: Improving Angular performance with 1 line of code

#87
post #71

Earlier quoted context omitted.

> most of the time the code runs fast enough Tell that to my Nexus 5 struggling to render a basic news article of 1000 words and a few images.

I'd put dollars to doughnuts the slowdown is caused by ads & trackers, not a lack of framework-specific perf tweaks.

So terrible performance is OK if it's caused by ads & trackers? They don't count as part of a page's Javascript payload?

Re: Improving Angular performance with 1 line of code

#88
post #71

As someone who's specialized in AngularJS optimization [0], this doesn't surprise me in the least. Developers leave plenty of performance optimizations on the table, some worse than this one. The truth of the matter is that in the general case, it doesn't matter. We engineers like to go on and on about this or that perf efficiency but most of the time the code runs fast enough (and the majority of the time when it do…

> most of the time the code runs fast enough Tell that to my Nexus 5 struggling to render a basic news article of 1000 words and a few images.

Use Firefox Mobile with uBlock. It's been a long time since I've seen ads on web

Re: Improving Angular performance with 1 line of code

#89
post #87

Earlier quoted context omitted.

I'd put dollars to doughnuts the slowdown is caused by ads & trackers, not a lack of framework-specific perf tweaks.

So terrible performance is OK if it's caused by ads & trackers? They don't count as part of a page's Javascript payload?

If you're going to complain about the slowness of pages because of the idiosyncrasies of one library over another, then complain about that.

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.

Post reply on HN