This is a ReactNative app that consumes XML and maps it to ReactNative components, so you're still using those pointlessly complicated technologies, but through a proxy application that abstracts some of the complexity away (https://github.com/instawork/hyperview?tab=readme-ov-file#hy...).
When you hit the boundaries of what Hyperview can do, you're going to need to dig into some of the details, but mayhaps you don't need those features. Either way, it's an interesting project, but like everything else it's going to have _some_ drawbacks
Just because there are multiple technologies does not make it complicated per se. Indeed, something could evolve to a simpler model, which it seems RSC on RN is.
Keep dreaming man. Just look at what Next has become... It has taken "render component on the screen" and turned that into an experts domain. It's a nightmare for anyone who isn't the most skilled, for projects that are more than just toy apps and AI one-offs.
Not sure about that, it's gotten easier as time goes on, especially with server actions. Previously we used something like OpenAPI to map types on the frontend and backend and had to make separate HTTP endpoints for everything. Now I just write a function and it's all taken care of automatically, I can put types and functions in any folder I want and it just works.
Yeah, the moment I read "Serve your app as XML" my brain instinctively began to move on but it's really just HTML-like semantic snippets that remind me of WebComponents. Example:
However, this warning statement should be in bold at the top: "If your app relies on offline data or local computations, Hyperview won't be the right choice."