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.

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 users claim that interest-based advertising has poisoned the well for all JavaScript in the browser, and 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 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 redecoding and rerendering them.[1]
  1. JNCF, 2019-07-20