Web applications

From Pin Eight
Revision as of 17:40, 10 January 2020 by Tepples (talk | contribs) (No script: Three excuses of script skeptics)
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.

This is outdated

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. These include WebGL (?) JavaScript JIT (4.3), accelerometer (4.2). I checked for how big a web app could be (tried Google mobile safari offline limit), and it appears to be limited to 5 MB. The localStorage object is likewise limited to 5 MB (tried Google mobile safari localstorage limit). Nor does Mobile Safari appear to JIT compile the JavaScript due to iOS's especially strong flavor of W^X (tried Google mobile safari javascript jit). Even accelerometer support wasn't added until iOS 4.2.

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.[1] A third is escape defects in browsers' JavaScript VMs.[2] 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.[3]
  1. Catalin Cimpanu. "Half of the websites using WebAssembly use it for malicious purposes". ZDNet, 2020-01-07. Accessed 2020-01-10.
  2. Zack Whittaker. "Mozilla says a new Firefox security bug is under active attack". TechCrunch, 2020-01-10. Accessed 2020-01-10.
  3. JNCF, 2019-07-20