Thank you. People calling web-render wrappers "native applications" must not realize how great it is when applications are mere coördinators on top of an integrated platform full of services designed to improve user productivity.
I guess if that demographic did, there would be less "unix philosophy" cultism, as the efficacy of the unix shell is merely on par with that provided by other relatively coherent software toolsets. The shell is really pretty barebones compared to the rich semantics provided by many toolkits and object systems on which user interfaces have been built: GObject and NeXT are two modern examples.
[That said, where shell shines is by providing so few abstractions that virtually any garbage has the same semantic depth as things which were designed to be used in the shell. Bytes are universal on the common computing substrate.]
The web, on the other hand, is a platform "designed" by the erosive flow of eyeballs during the 1st-nth browser wars, without much of a direction beyond tacking on additional pretty features without breaking backwards compatibility too much.
Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns. Look at how screen readers break on js-heavy and dynamic web pages, the ongoing security disasters of XSS and iframes (and the complexity of login services like Facebook's/oauth/openid), the disappearance of Google reader, and the half-assed way CDNs offer partial, ad-hoc offloading of some resources via surrender to centralization.
> Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns.
...what? The web is better than most native platforms in these.
The web is accessible. It has many features for screen readers and such, but more importantly, it is inherently flexible and allows content's form to be adapted to the reader's needs, thanks to the separation of content from style. A single web page, unmodified, can work on a desktop PC with a mouse and keyboard, a capacitive touch device the size of your palm, a stylus-input device the size of a laptop, a printed page, a screen reader, a ten key mobile phone from yesteryear, and more. The web lets users define custom styling that meets their needs, lets users selectively remove content (ads, for example), etc. No native platform is that flexible. Yes, some sites break screen readers, but this is true of native apps as well.
The web is incredibly embeddable. Any web page can, with one line of code, incorporate any other web page, and it "just works". You simply can't do that with native apps.
The web is composable as well. Sites can load JavaScript from each other very easily.
The web also supports resource sharing in various forms, but people don't necessarily use them.
Alas, all the benefits you list are just possibilities, not the reality. "separation of content from style" was a big thing back when csszengarden.com was making rounds, but that all is long forgotten in the name of angularreactnodecrap. Accessibility? Give me a break, how many web sites do even work without JS enabled?
I am not sure about Android, but iOS has a great accessibility support.
Separating style and content isn't dead. It's more popular than ever. HTML5 has brought in new semantic markup and discouraged presentational markup. Most sites even today work fine without CSS.
I agree that these are all legitimate problems, but over time the wrappers themselves will eliminate a lot of them. There will always be "native" wrapped HTML apps that do a bad job of taking advantage of the platform. That's the case with any adapter platform that lets you code once and deploy everywhere (look at 90% of Java-based apps). But that doesn't mean that it will inherently be a bad idea.
Indeed, Electron already is starting to provide these kinds of facilities. For example, it allows you to load native node modules, and it provides some tools for integrating with the desktop envirionment (see https://github.com/atom/electron/blob/master/docs/tutorial/d...).
Side note:
> coördinators
I knew I wasn't the only one who loves this pretentious diaresis style. Stay strong, brother/sister/sibling. Stay strong.
I guess if that demographic did, there would be less "unix philosophy" cultism, as the efficacy of the unix shell is merely on par with that provided by other relatively coherent software toolsets. The shell is really pretty barebones compared to the rich semantics provided by many toolkits and object systems on which user interfaces have been built: GObject and NeXT are two modern examples.
[That said, where shell shines is by providing so few abstractions that virtually any garbage has the same semantic depth as things which were designed to be used in the shell. Bytes are universal on the common computing substrate.]
The web, on the other hand, is a platform "designed" by the erosive flow of eyeballs during the 1st-nth browser wars, without much of a direction beyond tacking on additional pretty features without breaking backwards compatibility too much.
Attributes like a11y, embeddability, composability, and effective resource sharing tend to simply fall out of well-designed platforms. The web has an effective answer for none of these desirable concerns. Look at how screen readers break on js-heavy and dynamic web pages, the ongoing security disasters of XSS and iframes (and the complexity of login services like Facebook's/oauth/openid), the disappearance of Google reader, and the half-assed way CDNs offer partial, ad-hoc offloading of some resources via surrender to centralization.