Large parts of AS3's feature set actually were considered for standardization, back in the days of the "ECMAScript 4" standard (in quotes because it was never released). That standard was abandoned, due to differences some dismiss as politics and others claim were due to implementation and complexity issues.
Website != API. A cleverly-written API can exist in the same space as a Website (even the same URLs, if you differentiate by things like Accept: headers), but they're not the same thing.
XSLT was an interesting language that unfortunately tried to solve the wrong problem. What we needed was AWK for the DOM. Instead we got a vision where XML would be used to transform other forms XML into yet OTHER forms of XML, and the result was a mess.
I think there's still a place for an "AWK for the DOM". The XML extensions to gawk are interesting, but not really what I'm talking about; it works at a lower level (more like an "AWK for SAX"). jQuery comes closer to what I'm talking about, but I still wouldn't really call it a clean match.
The HTTPS-only folks mean well, and I support it as a stopgap solution, but it is useful only in that it can probably be implemented more quickly than IPSec-everywhere (or, if IPSec proves to be unsuitable, then some successor standard with the same goal of encrypting all traffic).
The latter, however, should be preferred as a permanent solution. The Web is by no means the only part of the Internet that needs to be secured.
IPSEC and HTTPS work at different levels. With IPSEC, your computer can be sure it's talking to the computer at 198.51.100.1 and not to any other computer. With HTTPS, your browser can be sure it's talking to www.example.gov and not to any other web server. Both work equally well against passive eavesdroppers, but they authenticate different things and so will work differently against active attackers.
Oh, no, it's useful for what it's designed for: to protect communication between two computers. If I have IPSEC protecting the connection between my desktop and my internal DNS server, and between my desktop and my database server, I know that connection to my database server is protected by IPSEC.
It doesn't protect the mapping between a computer name and a IP address, but that's not its job.
I think it's more like IPsec hasn't happened because it's a huge hairball of complexity which requires kernel-level configuration on every client and full end-to-end support for two new IP protocols and a UDP key management service.
In contrast, TLS requires using a new client library and works just about everywhere. All of the work people have been doing to switch to strong crypto everywhere and deploy things like perfect-forward security? Imagine how quickly that'd have happened if it required everyone to install a kernel update.
Until IPsec becomes easier to use (something as simple as checking that a socket is actually secure used to be shamefully under-documented) the best way to think of it is as a potential replacement for proprietary VPN protocols. Anything which cares about security will still need TLS over that so most people will simply use only TLS.
It's worth noting that HTTP(S) has broadened outside of the web, in the sense of web browsers. Most native mobile apps, and lots of APIs used by desktop apps, etc., all use HTTP to get their job done. Definitely doesn't cover everything, but I think it's fair to say that HTTP is basically the protocol of our lives right now.
It makes sense to me that depressed people are just as accurate at judging time as non-depressed people. In cases where depression has a sudden onset, that "slower" rate of time passing might take some getting used to. But eventually you WOULD get used to it, and start to judge the passage of time from that frame of reference.
There's no reason that couldn't be just as accurate as a non-depressed person's judgment. It's just a matter of relearning the skill. Or learning it in the first place, to those of us whose sense of time wasn't so acute to begin with.