HTTP was not designed for apps, it was designed for serving HTML. We had a decent solution in Java applets and the tech giants could play nice so we couldn't have nice things.
The work around has been a huge kludge of crap frameworks of the day trying to reinvent the OS and associated API in the browser. It sucks all the way down.
Apps are:
More powerful
More efficient
Have better tooling
Have stable APIs
Are easier to debug
Require devs pay a tithe to the app store owner
Are less able to be customized, reverse-engineered, and controlled by the user
Are subject to arbitrary, vague, constantly shifting, opaque app store approval rules
Require constant updates just to continue existing, since the platforms they target don't care for backwards compatibility, and are constantly releasing updates
Are hostile to open source projects that have limited resources, as those represent a drain on the system, since they generate no revenue
What does it even mean?
> More efficient
Debatable. Depends on implementation.
> Have better tooling
Absolutely no. I’m yet to see any native toolkit that has even feature parity and nice DX compared to web development.
> Have stable APIs
Ask Android developers about stable APIs. Also, which web APIs do you find unstable?
> Are easier to debug
Debatable.
The two versions written by one man as experiments and used by (by reasonable interpretation) absolutely nobody.
HTTP 1.0, the first "real" HTTP did indeed include support for images at some point prior to being finalized as RFC 1945.
Uh!