I would wager that the average quality of an iOS app written by someone like OP that "has a web experience and _has_ to learn iOS just to work on that platform" will probably be lower than if that person (with web experience) could just extend their web app natively with PWA.
I completely agree with you that the app should feel native to the platform (I actually quit a job a while back because they wanted me to theme our web Android experience as iOS for "consistency across all devices" instead of matching the user's device's design patterns), but there is huge value in giving the devs the tools they need to write the best product they can, and splitting codebases and requiring more work/knowledge/moving parts is actively detrimental to a quality end-product for everyone, unfortunately.
That's a business choice that they made, and will suffer for. If a developer and business choose to half-ass the native iOS application, there's no reason to believe it would behave any better on iOS when written as a webapp.
> the tools they need to write the best product they can
The best product that can be made will never be made with cross-platform tooling. It will always be lacking. My proof for this? Java programs. TCL programs. Electron programs. There has yet to be an application which uses the same GUI code across applications that is as good as a native application.
You're making a circular argument to the original point. If you pointlessly cripple the best "cross-platform toolset" (the web) then of course the products made with it won't be as good.
Native mobile apps belong in the same category as desktop apps - they are good when you need close-to-the-metal graphics but there's no reason you should have to open up a desktop app to read the news or even do some light word processing.
I've used Electron apps where no such restrictions have been put in place; it has lead me to believe HTML/CSS/JavaScript is nowhere near the best "cross-platform" toolset. It's more accurate to say that it's the lowest common denominator. Electron desktop apps today look and act like Java apps from ten years ago.
I'd say that the onus is on web developers to prove that it is capable of creating cross-platform apps that are even as good as, say, Eclipse, before attempting to call themselves "the best".
> do some light word processing.
Due to how much latency affects typing and interaction with an editor, I absolutely do want a native desktop app - neither Atom nor VSC react quickly enough for my editing uses, and Google docs is aggravating to write more than a page or two in.
As for the web being the de facto solution for light tasks, I'm not sure I agree there either, at least with the web's present resource consumption problems. There's no reason, for instance, for a word processor that barely matches modern WordPad or Word 95 in terms of features to be as heavy as it is (Google Docs).
If web apps were being approached from the angle of resource consciousness and taking advantage of platform strengths, I might have a different opinion, but that's not what anybody developing web apps wants.
This is hard to argue for/against, because having one (native or cross-platform) generally precludes you from simultaneously having both (necessary for a proper comparison).
Of note: I find Slack's Electron client as good as, if not better than, many native applications that I also use in my workflow. There are also benefits I know exist (as a dev) that I don't see (as a user) like shared code that shouldn't be discounted just because the end-user can't see them -- they indirectly result in a better product for the end-user by making it easier to add new features and maintain existing code.
Also: I've never had any issues with Minecraft's cross-platform java client either. Would it be any better as separate native apps targeted at each platform?
We already see this (and solve for this) on desktop and platforms with a lot of variance in capability like Android. Just because people out there run 2.3 Android doesn't mean my 7.1 apps are going to be any less quality, even if they still work on the least-capable platform's featureset.
The obvious solution to this is to exclude or disable features from devices that can't handle them, which is also possible and encouraged on the web (with some decent precision through identification and fingerprinting provided by a myriad of things like service workers). Your banking site probably works in IE8 (barely), but that doesn't mean your up-to-date Chrome/Safari/whatever is going to be a worse experience.
>If web apps were being approached from the angle of resource consciousness and taking advantage of platform strengths, I might have a different opinion, but that's not what anybody developing web apps wants.
Web apps are focused on optimizing _different_ resources than native apps, that's all. Google Drive, for example, offers me an experience with no local installation cost in storage, virtually unlimited storage space for files, ancillary services like backups/authentication/sharing/etc handled for "free", native-like responsiveness while working offline, a low barrier-to-entry (unlike downloading/installing an app), a smoother experience across multiple devices, etc etc. These are all qualities that a web experience does better, and I think these are all qualities that people (myself included) value over the separate benefits of traditional native apps.
Do you feel the same way with QT?
There's a reason all of those you cited failed. That reason is not "a cross platform environment can not be good".
Java on a phone is nothing new, but the Java for Symbian you'd write probably wouldn't work very well on a desktop. VC++ for Windows Mobile apps wouldn't work well on a desktop either. The web is the lowest common target, even though it's quite a high level to target. We still run into plenty of HCI issues (why is there a big fat + button in the lower-right on my laptop in GDocs instead of "New" or File -> New action? Because Material is mobile-first and applied thoughtlessly to non-touch experiences), but if you play your cards right, it's now possible to have a codebase, and truly the same app, running on whatever OS and architecture the user has, without specifically building and packaging for 30 different target combinations.
Never is a pretty strong word. Have you tried some of the apps on the site pwa.rocks? Flipboard and AliExpress are non-trivial examples of PWAs that do a good job. Who knows what app development will be like in 5-10 years?
As a developer I would much prefer a cross-platform way to write apps.
Have you looked into the web components spec yet? I think a combination of PWAs + Polymer (or React with web components) has a pretty good shot at easing cross platform development. It already has the support of most browser vendors and is relatively easy to pick up.
If I'd have to guess, I'd say that all of your examples sucked in different ways and it is not a general trend.
True or not, this is only relevant if it's indubitable that every app has to be 'the best product that can be made' in terms of platform-centric gold-plated polish. But it's not. Values often clash and tradeoffs are made. For some apps I would prioritise cross-platform availability far above platform polish. For others the converse is true. Some products don't merit the effort or expense of being 'the best product that can be made'. Others do.
Yes!
Qt is a nice library, and was almost certainly the right choice for an open-source application like Wireshark that had previously used the execrable GTK lib on non-X11 platforms, but Qt tries really hard to make water not wet in MANY cases.
Just look at what it takes to get a Mac Qt application to work well in full-screen mode on multiple monitors. Or handling keyboard-focus changes when a notification window pops up (especially one for iMessages). Or any number of things where the underlying platform libs on Windows, MacOS, and X11 differ significantly.
People who've only programmed web applications don't understand how weird platform GUI libraries are or how many corner-cases they have, especially when dealing with multi-window applications, keyboard focus changes, and notification & tool windows. Programming an application to this stuff is tricky - wrapping it in a cross-platform lib is nearly impossible!
Qt exactly proves the point that cross-platform libraries will NEVER give you the same high-quality experience that native applications written to the platform libs will.
That says nothing except the sad state of the other native apps you use in your workflow.
The truth is that yes, indeed, I can find a lot of native apps that are just about as "good" as slacks native Mac (and iOS - it's really bad too) app, and I can also find a lot that are a lot worse. But why compare to them at all? We should be measuring how good an app is by comparing it to, in this case, the best of the best native apps on the particular platform, or across all platforms, if so desired.
How much latency are we talking about here? I can't imagine how latency would affect typing..
> and interaction with an editor
Agreed, but again, how much latency are we talking about here? The projects I've used VSCode on have never had latency issues.
That way, the bulk of your team maintains the business logic, and you can get away with much smaller teams for the platform-specific bits.
These things _used_ to work in the Slack app. What happened?
I feel the same way about Jupyter. Sure it's very clever to run it in a browser but it is clunky as hell compared to native RStudio (free) or MathCAD (commercial).