> 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.
XSLT would be a classic answer, but it's a bit of a lost ancient technology these days. I've only used it in the browser for a lark, but I suppose you'd find mature (old) libraries for working with it easily enough.
PHPTAL is another system I've heard of (but never used) that seems to be built on this idea. It is also very mature (old). https://phptal.org/
In general working with DOM doesn't seem to be very cool these days. Everyone uses template systems that are glorified string concatenators, like Mustache, and doesn't care about security issues due to bad escaping.
I mean… yes? I don't see what's so confusing. In an office building, if anything goes wrong, an alarm goes off and everyone leaves, and insurance pays for damages. In a residential building, you have people sleeping, sick, possessions they might not be willing to leave behind, babies, pets… It makes sense for the safety requirements to be different.
Yes the idea isn't terribly new, but this implementation is significantly more elegant (and ruby-ish) thanks to what looks to be a great design and the capabilities of Crystal. rubyinline is neat but honestly not something I'd seriously consider using in a production project. I need to try out crystalruby before I have an opinion on that, but it looks very promising!
> Just like you wouldn't add spaces in the middle of '2>&1' when redirecting stderr to stdout:
Mostly because if you do it doesn’t work: '2 >&1' is not the same as '2> &1' (invalid syntax) which is not the same as '2>& 1', which …is the same as '2>&1'.
It used to be that the only programs capable of somewhat correctly parsing HTML were web browsers, each one of them produced different results, most weren't open-source, and none were reusable as libraries. If you wanted to parse HTML in... looks up what MySpace was written in... ColdFusion, you were all out of luck. Since then people spent years developing specifications and writing the libraries, so now it's not a big deal.
