Coming from a person who started writing UIs back in the 1980's, where one needed good assembly code to be able to do display text files in text mode, I am seriously impressed how effective browsers are in rendering HTML/CSS.
For a bunch of scripting languages stacked on top of each other, with byzantine levels of backwards compatibility and alternative ways to define the same things, thats seriously impressive optimisation techniques in the browsers. And they are pretty consistent, too. Absolutely awesome.
Of course, I am sure it generates a lot of CO2 for all that effortless eyecandy.
> I am sure it generates a lot of CO2 for all that effortless eyecandy.
Why?
Genuine question. A couple years ago I tried assessing the claim that websites (frontend, specifically) can meaningfully be tuned to reduce emissions [1]. Apparently it takes less than a dollar/year (2018) to charge a smartphone (0 to 100% daily) [2]. Given that fact, and assuming that energy usage from a mobile browser is in the same order of magnitude as a desktop browser + price is a decent stand-in for amount of emissions, it seems to me that any savings aimed at reducing emissions via "better" websites is negligible, even at web scale. I have a simple (maybe too simple?) spreadsheet to back this up [3].
"assuming that energy usage from a mobile browser is in the same order of magnitude as a desktop browser"
Any basis for this assumption?
Desktop processors are much less optimized for power consumption, and desktop browsers are also used differently with websites often time left running in the background tab, compared to the mobile phone.
I think the claim is accurate only because I've set the bar quite low (10x being an order of magnitude).
But I'll do a similar analysis: how much does a constantly-used desktop PC emit? I'm seeing estimates of ~200 kg emissions/year from a desktop PC for ~8hr/day usage, which is ~0.4% of the average American's emissions (50,000 kg/year). Now you must consider some other things:
1) of those relatively small emissions, how much is due to energy that is used for baseline PC functions (OS, monitor, etc).
2) does idle time from a browser doing slightly less work translate to noticeably less power draw? I can see a difference from 100% to 80% CPU utilization, but what about 40% to 20%? is the relationship between cpu utilization and power draw linear?
3) I'd bet the largest offenders of sites in terms of power usage are complex webapps that have no meaningful room for performance improvements possible by a frontend developer: games, photo editors, video players. Compare to those, better CSS selectors seems small potatoes.
To be clear, my claim is that overall the savings here are negligible and efforts are far best spent elsewhere (extreme example: instead of a programmer trying to optimize even a heavily-trafficked site, they would have a larger impact if they spent their time ensuring their home, or the home of their friends and family, is not wasting energy).
That doesn't take into account the production footprint of a device capable to render today's web with all its transitions and glory, the environmental and geo-political toll on extracting lithium, rare earths, and other materials, plus the footprint of delivering devices into the hands of users, and disposal after typically only two years of usage.
Whereas had we been sticking to deliver just plain passive HTML markup users are after, we could've had solar-/light-powered devices with slow LCD displays and low-power RF transmission similar to old e-book readers by now (solar-powered pocket calculators were available in the 1970s already).
Would help with tracking, privacy, ad monopolies, and browser obsolescence as well.
Yes, but having our modern devices isn't solely to allow css to exist - good hardware allows devices to be a replacement for maps and gps, cameras, messaging systems, mobile games, entertainment systems, and everything else you can write an app for. Low power e-book readers exist, but it's clear that most people would much rather have a smartphone.
The focus of this analysis is if creating tooling and researching better frontend practices could result in a meaningful reduction of emissions. Saying "don't use the web at all or the devices that access it" is not very useful in this context.
Yes, I think you are right - I was half joking. Its unlikely the faster websites would free up enough idle cpu time to make up for all that extra time it would take to implement the web with lower level, presumably more efficient frameworks.
I am sure it generates a lot of CO2 for all that effortless eyecandy
Maybe, but many people have optimized the browser layout engines to make them efficient. That probably means they're far more efficient that the sorts of UIs people write themselves, despite several layers of abstraction. One badly written block of code can waste a lot of energy.
I'm more so concerned for the fact that browsers are required to be so complex that it is seemingly more complicated to write a web browser rendering engine than a video game engine.
The resources modern browsers require to run are silly and often take more resources than all other applications combine, and small players have a hard time entering the field.
You're comparing a value against a spectrum - there are a few video games that likely rival the complexity of a browser... but I don't know if it's really a fair comparison. Video games just do the one thing - while browsers are essentially mini-operating systems. Some folks primarily use GoogleDocs as their text editor.
I don't know if there was ever a time when browsers weren't heavier to write than games - except back in the dark days when the web was but a baby.
> while browsers are essentially mini-operating systems. Some folks primarily use GoogleDocs as their text editor.
The mini operating system is written in another language than the browser.
An analogy here would be writing such an operating system within the game engine, and then claiming the game engine that is only used to render the operating system is the operating system.
The real issue with browsers is the load of historical cruft they have to continue to support, as well as many new and duplicated technologies such as in this case C.S.S encroaching more and more upon the domain of browser scripting.
> I don't know if there was ever a time when browsers weren't heavier to write than games - except back in the dark days when the web was but a baby.
Is that really so? I would say that at the time game rendering technology was making vast advances in 3.d. rendering with clever hacks around the turn of the millennium, browsers were probably easier to write than these engines.
At least in my mind the nascent days of the web was the early 90's when a large portion of games were still mostly text based with most of the graphical fidelity coming from clever uses of flat 2D images that had sprites overlaid on them. You certainly had 3D games going back to 1981 - but there were still quite rare compared to isometric 2.5d games.
Even the side scrolling games of the early 90s required ingenious hacks to make them work on the hardware of the time.
Game consoles at the time had hardware accelerated sprite scrolling; personal computers did not and had to redraw sprites manually to scroll but the games used some very interesting hacks to avoid having to redraw most of the screen and create the illusion of fluid movement by only redrawing parts of it.
Some of the absolute hacks to make games run on the Gameboy were even more impressive.
For a bunch of scripting languages stacked on top of each other, with byzantine levels of backwards compatibility and alternative ways to define the same things, thats seriously impressive optimisation techniques in the browsers. And they are pretty consistent, too. Absolutely awesome.
Of course, I am sure it generates a lot of CO2 for all that effortless eyecandy.