
Bad month for the main thread - skellertor
https://daverupert.com/2018/01/bad-month-for-the-main-thread/
======
AHTERIX5000
What is it exactly the added bonus _users_ get with the modern way of web
development that wasn't there in, say 2011? I remember using Android 2.x with
800 MHz SOC back in the day and web browsing worked fine, really. What modern
web sites can offer to justify the increased CPU usage?

~~~
dijit
I suppose now you can play 3d games? Watch videos without flash?

I don't think you can claim that the way we use the internet in 2018 is the
same as how it was in 2001, we assume "web apps" for things like mail, editing
documents and other things will work.

Now, I absolutely detest the insane complexity of a browser and that I can't
have a 'lite' browsing experience today without sacrificing access to a large
portion of the internet. (which I blame on the prevalence of javascript)

But do enjoy the 'no download', 'run anywhere' nature of web-applications,
and, often, I'm willing to trade a bit more power for them, because as a
heavily BSD/Linux user the alternative is not having anything at all.

The question is, how can we penalise those that abuse the power of a browser
without offering value?

~~~
rsynnott
> The question is, how can we penalise those that abuse the power of a browser
> without offering value?

"Do you want to enable Javascript for this website?"

~~~
dijit
I really /really/ like that idea, but it will be an annoyance for 99% of
people with how frequently it will trigger. People will expect a crappy
experience until they click "OK" and the button will be blamed for getting in
the way.

------
deathanatos
> _It isn’t far fetched that a device would reduce power consumption when on
> battery, it makes the device last longer, makes users happier._

Does it? If I reduce the amount of power available to complete a task, but
proceed to complete the task _anyways_ , doesn't the phone now need to
potentially have the peripherals (particularly, the screen) on for longer as
the user waits for a task that has been slowed down to complete, consuming
_more_ energy than had it completed the task using 100% CPU?

(Unless using 80% of the CPU can accomplish the same task using less energy
(not power) and recoup enough to make up for the losses incurred by needing
extra time.)

It isn't intuitive to me at all that what we're doing isn't making phones
useless so that their battery lasts all day.

~~~
jerf
"It depends":
[https://pdfs.semanticscholar.org/6611/bc084fbaf1845b1bf54cc7...](https://pdfs.semanticscholar.org/6611/bc084fbaf1845b1bf54cc72d1c143d25083d.pdf)
From the abstract: "We evaluate three systems - a clock throttled Pentium
laptop, a frequency scaled PowerPC platform, and a voltage scaled system....
on the Pentium-based system, it is energy efficient to run only at the highest
frequency, while on the PowerPC-based system, it is energy efficient to run at
the lowest frequency point."

So it can go either way, depending on a lot of the local factors.

------
arghwhat
The author presents a problem in the lack of device model and battery level
information. A website/web application may disable functionality due to
browser feature availablity, but if you disable functionality based on the
device model, you're doing something wrong.

If you have a scenario where you can disable _some_ thing to make the
experience better while maintaining functionality, then why in the _world_
would you ever enable those things? This is simply beyond me.

Any suggestions that improve the situation are simply generic performance
optimizations that benefit everyone.

~~~
Cyberdog
On the other hand, if the idea of sending mobile devices with low batteries
simplified versions of web sites catches on, we could have our desktop
browsers spoof to be four-year-old iPhones with 10% battery life and perhaps
have a much better and faster desktop experience…

~~~
arghwhat
What a world we live in...

------
lmm
Given that components are going to need to contain Javascript, what's the
value in having them contain separate HTML? "Browsers are good at handling
documents" isn't really true any more; at least, browsers don't seem
appreciably better at handling documents than Javascript is.

~~~
MaxBarraclough
> browsers don't seem appreciably better at handling documents than Javascript
> is

If you disregard memory consumption, CPU load, battery life, then sure.

~~~
lmm
Even then. I was surprised to see doing a given thing in Javascript perform
better than doing it in CSS, but that seems to be the reality of browser
implementations.

------
debacle
Just discovered the slider. What a huge performance boost.

------
rmrfrmrf
What can we blame on JavaScript next?

