> 'What would make for a better cross-platform development experience?' Back in the day, people balked at using Java as a universal portable application platfo

> 'What would make for a better cross-platform development experience?' Back in the day, people balked at using Java as a universal portable application platform, because ironically, everyone wanted their own language and their own platform semantics. Yet everyone on the planet has already unanimously agreed to a cross-platform development platform with a strict set of languages: - HTML/CSS for presenting text/style/layouts - Javascript for crafting and organizing the UI - WebAssembly for compiled code run in a VM - HTTP for IPC So right there you have prescribed languages, formats, protocols. We gave up a single simple prescribed system for a more complicated one. However, if you wanted to, you could get rid of the browser, and still support those same things - plus everything else a native app can do. Separate those components into libraries, then link those libraries into your app, have your app load the libraries & components you want, and configure how the library should handle the presentation, UI, and business logic. You're then basically shipping a custom, streamlined browser - except it doesn't have to obey browser rules! It can run any code you want, because it's your app. It can present any way you want, because it's your app. But it's also portable! The UI, the business logic, presentation, would all be using libraries ported to multiple platforms. Just recompile your app on the target platform. Avoid native code for an instant recompile, or add native code and deal with the portability tax. It's sort of like compiling one browser on multiple platforms, except 1) it's broken down into components, 2) you can interchange those components with ones from different vendors that follow the same standards, and 3) you are not limited to these libraries - you can add your own native code. In terms of interoperability with other apps, use the same network protocols, the same URIs. You can add new ones too, if you prefer, just for your own custom backend for your app... but probably everyone will stick to HTTP, because it's a universal way to access everyone's backend APIs or other native apps across sandboxes.