>there's almost no native-feeling cross-platform UI library for native apps at the moment
Xamarin.Forms is the closest I can think of. Qt too, kind of.
>The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence.
It's true, the browser succeeded as a working everywhere JVM equivalent.
It also succeeded at reimplementing half of your OS features, being another massive source of security issues, being inefficient with resources (chrome memory usage lol), having piss poor perfomance and locking everything to Javascript. Compiling to Javascript is not a solution. A proper bytecode is. Which we may have with WebAssembly as soon as it's implemented and the standard respected by browser builders (which will probably be around 2040). Until Google decides to add a new WA feature that's incompatible with other browsers because that's what Google does. Let's not get started on the fact that HTML is a terrible language for UIs and that any Javascript based solution is not a solution at all (i.e. React is still crap, as is Meteor and javascript.framework.of.the.day.js).
The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page.
> if Google, Apple, and MSFT decided to jointly ban all native apps and only have a web browser on their smartphones, we would have a much better compatability situation, since so much functionality has been standardised on that end, and _actually respected_.
1. We've been hoping to get at least TWO browser vendors to fully collaborate for the last 20 years and it has not happened. It won't happen.
2. Performance will still be crap.
3. I'd rather not get locked to Google's piss poor record of updating the stock Android browser. In fact, I'd rather not get locked to Google's piss poor software at all, thank you very much. The same argument applies to Apple and Microsoft. Safari is awful, and so is IE/Edge.
> the only cross platform UI experiment that has 'worked' on any significant level.
Users do not care about cross-platform compatibility, at all. They only care that it works on their platform. As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc.
The only people who should be upset about cross-platform compatibility issues are budget-conscious managers and unfortunate OSS devs.
>As developers, we should be cheering for a diversity of widely-popular, mutually-incompatible platforms because there will be more work for developers to port the iOS version to Android to Windows, etc.
This is like saying "As construction workers we should be cheering for natural disasters, because there will be more work for construction workers to rebuild destroyed cities."
Job security is great- but at what cost? I'd rather see developers making completely new things than wasting time porting from one native platform to another.
And honestly, whether as a construction worker or a programmer, I, too, would rather be building new things than rebuilding the same goddamn thing over and over again.
What a hyperbolic analogy. No, porting to new platforms is not like recovering from a natural disaster, and rooting for competing platforms is not like cheering for the misery of a disaster.
And for the record, doing a port well (as opposed to a hacky, broken one) frequently requires lots of creativity and technical ingenuity.
The web has no meaningful UI. The entire window is just styled elements.
UI is not always about respecting the OS's guidelines/theme. Firefox, for example pretty much ignores everything since their Australis UI update and it is fine.
4.4 is KitKat. 4.0 is ICS, 4.1-4.3 are Jellybean releases.
For native apps, anything Jellybean or better is reasonably easy to deal with (and ICS isn't that bad). But for webapps, the system webview was the horrible default Android browser up until KitKat, and didn't get auto-update until Lollipop. Android Browser has a number of outright bugs in its spec compliance (when I was developing for Google Search, we thought of it as the new IE6), and you lose any sort of GPU acceleration or fast JS engine that you might want for animations.
> Let's not get started on the fact that HTML is a terrible language for UIs
This is why I'm hoping that future web front-end frameworks will output UI elements to a <canvas> instead of the DOM.
If a DOM-like scene graph is needed, it should be managed entirely by the framework and simply be an intermediate layer between the application code and the <canvas>.
As a blind user and developer I am absolutely terrified by such a prospect. We've just started to get decent accessibility for the plethora of new web features with ARIA and similar. But if you render everything to graphics output directly to a canvas you lose any capability of ever talking to my screen reader. Text is awesome for both people and machines, let's not throw it out.
Xamarin.Forms is the closest I can think of. Qt too, kind of.
>The browser is basically what the JVM tried to be, a write once work anywhere solution that is pretty well sandboxed. It's miles better than pretty much every other cross-platform piece of tooling in existence.
It's true, the browser succeeded as a working everywhere JVM equivalent.
It also succeeded at reimplementing half of your OS features, being another massive source of security issues, being inefficient with resources (chrome memory usage lol), having piss poor perfomance and locking everything to Javascript. Compiling to Javascript is not a solution. A proper bytecode is. Which we may have with WebAssembly as soon as it's implemented and the standard respected by browser builders (which will probably be around 2040). Until Google decides to add a new WA feature that's incompatible with other browsers because that's what Google does. Let's not get started on the fact that HTML is a terrible language for UIs and that any Javascript based solution is not a solution at all (i.e. React is still crap, as is Meteor and javascript.framework.of.the.day.js).
The web as an application delivery medium is a failed experiment, patched up on all sides and held together with 40MB of polyfills on every page.
> if Google, Apple, and MSFT decided to jointly ban all native apps and only have a web browser on their smartphones, we would have a much better compatability situation, since so much functionality has been standardised on that end, and _actually respected_.
1. We've been hoping to get at least TWO browser vendors to fully collaborate for the last 20 years and it has not happened. It won't happen.
2. Performance will still be crap.
3. I'd rather not get locked to Google's piss poor record of updating the stock Android browser. In fact, I'd rather not get locked to Google's piss poor software at all, thank you very much. The same argument applies to Apple and Microsoft. Safari is awful, and so is IE/Edge.