Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off
-
Bonus WTF: 20 of the sites listed on the MadeWithAngular site aren't made with angular.
Another bonus WTF: this OneBox code is AGAIN doing a DoS on an external website. What a piece of shit. Turn it OFF until it's fixed, please.
-
@blakeyrat Wait, as far as I understood, it only adds css classes? There is no other overhead?
If that's the case, then leave it on. The benefits of being able to inspect live code using angular tooling far outweighs the imaginary performance penalty of having a few extra classes. The OP should have ran some actual performance tests before he decided to call the angular authors idiots.
-
@cartman82 said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
Wait, as far as I understood, it only adds css classes?
You should read the article.
EDIT: or, I guess, read the documentation page the article tells you to read: https://code.angularjs.org/1.5.5/docs/guide/production
The horse's mouth says:
but you can disable this in production for a significant performance boost with:
There is a SIGNIFICANT performance difference.
-
@blakeyrat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
You should read the article.
I did.
Those classes are for debugging purposes and debugging purposes only. They’re not security leaks, but performance drags. Angular has to add and remove those classes whenever a new scope or new isolated scope is created. Doing this slows down Angular, and the website that is using Angular.
That's his whole argument. A blank assertion, without any performance tests or comparisons.
If you're gonna call people idiots, you need to do better than that.
-
@blakeyrat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
There is a SIGNIFICANT performance difference.
Ok. fair enough.
I'd still like to see an actual test, but if angular team says this is a performance drag, yet leaves it on, it's a WTF.
-
@cartman82 Maybe Angular's own documentation is lying, but that's just swapping one WTF for another.
-
@blakeyrat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
@cartman82 Maybe Angular's own documentation is lying, but that's just swapping one WTF for another.
Looking more into this...
https://ng-perf.com/2014/10/24/simple-trick-to-speed-up-your-angularjs-app-load-time/
Apparently, this was an obscure speed hack in 1.2, then introduced as a documented flag in 1.3. If your site is older than that (which is likely if you're an early adopter from madewithangular.com), you'll likely miss this, unless you are keeping up with version updates.
Up to 50% speed boost according to that blog. Interesting.
-
I'm not sure how much trust I'm placing in a framework which neither has easy to use configuration variables nor a command line flag like
--env=production
nor a settings file wherein switching to production automatically switches off all the development and debugging stuff.And just for the record, this:
config(['$routeProvider', '$compileProvider', function($routeProvider, $compileProvider) { //configure routeProvider as usual $compileProvider.debugInfoEnabled(false); }]
is not what I consider easily setting a configuration variable.
-
@Rhywden I'm not sure I'd trust a framework that defaults to debug on, if I'm brutally honest
-
@RaceProUK said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
@Rhywden I'm not sure I'd trust a framework that defaults to debug on, if I'm brutally honest
That was an implication I neglected to make brutally clear :p
-
if Genius didn’t use this one line of code that improves the performance of their website
Did they use the one line of code that would speed up their Angular? No.
How about the other 57 examples? How many of them used this one line of performance-enhancing code?
That means 96.5% of websites inspected do not use this one line of code that improves Angular performance.
Chrissake, the whole article sounds like an infomercial. Why Aren't You Using This One Simple Line Of Performance-Enhancing Code When You Could Be RIGHT NOW, for only $99.99?!
There's an assload of websites parroting this trick, and none of them includes any metrics whatsoever. God forbit you could actually tell people how much they'll benefit from it!
-
@Maciejasjmj said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
There's an assload of websites parroting this trick, and none of them includes any metrics whatsoever.
indeed. if you're pushing a performance improvement anything and you want me to take you seriously.... PROVIDE METRICS!
-
@Maciejasjmj said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
God forbit you could actually tell people how much they'll benefit from it!
So one byte is two Gods?
-
@accalia said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
PROVIDE METRICS!
Pascal, Newton, Farad, Tesla, Coulomb, second.
-
@dkf those are metric units, not metrics.
so, nice try, but i'm afraid i have to award you zero points.
please try again in 30 seconds or more.
-
@accalia said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
those are metric units, not metrics.
-
@accalia said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
indeed. if you're pushing a performance improvement anything and you want me to take you seriously.... PROVIDE METRICS!
If you don't trust the makers of your framework to tell the truth in their own documentation, why the fuck are you using that framework?
-
@blakeyrat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
why the fuck are you using that framework
why do you think i'm not using AngularJS?
or ember, or whatever the flip is the JS DOM framework du jour .
-
@accalia The point is, you stupid moron idiot dummy, why do you need to ask for numbers when the documentation already says it's a significant performance impact?The PEOPLE IN CHARGE have already said it's significant. You don't need specific numbers.
The only explanation for this retarded dumb moron idiot dummy behavior is if you think the documentation is a liar, in which case you're a dumb moron idiot dummy for adopting the framework in the first place.
-
@dkf I prefer "Ham distance", which measures the distance between two ham actors in a given piece. I prefer movies with small ham distance myself, other people prefer the ones where it's tending to infinity.
*Pictured above: one of the smallest ham distances ever recorded in a high-budget movie*
-
@Onyx The line after that should be back to Stallone and
I AM THE LAW!
-
@Onyx I still say that is a 100% unscripted moment where Armand Assante was outright mocking Stallone's performance which somehow ended up in the final product.
-
@blakeyrat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
You don't need specific numbers.
why not?
how else can i judge whether turning it off is the correct thing for me to do?
as the documentation says the setting needs to be enabled for at least two plugins to angular? what if i want to use one of them? i need to know what the performance improvement is to determing if it's acceptable to take the performance penalty to use the plugin.
@blakeyrat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
The only explanation for this retarded dumb moron idiot dummy behavior
is because i prefer to think and reason from a position of information. "significant performance improvement" is meaningless to me. does it mean 50% faster? 500% faster? 50ms faster? 1.5% faster? all of those values can and will be called significant for someone because they will be significant for someone, i need to know which one the author refers to to determine if it is significant for my purposes
-
@blakeyrat well, if it is so I salute both Armand and the editor, because it's pure gold.
-
@accalia I guess the answer is to go on a vision quest, drop peyote by the wheelbarrow load, and bug-off into the desert with no supplies or water.
Let us know how it turns out.
-
@blakeyrat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
the answer is to go on a vision quest
so the answer isn't "actually measure the performance impact of the setting"?
no wonder i fucking hate front end developers
-
@accalia said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
how else can i judge whether turning it off is the correct thing for me to do?
Remember, you're talking to the person who consistently denies the validity of a trade off.
-
@boomzilla said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
@accalia said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
how else can i judge whether turning it off is the correct thing for me to do?
Remember, you're talking to the person who consistently denies the validity of a trade off.
/shrug.
still better than talking to a brick wall.
i'm much more likely to get hurt talking to a brick wall, what with the risk of it falling on me and all.
-
A Javascript framework doing something stupid. I am shocked.
At this point you could say "Angular.JS spawns a new full Java Virtual Machine in your browser on every click event, and forces web developers to write all their code in Brainfuck" and I'd be like "oh well, I guess that works for them".
-
@anonymous234 said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
spawns a new full Java Virtual Machine in your browser on every click event, and forces web developers to write all their code in Brainfuck
They work for Jeff?
-
@anonymous234 Don't give them ideas!
-
@loopback0 I still think "soft rendering", i.e. drawing the entire page in Javascript on a single <canvas>, will actually happen sooner or later.
-
@anonymous234 I've done that. It was a graphically-oriented page though, with lots of interactive animation.
<canvas>
was the right decision I think…
-
@dkf said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
@anonymous234 said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
spawns a new full Java Virtual Machine in your browser on every click event, and forces web developers to write all their code in Brainfuck
They work for Jeff?
To be fair, they're working on having a farm of JVMs in the cloud that you can call out to.
-
@boomzilla said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
To be fair, they're working on having a farm of JVMs in the cloud that you can call out to.
They'll get those letter avatars rendered yet!
-
@accalia said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
i'm much more likely to get hurt talking to a brick wall, what with the risk of it falling on me and all.
What if the brick wall says you ed something? I'm asking for a friend.
-
@FrostCat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
@accalia said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
i'm much more likely to get hurt talking to a brick wall, what with the risk of it falling on me and all.
What if the brick wall says you ed something? I'm asking for a friend.
KYON BARK!
-
@blakeyrat said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
@accalia I guess the answer is to go on a vision quest, drop peyote by the wheelbarrow load, and bug-off into the desert with no supplies or water.
Let us know how it turns out.
Please let us know. The last guy still hasn't reported back his metrics.
-
@dkf said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
@boomzilla said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
To be fair, they're working on having a farm of JVMs in the cloud that you can call out to.
They'll get those letter avatars rendered yet!
You know what the best part of that whole debacle is?
So even if it was a problem, you could render them client-side. With zero server-side performance overhead.
-
@cartman82 They still didn't provide any actual fucking measurements data.
-
@blakeyrat You know why you're a moron?
Because you do blanket assertions without providing any actual data to prove your point and cite random blogs written by fuckwits that don't provide any actual data as a proof.
There is this camp of people that still, for example, repeat the mantra about string concatenation being a performance hog in Java and how everyone must use StringBuilder, while ignoring the fact that the compiler does exactly this when it encounters string concatenation, since Java 6. They just learn a factoid either completely unproven, or out of date for an epoch, and keep reiterating it for decades. Fuck these people.
-
@wft said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
There is this camp of people that still, for example, repeat the mantra about string concatenation being a performance hog in Java and how everyone must use StringBuilder, while ignoring the fact that the compiler does exactly this when it encounters string concatenation, since Java 6.
If you're going to rant about people repeating mantras, you should probably make sure that you're not also repeating a mantra. Specifically that the compiler will solve all your string concatenation woes.
The auto-stringbuilder feature only works if you are doing all your concatenation in a single expression, i.e.String result = a + b + c;
It screws up on even the slightest variation. This creates two StringBuilders:
String result = a + b; result += c;
So unless you are only ever doing concatenation as a single expression, then yes, you should be using StringBuilder explicitly.
-
@sloosecannon said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
you could render them client-side. With zero server-side performance overhead.
Yeah, Discourse really needs to put more load on the client.
-
@Salamander A construct like you mentioned is usually used in loops of some description. Growing a string incrementally calls for an explicit StringBuilder, because you build a string. It reveals the intent. One-off stitching 2-4 String variables together with an explicit StringBuilder hides the intent. Why create throwaway StringBuilders if the compiler can create perfectly good ones just as well?
-
@wft What intent is actually hidden? It's a StringBuilder. It builds strings. Intent right there.
-
It also occurs when you're doing selective concatenation in Java using if-statements; I've seen those more times than I've seen simple concatenation in a single expression.
I personally don't care what people do if they understand exactly how and when the automatic stringbuilder gets created, however I typically see people who do not.StringBuilder is a good reason for adding operator overloading in Java, but that doesn't exist and it's not the only verbose class that exists. If you can't read Java's current verbose shit, then you're going to have a bad time.
-
@Salamander said in Angular.JS' performance-killing debugger nonsense is on by default, nobody turns it off:
StringBuilder is a good reason for adding operator overloading in Java
It wouldn't change the fact that you still need to use it as the semantics for automated insertion of StringBuilders doesn't work efficiently in loops and other append-heavy situations. Operator overloading isn't a solution; it's a different (shorter, but perhaps more confusing) way to write the problem down.
-
@loopback0 pffft, a drop of water compared to all the other crap it crams through your browser's JS engine...