thegreenwebfoundation / co2.js

I've seen there have been changes to the SWD method which have been suddenly merged in. Why is this? Can it go in PR review beforehand? Some of the additions are a little confusing. And seemingly change the calculations quite a bit.

Why do we need this logic? We have a default value set carbonIntensity = GLOBAL_INTENSITY so it will fall back to global intensity anyway.

co2.js/src/sustainable-web-design.js

Line 100 in 95939c3

if (Boolean(carbonIntensity) === false) {
Why does it fall back if true to RENEWABLES_INTENSITY?

co2.js/src/sustainable-web-design.js

Line 105 in 95939c3

if (carbonIntensity === true) {
Why has energyPerVisit changed? It doesn't meet the calculations in SWD page

co2.js/src/sustainable-web-design.js

Line 190 in 95939c3

energyPerVisit(bytes) {

Before we make breaking changes like this we need to go through them together and make sure they all align and importantly we understand the why and what is outputted.

I wouldn't add any more updates/code without adding TypeScript too.

When did co2byComponent, energyPerByteByComponent, perByte get merged in? @mrchrisadams

hi Dryden,

When did co2byComponent, energyPerByteByComponent, perByte get merged in?

See PR #67 - about three weeks back.

#67

These changes were designed to allow support for existing clients, like sitespeed, and lighthouse.

There's some discussion about adding this to the HTTP Archive runs, which may need to consume HAR files of the loaded pages, rather than doing a re-run of all the millions of pages crawled as part of the HTTP Archive regular crawl.

Why do we need this logic?

In see issue #56 back in December I tagged you to ask a few questions about supporting other clients , and asked for these methods, explaining why they were needed. These provide an upgrade path for existing clients, so they can adopt the SWD model from consuming the current model based on the 1byte calculations from before.

I hadn't heard back, and they were needed, so I ended up implementing them myself. Sorry about not tagging you on the previous PR - I'll tag you in future when there are future PR, and I think this highlights the need to have a better documented process for handling future changes.

#56

I'm not available today for more discussion but I'm happy to chat next week in more detail.

In the meantime, I've shared a jupyter notebook with you (the nextjournal one) going more detail about how the SWD model relates to the underlying paper it's based on.

I've also got the go-ahead to share it in a slightly edited form to add to this repo. I think this could provide a useful addition to the documentation we have so far, outlining where we might work on future versions of the SWD model as new data becomes available.

Have a nice weekend - I hope this is enough for now - I'll pick this up next week.

I wouldn't add any more updates/code without adding TypeScript too

There's an existing PR here that started a conversion:

#30

…but it's pretty old now, and I had held off merging it before because I didn't know well Typescript all that well.

My main worry about Typescript is that its a big language and introducing a bunch of Typescript's features might raise the bar for contribution so that only people who know typescript really well can do so.

I think that would reduce adoption, but I don't know enough about Typescript to really tell either way right now.

There's an issue, #77, linked below for more discussion - can we discuss it and share any links to public PRs there please?

#77

This issue seems to be resolved/is dated.
@mrchrisadams I'm going to mark it as closed.

Default carbonIntensity checking fallbacks