I don't think that's true. Some years ago I did a free trial with them (did not pay anything). More recently I decided to actually sign up (for a paid account) and the email address I used for the free trial years ago was not available. I eventually got that username only after contacting support and giving them the date on which I started that free trial, to prove it was me.
> This long-standing quest, known as chrysopoeia, may have been motivated by the observation that dull grey, relatively abundant lead is of a similar density to gold, which has long been coveted for its beautiful colour and rarity.
It makes sense though -- Gmail has little in common with normal email besides usage of SMTP transport, and has a lot bigger market share than normal email. (Exchange also doesn't count as "normal email" - so that's the reason for my confident assertion.)
I don’t think it makes sense, per se, considering Gmail’s ubiquity comes from Google offering it as a free product, and then all the barriers to creating an email provider being raised in an attempt to combat spam.
There’s barely any point in setting up your own provider now because you have to compete both with free. All the action has been around email clients which have typically been acquired and then crushed.
Google could have stuck with the protocol or presented a spec for it, rather than leaving the competition with IMAP and SMTP.
What makes sense is they dominated the market and helped put up roadblocks afterwards. EEE.
You're right, but the author's approach still works by accident, because ClearType is disabled when drawing text to canvas. I am not sure why that's the case, but I would guess it's because the subpixel colors can only be computed correctly when the background color is known (and static), and with a canvas, the background can be drawn later or animated. ClearType is only enabled for normal text on the page, and many CSS properties incidentally disable it presumably for similar reasons (e.g. 'will-change: opacity;').
You can keep your commands simple enough so that they can be executed by both `sh` and `cmd.exe`. If you need anything more complex than invoking other programs, `&&`, `|` and `>`, it's time to rewrite your build script in a real programming language anyway.
> Why can't I await in a normal function? await sounds blocking
> You can await in a normal function in better languages, just not in JavaScript.
Await, per common definition, makes you wait asynchronously for a Task/Promise. How on earth are you going to "await" for a Promise which also runs on the same thread on a synchronous function? That function needs to be psuedo-async as in "return myPromise.then(() => { /* all fn code here */ }), or you need to use threads, which brings us to the second point...
With the closest thing to threads (workers) in JavaScript and using SharedArrayBuffer and a simple while loop, perhaps (didn't think too much on it), you can implement the same thing with a user defined Promise alternative but then why would you want to block the main thread which usually has GUI/Web-Server code?
It seemed to me that the previous poster wanted a way to wait for the result of a promise (in a blocking manner), and I meant that this is available in other languages. You're right that it is not usually spelled "await".
Probably. I've encountered a case where setting `contain` for unrelated reasons noticeably decreased the GPU memory use as reported by the browser: https://phabricator.wikimedia.org/T373066#10096943 (search for "As a bonus"). Wikipedia is pretty light, so in absolute terms it wasn't really meaningful, but I could see that on a more complex site.
