Great video, but I would add a correction on re-frame regarding 26:32. As you said, the reason you do that encapsulation in Java is because you want to ensure the state of the class is private, and you do this by ensuring that it is only accessible through methods, so that state updates are controlled. The alternative is that multiple classes can access and write to the fields directly, which means you have shared mutable state and the obvious dangers that go with that. In re-frame, this is not even a possibility because you never access state directly. The unidirectional data flow, going from view -> event generation -> state change -> updated view, does the same thing as encapsulation. It ensures that state updates are controlled because the only way to modify state is to fire events and have re-frame itself coordinate the actual changes. It's identical to the reducer model of Redux, where you end up collecting state changes and applying them at the same time. I know it "feels" or "seems" like you are modifying state directly, but this is the reason you have to write subscriptions and events and so forth. It's so that the architecture can handle this for you in the background.