Web applications

From Pin Eight
Revision as of 03:38, 4 February 2020 by Tepples (talk | contribs) (iPhone and iPad: Rephrase to remove outdated things, as capacity is a non-issue)
Jump to: navigation, search

This is a mini-rant, a short essay refuting a common misconception among users of an Internet forum. If you think this essay is FUD, feel free to explain why on the essay's talk page.

Some people propose to circumvent the political restrictions on applications for mobile phones and consumer tablets, such as the rules of the iPhone Developer Program, by replacing them with web applications. This just trades off political restrictions for technical restrictions. A web application environment capable of replacing the native execution environment would require well-documented JavaScript APIs for every input device on the hardware, including multitouch and any built-in camera, accelerometer, and GPS. It would also require a highly optimized JavaScript JIT engine, WebGL, and full support for HTML5 offline features (Service Workers and localStorage/IndexedDB). It took several years for this situation to improve.

iPhone and iPad

The browser on the iPod touch, iPhone, and iPad is Mobile Safari. Per Apple's App Store Review Guidelines, all other web browsers that run on iOS and iPadOS wrap the same system WebKit library as Safari. This means they have the same deficiencies in support for web platform features as Safari, no more, no less.

Despite iOS 1.0 touting Safari as the primary programming interface for the original iPhone, it took several years for Safari to gain support for key web platform features. It added support for accelerometer, JavaScript JIT, WebGL, service workers, and even HTML file inputs years after Chromium or Firefox added them. Initially, the total size of an application with offline support was limited to 5 MB for application cache and 5 MB for localStorage. By sometime in 2019, these were phased out in favor of service workers and IndexedDB, and iOS had increased the limt to 500 MB,[1] making capacity far less of an issue. Thus some Progressive Web Apps that work in Chrome and Firefox for other platforms can be made to run on Safari, but others cannot.

No script

Some traditionalist users refuse to run script (JavaScript or WebAssembly) for several reasons. One is that interest-based advertising has poisoned the well for all script in the browser. Another is surreptitious mining of Monero cryptocurrency.[2] A third is escape defects in browsers' JavaScript VMs.[3] But these users have so far failed to explain how installing a native application is any safer than using a web application. Even an application distributed in source code form under a free software license depends on possibly dozens of libraries that even the application's developer probably has not thoroughly audited, as shown by the Heartbleed incident in OpenSSL and several attacks on NPM.

Some of these script skeptics claim that static web pages gain no appreciable benefit from JavaScript. Other users point out that even for a blog or other relatively static website, handling navigation within the site as a single-page application using JavaScript when JavaScript is available may still show a speed advantage over a no-JS full page reload on every navigation. In a site structured as a single-page application, the server can skip resending the markup for navigation areas that surround the article at the top, side, and bottom.

And even though images and other subresources in these areas are probably cached, the browser can skip spending CPU time on redecoding and rerendering them.[4]
  1. Chris Love. "What is the Service Worker ⚙️ Cache Storage Limit? How Much Your Progressive Web App (PWA) Can Store". Love2Dev, 2019-10-29. Accessed 2020-02-03.
  2. Catalin Cimpanu. "Half of the websites using WebAssembly use it for malicious purposes". ZDNet, 2020-01-07. Accessed 2020-01-10.
  3. Zack Whittaker. "Mozilla says a new Firefox security bug is under active attack". TechCrunch, 2020-01-10. Accessed 2020-01-10.
  4. JNCF, 2019-07-20