But if your product is not just about information retrieval or collection, rather based on things like complex user interaction, persistent local data storage, integration with devices on the users machine or complex interactions that need to override mouse/keystroke behavior... then I'd question whether or not it should be a webapp.

Discord is a really good example of this to me. They have a web client, sure, but the app itself makes sense on the desktop. There's nothing wrong with using web technologies to build the app, but the mental model of how browsers send/receive data from a server somewhere seems fundamentally incompatible with how such an app should work.

What I meant by hostile is that publishing apps sucks for a lot of reasons, from lack of user demand to platform issues, poor sandboxing, distribution issues, etc. It's a shame, because that's how we wind up with such crazy complexity in web apps, when we could just stick to native OS APIs and call it a day.

So the solution would be to exclusively some "web technologies" (HTTPS, WS) to deliver content and messages to the application? I guess by creating a bunch of clients, managing request states and working around the intricacies involved there (or in the libraries you used).

So after that's done then lets add some kind of auto-updating mechanism. After a while you get it working, awesome. Lets hope users constantly keep it updated! Spoiler: they will not.

And then, when you think you're all finished, someone from product comes in and says "hey we want to A/B test this feature on these specific clients, when it's a Tuesday and they are connecting from India. Oh and these requirements will change every 24 hours". Great.

"If only there was some set of technologies that made all of these problems convenient and effective", you think to yourself as you check Slack.