Forem: Carlos Ouro

Pitch: Web-only PWA phone

Carlos Ouro — Thu, 20 Aug 2020 14:30:51 +0000

PWA is becoming more and more usual on our phones. If it's so easy to deliver and maintain, why isn't it more widely used?

In this post I'll propose a conceptual "app store" free mobile OS and a very different monetisation model, in a vision which would free us from biased store content and turn the mobile back to the free web.

"I want to make something really clear: We support two platforms at Apple. Two.
The first one is HTML5, a fully open uncontrolled platform (...).
The second one is the App Store. (...)"
- Steve Jobs, 2010

I've discussed how iOS in particular has moved from being the web innovator in 2010 to becoming the internet explorer of the mobile era.

What if a phone had only the mobile web?

But like... supercharged.

Hear me out -

What if we designed a ROM which only runs mobile web & PWA?

What if this new phone came with crypto wallet powers in web payments?

"Firefox OS again?" Not exactly.
Firefox was bound by 3 concepts we disregard here from the start:

hybrid downloadable apps from a store
cheap low-end phones
lack of monetisation strategy

Instead, we:

do not want a "store"
assume modern decent phones and PWA standards
drive phone lifetime monetisation to manufacturer

Note: In case you never heard of PWAs before - read about it here.

Mobile platforms - 2010 to 2020+

2010:

2020+ state of "mobile native pros":

Interface

Browser app controls still take considerable space in the mobile web interface :(
Not an issue on full-screen mode PWA :)

Offline Data

No longer an issue for DB & cache data
In DB file storage already available

Marketing

Driven by app store

Earning Bucks

Driven by app store

Richer experience

Not an issue for "common" apps in fact, a lot are just webview wrapped HTML5 today...
Games/3d/AR are quickly catching up (WebGL, WebXR, WebAssembly, WebGPU, etc)

We can see from the above that most issues on mobile web today are bound to the phone OS/store, its marketing and biased strategies, more than the mobile web technology which is coming leaps and bounds since 2010.

Re-imagining a Mobile OS

Interface

"Web content on my phone is simply not the same as apps"

The main reason for this is that you need to cater for the controls of the browser app itself such as address bar, settings, favourites, etc.
We still see the browser as a the app, and the web content as... just content.

The answer would be a web-only mobile OS UI.
By having the concept of “web browser” as the only client runtime, we can immerse the web experience into the mobile phone UI. Apps become just tabs, and “bookmarking” is no different from “installing”.

Let's take our modern phone to a "blank slate" and start off from a basic modern dashboard. Taking Android UI as a baseline, we could merge home+switch app buttons into a single button, and take the old switch app place and use it for context settings.

Then when we travel to a web page/app, say gmail, the web page would be an "app" in itself and always present fullscreen

This seems natural!
It doesn't "feel" like mobile web anymore.

But what about browser controls?
Remember the context settings button we've added?

Ok - now its even easier to control security and permissions for any app that on a "native" apps phone!

Offline Data

"Yeah but web apps can’t really create and store stuff locally"

Actually today they can.

There is already a suite of solutions for web apps in use today:
Storage API standards:

IndexedDB API - large amounts of data & files/blobs
Cache API - in-app assets cache
Web Storage API - in-app session information

We just need to organise appropriate storage settings and limits for installed and non-installed apps, and enable user review/override when necessary.
Managing in-device storage also becomes much simpler than in other mobile operating systems today that need to account with multiple storage solutions for different app types.

Marketing

"How are users going to get access to filtered quality content without a store? How are developers going to promote their content?"

The web already knows how to marketing

Ads and SEO have been around for a long time and they are the natural marketing strategies of the web.
It is the natural solution for developers which is provided out-of-the-box by the open web.

Having said this, the manufacturer could consider some kind of branded dashboard/portal where top compatible “apps” can be listed...

Earning Bucks

"Sounds like a cool project but we can’t really make money without a store"

Enter crypto-currency superpowers

Payment Request API already exists today.
With some work in this field we could easily can turn our phone into a eWallet for web payments.

Phone manufacturers can bundle their own crypto providers to phone users and thus leverage of small micro-transaction fees out-of-the-box with the phone.
Also - using crypto would make payments processing much easier in the web apps themselves.

Richer Experience

"But can the content quality ever really match up to native speeds?"

We know things have been evolving incredibly fast - we now have near-native speeds in web content today with WebAssembly, basic 3D graphics via WebGL, augmented reality capabilities via WebXR, threads via workers, and many, many other APIs.

Vulkan/WebGPU is expected to soon enable game developers to reach even closer to native-level graphics with thousands of 3D objects not degrading performance, much above the ~100 objects that we can do today with WebGL.

We don’t have the tools, frameworks and engines today that we do in native apps - but part of the problem is exactly because there has been no real need/business case for it. We just put up a native app instead.

But with broader PWA adoption and newer web APIs, developers will soon create such tools and there is no real technical limitation in the near future for any relevant discrepancy in web vs native experiences.

But would this actually work?

Probably not.

I've pitched the idea to a few people over the last 3 years, and mostly everyone discards it as meh.

So I've decided to post it here - maybe someone else will agree or build upon the idea :)

Embed Rust wasm into React

Carlos Ouro — Wed, 19 Aug 2020 21:00:29 +0000

WebAssembly is coming out to play. It's time for us, developers, to also move forward and push our heavy lifting computation algorithms into the low-level architecture in our products/libs/components and, together, speed up the web client as a whole.

What should know (at a high-level) before we progress:

Modern JavaScript;
React;
react-app-rewired pipeline;
Rust;

If you are looking for a non-Rust WASM approach

First, let's keep in mind how WebAssembly actually runs in a web page.

How does WebAssembly run in a webpage?

WebAssembly is a low-level module with a sandboxed shared memory allocated and managed by the browser.
Today, we instance these WebAssembly modules via JavaScript and can then interop with their shared memory and call exported module functionality.

Now we're ready to see how we can make our Rust code take some algorithmic load from our modern React web app.

When to use WASM instead of JS

JavaScript does an epic job in the web platform - it's perfect to describe events, functional flows and passing arbitrary small sets of data around. It has direct runtime scope integration into the window, giving you direct scope interoperability between different JavaScript modules loaded on the page with a simple single-threaded approach.
Perhaps one day we'll find an even better approach, but that is not the goal of WebAssembly.

WebAssembly thrives in heavy data manipulation and complex algorithmic logic and, last but not least, large chains of function calls.
Think about image/video/sound data manipulation, heavy string operations, game/scene object interpolations, etc.

You can read more at this great article by Koala42, where, near the bottom, he demonstrates how can WebAssembly be much slower or much faster than JS in 2 fairly similar tasks.

If you are curious, check the difference of factorize() and factorialize_fib() in both Javascript and Rust in his example source code to understand how is WebAssembly faster for factorialize_fib(), but slower than JS on the simpler factorize().

But the stack milord!

Indeed the modern web app is not bare metal anymore. Our JSX+ES7 codebase and 3rd party modules are bundled on-the-fly by complex build pipelines transpiling, collating and cleaning up code into a shinny optimised web app output that we actually don't know much about anymore.
This process takes away most of the cross-browser/transpile pain, but makes it hard to introduce something new or tweak under the hood.

Rant: I hope web standards adoption trends and perhaps a standardised react alternative (Web Components?) will one day bring us back to simpler build pipelines, closer to bare metal web and JS...

So, how do we integrate the modern stack with WebAssembly?

Back to the future

Let's assume you have some kind of react app with a typical create-react-app base template structure. This example purposely showcases the git repo.

- myApp
  | - .git/
  | - node_modules/
  | - public/
  | - src/
  | - config-overrides.js
  | - package.json

There are 3 different approaches to integrating WASM modules into your react app:

Use a provided wasm module via npm
Hook your own local wasm npm module into an app
Embed a wasm module directly into your app git repo

Use case 1. Use a provided wasm module via npm

This option is so simple you may even already be using 3rd party WASM modules without knowing.

You just have to add the published npm module into your package.json and use it directly.

npm install rust-wasm-react-calculator --save

Then simply use it in your react source code

// import
import { calculate } from "rust-wasm-react-calculator";

// and use
alert(calculate("14+5"));

I know, that's way too simple - this is why we should be using WebAssembly today for whatever is meaningful in terms of performance (keep in mind - it's actually slower for most common tasks!)

Next, let's see how we can create our own

Use case 2. Hook your own local wasm npm module into an app

First, in order to create and manage your wasm npm module, let's make sure you have wasm-pack installed with all permissions it needs

sudo npm i -g wasm-pack --unsafe-perm=true

Then, outside our app codebase, let's create our hello world wasm npm module

wasm-pack new helloWorld

You will get something like

- myApp
  | - .git/
  | - node_modules/
  | - public/
  | - src/
  | - config-overrides.js
  | - package.json
- helloWorld
  | - .git/
  | - src/
  | - tests/
  | - ... cargo files, etc

You now can see the actual Rust source code generated in helloWorld/src/lib.rs.
The public methods here will be available to be called in JS, and #wasm-bindgen takes care of passing things around on our behalf.
Read more about wasm-bindgen if you need to know how it works in greater depth.

Our piece of interesting code in helloWorld/src/lib.rs:

#[wasm_bindgen]
pub fn greet() {
    alert("Hello, worldview test!");
}

With a quick wasm-pack build an actual npm module will be generated into helloWorld/pkg - this is a ready-made wasm npm module with all the methods and bindgen stuff in it - much like the rust-wasm-react-calculator one we used for the example (1.)

To test it locally with your app, you can import it directly as a local npm module in your package.json with

{
  //...
  dependencies: {
    //...
    "helloWorldWasm": "file:../helloWorld/pkg"
  }
}

and use it in your app code like

// import
import { greet } from "helloWorldWasm";

// and use
greet();

Note: auto-update of the development server will not work out of the box - you will need to first rebuild helloWorld and then refresh your app.

Use case 3. Embed a wasm module directly into your app git repo

Finally, we come to the option where you really want to make rust part of your app and its source code.

We start off similarly to 2., by creating our own wasm-pack module.

Like before, in order to create and manage your wasm npm module, let's make sure you have wasm-pack installed with all permissions it needs

sudo npm i -g wasm-pack --unsafe-perm=true

Then, in the root of your app source, let's create our hello world wasm npm module

wasm-pack new helloHelper

You will get something like

- myApp
  | - .git/
  | - node_modules/
  | - public/
  | - src/
  | - config-overrides.js
  | - package.json
  | - helloHelper
     | - .git/
     | - src/
     | - tests/
     | - ... cargo files, etc

Next we need to remove .git from helloHelper. We do not want to have a submodule here, we want to have our helper as part of our main app repo itself.

rm -rf helloHelper/.git/

Note: It would be much easier if wasm-pack would allow us to create a module directly without VCS embedded, I've pointed this out as a feature request in wasm-pack

The final step is to hook it up to our react build, for this we will leverage wasm-pack-plugin.
Kick off by adding it to your app

npm i @wasm-tool/wasm-pack-plugin --save

Now we will let wasm-pack-plugin manage the wasm-pack build on our behalf on its own, with its own watcher and outputting the npm module (pkg) of helloHelper directly into our own app /src code. From there the react watcher itself also picks it up automatically and refreshes our app automatically when running locally.

To achieve this we need to hook helloHelper into our config-overrides.js using @wasm-tool/wasm-pack-plugin and make it part of the build. Additionally, we also need to ensure file-loader does not attempt to load .wasm file on its own.

In my case I am already using customize-cra, so I will just add two config filter methods of my own, but you could modify config directly in the same way.

const path = require("path");
const {
  override
} = require("customize-cra");

const WasmPackPlugin = require("@wasm-tool/wasm-pack-plugin");

module.exports = override(
  // make the file loader ignore wasm files
  config => {
    config.module.rules.find(rule => {
      return (rule.oneOf || []).find(item => {
        if (item.loader && item.loader.indexOf("file-loader") >= 0) {
          item.exclude.push(/\.wasm$/); //exclude wasm
          return true; //ignore remaining rules
        }
      });
    });

    return config;
  },

  //hook up our helloHelper wasm module
  config => {
    config.plugins = (config.plugins || []).concat([
      new WasmPackPlugin({
        crateDirectory: path.resolve(__dirname, "./helloHelper"),
        extraArgs: "--no-typescript",
        outDir: path.resolve(__dirname, "./src/helloHelperWasm")
      })
    ]);

    return config;
  }
);

And then we simply use our new local module directly in react:

// import
import { greet } from "./helloHelperWasm";

// and use
greet();

There you have it - let's npm start and let the real fun begin :)

Safari - The Internet Explorer of the Mobile Web

Carlos Ouro — Fri, 07 Feb 2020 16:49:55 +0000

It needs to be voiced.
iOS Safari has fallen from a spearhead of innovation in early 2010's to become the de facto limiting User Agent of the modern web.

I'll make my case in 5 parts:

A bit of history
Native & HTML5
So how is iOS Safari limiting the modern web?
- Viewport / fullscreen support
- Web Notifications
- Web App Manifest

Skip to the gist - tl;dr

Back in 2010

Back in 2010, Steve Jobs made a big case of why iOS would not support flash in his open letter Thoughts on Flash

Instead, Steve proposed a view of a mobile HTML5 era for the future:

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too)

This was followed up with Apple's clear statement of supporting 2 development platforms at Apple - HTML5 and App Store Native

I want to make something really clear: We support two platforms at Apple. Two.

The first one is HTML5, a fully open uncontrolled platform (...) we fully support HTML5 and Apple's browsers are in the lead in terms of supporting the full HTML5 standard. We are behind this 100%.

The second one is the App Store. The App Store is a curated platform (...) with the most vibrant app community on the planet.

With it, Flash was effectively out, and the new technology war in the mobile era had become Native vs HTML5.

Native & HTML5

In the coming years the two platforms would evolve each in its own way:

HTML5 continued in its quest to eliminate old proprietary technologies and standardise itself the open web - slow and steady but with guaranteed sandboxing and cross-device runtime
Native Mobile progressed to reach much higher levels of integration and performance - with much less sandbox boundaries and much quicker iterations it evolved much faster

But the reality is that not all developers needed the tight coupling with the OS provided by Native. HTML5 had kept on improving, steadily and firmly and reaching ever nearer its Native counterpart.

However soon the App Store had created a bind - not really a platform bind, but a delivery and profitability bind.

So came Hybrid apps - web platform runtimes that could be easily wrapped in a Native runtime. And with good design and implementation, hybrid apps were now indistinguishable from Native.
Although there are no official numbers, it is widely known and accepted that a considerable amount of applications today use this Hybrid approach.

So I'll be calling all apps delivered through an App or Play Store "Native" throughout the rest of this post.

So how is iOS Safari limiting the modern web?

In the past years, web standards have brought the web platform really close to the perceived "Native" standards.
With APIs like WebGL, WebAudio, WebAssembly, Workers, Fullscreen API, Push API & Web Notifications, Accelerometer, Gyroscope, Orientation, Network Information and Web App Manifest, you can now install and run a web app and perform almost any task without a visible difference from a "Native" one.

However most of such Web APIs are still lacking in iOS Safari.
The decision of not implementing such APIs by Apple have avoided that a web app can be installed and run like a "Native" one through the web platform directly.

There are 3 APIs in particular that are key to the perceived "app" experience in the OS:

Viewport / fullscreen support

The Fullscreen API adds methods to present a specific Element (and its descendants) in full-screen mode, and to exit full-screen mode once it is no longer needed. This makes it possible to present desired content—such as an online game—using the user's entire screen, removing all browser user interface elements and other applications from the screen until full-screen mode is shut off.
Fullscreen API - Web APIs | MDN

The Fullscreen API has been available in Chrome and Safari since 2011. It has never been made available in iOS Safari - not by a technical constraint, but by a design decision.

For perspective, here is some of the commit history of pain I've been dragged through to workaround it:

(partial) commit history related w/ Android Chrome

2013‑12‑10 - Android Chrome - normalised viewport scaling
2013‑12‑10 - Fixed width/height viewport for Android stock browser <=534.3
2014-12-08 - Support for Fullscreen API for Android Chrome

(partial) commit history related w/ iOS Safari

2013‑09‑19 - generalised iOS7 viewport fix for all iPhones ( 4 / 4s / 5 )
2014‑03‑05 - viewport handling for iOS 7.0
2014‑09‑30 - hotfix for iPhone 6+ viewport
2014‑10‑01 - viewport fix for iOS 8.1+
2015‑09‑03 - viewport fix for iOS 9
2015‑11‑09 - Viewport is broken when the game is opened in portrait on iPhone 6s+
2015‑11‑11 - Swipe up hack is not working on iPhone 6s+ in portrait
2016‑11‑14 - fix(rendering): Fix iOS rendering when disabling swipe fix
2017‑10‑13 - fix(virtualEvents): Hack to disable iOS 10+ zoom
2018‑08‑16 - fix(iphoneX): iphoneX barheigth fix
2019‑08‑22 - fix(iphone): viewport fix for iOS 13

Web notifications

Notifications - Web APIs | MDN

Here is another 5+ years old API that never reached iOS Safari. It allows web apps to send users notifications, like "Native" apps.

The only alternative is to build your own "Native" app and deliver it through the App Store.

Add to home screen

Mobile browsers have for long allowed web apps to be added to homescreen as bookmarks with a chain of manual steps. But it is just such a buried option in the browser that no one actually used it.

Now it has become a standard option for web apps.

"Add to home screen" (or a2hs for short) is a feature implemented by mobile browsers that takes the information found in an app's web manifest and uses them to represent the app on the device's home screen with an icon and name.

This key element is part of a collection of web technologies called progressive web apps (PWAs), which are websites that can be installed to a device’s homescreen like a "Native" app, from a user's perspective. And this can now be done directly from the web.

Unlike regular web apps with simple homescreen links or bookmarks, PWAs can be downloaded in advance and can work offline, as well as use regular Web APIs.
Progressive Web Apps | MDN

This has not been added to iOS Safari up to now (iOS 13, 2019).

tl;dr

Web standards have bridged the gap with "Native" mobile apps enough that today, for most mobile apps, the only reason to prefer some form of "Native" entanglement is really due to the App and Play Stores channels for delivery and profitability. You just have to be in the app stores.

Much like Microsoft tried to lock their user base to Internet Explorer Web APIs in the past, Apple today seems to be forcefully ridging the perception of web platform vs app store apps in iOS. It is doing so by not implementing web platform enhancements that are key to bringing web apps to be enabled and used as first class citizens (like "Native" apps) by the user.

I'm not even original in this comparison, others have been noticing it too for a variety of reasons:

safari-is-the-new-ie.com

Safari is the New Internet Explorer

Meghan (she/her) ・ Jan 14 '18

#javascript #safari #webdev #productivity

Rephrasing Steve Jobs on Thoughts on flash:

New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too).

Perhaps Apple should focus more on creating great HTML5 tools for the future, and less on blocking out the web platform from being a first class citizen on mobile.