So you're saying software OEMs need to pick one of Windows or MacOS and not support any other platforms?
For example, IFileDialog maps to a Cocoa dialog on macOS, file picker on UWP, open dialog on Win32, document selector on Android and so on.
Yes, it takes some initial effort, but it only needs to be done once.
Do you need to design 5 designs that include 5 different buttons, 5 ways of navigating through the app, 5 different sets of icons, 5 different styles of animation, etc...
Hell even with a file picker, what happens when you use it on a platform that doesn't really have the concept of "files" like iOS or up to recently Android (at least in what is normally exposed to the user)
Roll in various versions of each OS and you are up to needing 10+ ways of doing most things. How are you supposed to create anything even remotely complicated?
Not sure I agree here. There are a great many browser features (e.g. web speech api for recognition and tts, webrtc, etc) that are just not lowest common denominator. Even if we stick with UI only, features like cross platform vector graphics are not trivial. Of course some libs like qt abstract it, but you're back to your same complaint except it's qml, css, and js (or often times worse, c++ if using widgets)
Most of it actually written in Assembly.
Magnitudes easier to shim and support multiple architectures.
It is all about design a good application architecture from the get go.
If you must run on every platform for whatever reason, there is Rust, C, C# (Xamarin), etc.
Cursors and styluses are accurate, but fingers are not. So, if you make buttons sized for fingers, they feel awkwardly large (takes large hand movements to change between UI components, and the spacing means more scrolling or pages of UI), but if you size them for cursors/styluses, they are frustratingly small targets for touchscreens.
You can probably assume that most devices in portrait orientation are that way so they can be held in one hand leaving the other free to work a touchscreen, so you only need to handle three of the four combinations for a comfortable user experience in those regards.
However, there's more to it than that. Desktop users often run apps windowed, while phones tend to omit that option entirely. Mac puts the menu bar at the screen edge regardless of the window size/position, but other desktop/laptop OSs usually put the menu bar within the window border. You can remove the menu bar entirely and draw a hamburger button into your UI, but desktop users have the expectation of a menu bar and the change in convention will make the app feel like an outsider.
A desktop/laptop user will never try a long press and don't have a menu button, both of which have been used to hide extra functionality on phones, but they often do have a keyboard, and there is a massive list of keyboard shortcuts that they will automatically use. Desktop UIs have a logical tab order and that selection can be moved with the arrow keys. Cut, copy, and paste function as expected. On windows, F2 almost always means "rename selected item", F1 for help, alt-enter to toggle full screen, and so on. What about the multitude of multi-finger phone/tablet gestures? You have two very different modes on input, and users' muscle memory expects your app to fully support whichever one they are using. As an anecdote, I tried writing something in an Electron app's text box, then went for ctrl-left to jump back a word, but instead it caused a page navigation and lost the entire message I was typing. That was a frustrating "this app is an outsider on desktop" experience to me.
Your decision is effectively mediocre everywhere or customized to fit the conventions for each platform.
https://books.google.co.uk/books?id=vPvhzDqZlaAC&pg=PA174&lp... (Spolsky)
See the Office related talks at CppCon 2015 about how to write portable code using what Microsoft calls the hamburger model, as part of their migration to a common codebase.
Basic a shim layer for low level OS APIs, the middle layer with the majority of code and another shim layer for UI APIs.
Microsoft calls it hamburger design, and has held three talks at CppCon 2015 presenting how they unified their codebase across all platforms. They are available on YouTube.
It needs to be redone for each platform every few years as apis and visual styles change. Cross platform libraries are notoriously hard and usually end up in the uncanny valley (qt, swing etc).
Platform vendors of course any devs to buy into just one platform, they want and need the lock-in. Using web UI is a way to sidestep that.