41–50 of 118 posts
* 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.
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…
-Donald Knuth [1]
[1]https://books.google.com/books?id=SJHvCgAAQBAJ&pg=PT471&lpg=...
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…
Wow, I did not know that everyone else also right clicked to "inspect element" all over the place, for no reason... I love moments like this.
It comes in quite handy when you're dealing with sites that attempt to hide content behind a paywall, with just a front-end solution... #nevertrusttheclient
Off the top of your head, do you remember any examples of sites that expose paywalled content like this?
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…
Depends. There's been lots of studies linking page speed to revenue. I would imagine it doesn't manifest much in lower traffic sites where there's too much noise for it to play out, but as you grow in your userbase, working fast starts to become necessary for it to work well.
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/
I've searched a few minutes for any blog post or article which demonstrates the performance difference between turning this setting on or off, and I haven't found anything. If you don't have a benchmark, you don't have a performance boost.
What the author discovered is really shitty defaults for Angular. Most software is like that. Don't blame the developers using the software, blame the Angular developers for choosing shitty defaults. Instead of choosing production ready defaults, they chose development ready defaults, creating more work for everyone.
Does Angular 2.0 make this one weird trick unnecessary?
This article reminds me of those X Hate Him! ads. http://i1.kym-cdn.com/photos/images/newsfeed/000/633/254/14f...
Earlier quoted context omitted.
It comes in quite handy when you're dealing with sites that attempt to hide content behind a paywall, with just a front-end solution... #nevertrusttheclient
That still works? Cool. Off the top of your head, do you remember any examples of sites that expose paywalled content like this?
Shouldn't debugging be something you opt-in to rather than opt-out of? Seems like a weird design choice