You don't need an Event Sourcing framework. Or do you? - Alexey Zimarev 

Very interesting discussion regarding Event Sourcing and enjoyed your presentation immensely!! One thing I would add is the need to define whether your use of Event Sourcing is for a single local domain or for large global domains. I have been using DDD ES/CQRS event driven architecture for nearly 10 years now but only for complex local domain apps which in my case was enterprise level domain trading applications. For more global domains apps, I think I would think very hard before entering a journey using Event Sourcing without a well proven framework because there are an awful amount of global domain technical issues that can easily swamp the simple left fold function concept of Event Sourcing starting with Day N+1 production problems. Basically, know your business model completely inside out BEFORE deciding if any bounded context actually needs to use Event Sourcing in a beneficial way as clearly defined by your business model from day one and make sure your business model acts as a constraint on what architecture you should use. In this way, an overwhelming number of technical issues can be slayed well before you go into production and therefore, make the life of your business users much easier.

This is fantastic. Really. I've been in the exact same situation, having to write checkpoints, versioning weak schema, projections boilerplate, etc. I am adopting eventuous for a new event sourced product we're using. The travel in time feature looks amazing. I didn't quite get the returning the state in http response. I guess what's returning is the aggregate state, but not the "system"/projection state, as read models could span multiple streams/aggregates, right? In any case, it looks great. Very good presentation