Yes, just like the DPS interpreter translates (high-level) DPS into (low-level) pixels. Looks pretty similar to me. (but then I am not overly familiar with DPS or ReactJS)
EDIT: To clarify, I am sure that the current UIKit also tries to do optimize rendering. They probably do some kind of internal batching, etc. But they have no (public) data format like DPS or a virtual DOM that is generated, optimized and rendered. I don't think that DPS is all that different.
It's not similar. Postscript (display or "regular") is imperative. It's an instruction stream.
React belongs one level "up", abstracting away the translation from a declarative representation of the view to a stream of calls on some lower level mechanism to reproduce that representation in the most efficient way possible.
The basic idea of React is that instead of having your application spitting out an instruction here and an instruction there, which may result in lots of reflows and redrawing, if individual state changes are expensive it can be more efficient to re-create a full representation of the desired state and have an engine compare that desired state to the actual state and figuring out the best possible set of steps to get from the actual to desired state.
E.g. the engine may be able to figure out that a subtree changes so much it's going to be best to just replace it wholesale instead of manipulating node by node.
The "output" from a React style engine can be a series of DOM manipulations, or it could be DPS instructions, or any number of other things - the idea is very general.
EDIT: To clarify, I am sure that the current UIKit also tries to do optimize rendering. They probably do some kind of internal batching, etc. But they have no (public) data format like DPS or a virtual DOM that is generated, optimized and rendered. I don't think that DPS is all that different.