“I got inspired by a recent Java talk[1] from a Netflix employee about how they are building.”
Netflix talk inspired the commenter's framework design thinking.
Full comment
Only in the conceptual stage right now. So far my thoughts are. An app framework targeting modern C++ (>C++20) based on Boost.Fiber and stdexec( sender/receivers when C++26 releases) I got inspired by a recent Java talk[1] from a Netflix employee about how they are building. I have the pretty strong opinion that async/await are implementation details and shouldn’t be exposed in APIs. They effectively have the compiler/runtime generate a state machine for you and you wouldn’t put a state machine in an api. Using C++ though we do have low level access to the CPU and there is no reason we cannot just use stackfull coroutines. This allows you to write literally synchronous code but it will defer blocking operations to an even loop and allow concurrency. For GUI at least in the beginning Im thinking that I just spawn a native window and it’s up to you how you draw to that. I’m targeting something basic on linux myself which means it will probably just be direct calls to the wayland compositor to create a window. Getting a context etc will be up to the user since my idea would be in windows we use C# and on macos we use swift for UI. Documenting and building tooling around getting those languages integrated feels like it would provide more benefits than actually trying to reinvent the wheel in C++. Likewise HTTP client will just wrap libcurl, for server side Im actually thinking of just calling into golang. HTTP servers aren’t the hard part, it’s all the infrastructure around it th