> In PHP, persisting this sort of thing between requests becomes a painful task instead of a triviality

apc_fetch/apc_store hardly seems painful.

Session cookies were basically invented for transient statefulness over HTTP.

I'm not referring to per-user sorts of things. You can't cache those locally in a sane way in any language. I'm talking about what would usually be memoizable sorts of things.

There are memoization libraries for PHP but really it's just another cache implementation. Put it in RAM, put it on disk, put it in memcached or redis, I don't really see too much a difference between $cache->set($key, $value) in PHP vs cache[key] = value in node for instance.

if you need to persist some data/state between requests, php has a mature memcached extension. it's a fast memory store, but i'm not certain of the security implications since i dont think it has any kind of built-in isolation.

Sure, but that means I have to either run a memcached instance on every server (which I've actually had to do before just for the sake of PHP) or I have to make network calls for something I shouldn't have to, and then also do serialization/deserialization. That's fine for plenty of things, but certainly isn't optimal for all sorts of stuff.

Not to mention, all the other languages out there memcached just as well.

But in most languages http requests should be stateless. Even in node or Java you should be hitting the db to pull that info anyway, as sharing the last info in the process leads to scaling issues as well as big problems if the application crashes.

The alternative is crazy sharding systems which are becoming more and more difficult as devices are less and less "static"