Yes, sigh, the "Save the trees argument" it never did make much sense. first and most important. trees are a renewable resource. second, the best trees for paper are from small farmed trees. not old growth forest.
The actual take away should have been, the bigger the paper industry, the more trees there will be.
If you are grasping you can bring modern carbon sequester theory into the argument. but I will admit that is too complicated a subject for me to feel comfortable leaning on it.
I feel like humans have trouble with the concept that the environment is not just one single thing, and that something can be good in one way but bad in another.
Its kind of like all those wine is good for you vs bad for you studies where both are kind of correct but in different ways.
The magic isn’t in the client it’s in the delivery pipeline. If nothing is classifying the message into a bundle on the backend, what is the frontend going to do? Of course you can replicate all this yourself but it’s going to be a lot of software to write.
What I miss most is not the auto-bundling, but writing rules to tag emails with a label and the viewing (and archiving) everything that matched as a bundle.
Seems like all the backend that’s needed is built into gmail, what’s needed on the client is knowing which labels to display as a bundle.
No, no - I definitely miss the autobundling. The auto bundling of github emails by repo is possible the only thing that's been keeping me sane, since I get a _lot_ of notification traffic, much of which I should read about, at least... I can't really setup rules for that - I could setup rules for repos I already participate on (ungh, that's a lot), but every random new repo would be another tag and another rule. Eck.
Inbox made that management drop dead simple. I lament it's loss.
Formatting dates with a format string is an anti-pattern. Format strings are too easy to get wrong and don't scale when you need to account for different locales. JavaScript's Intl functions do this correctly by providing an api that accepts a locale and options like weekday: narrow|short|long, year: numeric|2-digit, etc.
const only guards against changing the reference that it was assigned to. This won't break because info is still assigned to the same array. It doesn't matter that the array was mutated.
I think this article ignores that JavaScript's standard library has been growing in pace with new language features. The author mentions underscore as a good place to draw inspiration, but a ton of it's functionality has already been added to the language. forEach, map, reduce, filter, every, some, and others were added in ES5. ES6 brings find, includes, isArray, Object.assign and others. Promises were also added, make a library for them now unnecessary. Many of the current proposals aren't just for syntax additions to language, but to implement more standard library type of stuff (including string padding).
They say they don't inline because it doesn't make sense in their case, but if you do inline and use xlink [1], you don't duplicate data transmissions.
There are other techniques for client side-templated sites that will cache SVG icon data. For example, angular material's icon service [2] does this.
The repetitions would have to appear within 32KB of each other to be captured in the DEFLATE window [1] which, given that a lot of pages can be 100s of KBs of uncompressed text, may make that impossible.
Additionally, the zlib (or whatever) compression settings would have to be set aggressively enough to identify those duplicates as the best run-lengths to encode. Since GitHub is generating a lot of this live and delivering with low TTFB, they may be using a less aggressive than necessary setting.
I could see this being an issue for a highly complex vector shape. But most shapes only consume a few bytes. Compared to an external image or another request for the font files.
