Web applications

From Pin Eight
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]

Some traditionalists remember protocols other than HTTP, such as SMTP, IMAP, IRC, Usenet, FTP, SSH, and the like. They suggest that applications with interactivity needs greater than navigation and form submission be replaced with with non-web protocols that are publicly documented with a reference implementation distributed in source code form under a free software license.[5] It remains unclear, however, how "here's a free protocol, here's a reference server and client for GNU/Linux or macOS, feel free to pool your money with other people to hire someone to write a client for the proprietary or semi-proprietary[6] platforms that people actually use" can lead to adoption by enough people to replace entrenched web applications.


  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
  5. Conversation between tepples and Editorial Failure, 2021-02
  6. A popular "semi-proprietary" platform is Android, which is free software, combined with Google Play Services, which is proprietary software.