(speaker here) regarding the limits of stateless apps see https://driftingin.space/posts/session-lived-application-bac..., the trend is that the more complex your app (think an IDE), the more the "stateless" approach is too slow and breaks down. (Note that what people call "stateless" is not stateless at all; there's database query effects, network effects, session state – and then on the client we have dom effects, reactive rendering and component local state. Modern web apps are actually entirely imperative except in isolated little components where we pretend)
The system we describe in the talk is indeed stateful, but it's worth pointing out that the Photon runtime is referentially transparent in the pure functional programming sense. People think functional programming is about avoiding state and effects; it's not. It's about gaining control over our effects so that we can orchestrate scaled up fabrics of millions of fine grained effects without loss of composition, reasoning or control. This is the promise of modern functional effect systems, and is the underpinning abstraction that powers Photon.
+1 for understanding that "stateless" doesn't necessarily mean better OR more performant. There's too much reductionist thinking based on not enough evidence. I'm not building a twitter clone, i'm building something that needs to frequently re-evaluate business rules at each step of a lengthy workflow. Reactivity is a natural fit. And there's state that exists there. Where do you want it to stay? (please don't say 'in a jwt')
There's room for so many different solutions to so many different problems. Shooting something down because its "stateful" well, okay if you know your problem domain well and that's significant to you then so be it, but that smells to me like "I have nothing valuable to contribute so I'm going to throw out a meaningless non-sequitur". I'll happily prioritize developer productivity first when user experience is not meaningfully impacted. I suspect that ~95% of web developers are in that same position.
Does this approach end up causing you to keep around more state (or other resources, like connections or whatnot) than would be typical in the traditional approaches? That's kind of where my mind was wandering with my comment earlier—not expecting statelessness for every application, but wondering if it becomes any more difficult to manage state than it would be normally. (Part of why I thought this might be the case is that people naturally try to minimize resources when they have to keep it around explicitly, but when it's done implicitly, I'm not sure if that becomes more of a concern or not. I could see it going either way.)
The system we describe in the talk is indeed stateful, but it's worth pointing out that the Photon runtime is referentially transparent in the pure functional programming sense. People think functional programming is about avoiding state and effects; it's not. It's about gaining control over our effects so that we can orchestrate scaled up fabrics of millions of fine grained effects without loss of composition, reasoning or control. This is the promise of modern functional effect systems, and is the underpinning abstraction that powers Photon.