Reading/Web/Projects/A frontend powered by Parsoid/Q2 MVP

Here is the outcome of the spike https://phabricator.wikimedia.org/T113769 for the Q2 MVP that we're building for a mobile web front-end that uses parsoid.

Main objectives of the MVP

 * Ease of development and prototyping
 * Speed
 * Improved reading experience

Ease of development and prototyping
In order to ease development (of UI/UX) and the creation of different prototypes for features or user research, it seems like the following properties are desirable (which we don't have right now):


 * Immediate feedback when developing UIs.
 * Improve iteration time.
 * Sharing of improved or experimental work.
 * Make state of UI reproducible to improve bug fixing and UI testing.

Solutions will come in the form of:


 * Live updating UI to multiple clients on development without blowing current UI state.
 * Live updating "development cards" containing the isolated UI pieces with their different states. (Like visual feature/UI tests).
 * Fast static server serving the front-end and client cache layer.
 * Serializable app state enabling playing and re-playing of user sessions/state.

In order to enable better prototyping and rapid iteration, the following properties would be desirable (which we don't have right now):


 * Ease of development previously outlined would help with this.
 * Ease of deploying+sharing prototypes|in-progress|experimental work.
 * For better/faster feedback from stakeholders.
 * For better user research.
 * Checking prototypes|in-progress|experimental work with REAL data.
 * For better/faster feedback from stakeholders.
 * For better user research.

Solutions will come in the form of:


 * Previously outlined solutions on the "Ease of development and prototyping".
 * API driven means REAL data available when needed.
 * Static bundle means deployable anywhere really easily. No need for a server in experimental / prototyping stages.

Speed
We're looking to prove that we can make the mobile web (and eventually all web experiences) dramatically faster. For mobile web there's a clear objective:


 * Speed up Barack Obama's first render by 3x or 4x for a 2G connection on India.
 * Which is more generally expressed as "Serve something useful RIGHT NOW and enhance the experience progressively as the network allows.
 * As a secondary objective, interacting with the page's chrome and navigation should feel instant once the page is already done, improving perceived speed by always showing the user what is happening and minimizing network payloads by changing to API only requests.

To accomplish such dramatic speed ups is why we'll decouple most UX with the essential page payload.

More will be outlined in the Architecture  of such MVP but as a general guideline:


 * Aggregated services will provide necessary data with minimal number of requests (for both server rendering and API responses).
 * Server will provide a minimal HTML with bare chrome and critical CSS, with a minimal version of the page's content (probably the stripped version of the lead section and table of contents).
 * When the JS bundle loads the client side will enhance the chrome of the web to become a web app, avoiding full roundtrips to the server and making the navigation happen in the client, and the access to the data via API or client caching.
 * The same code/UI that powers and renders the web app will provide the server rendering.
 * Alternatively the app could feed out of parsoid html or JS data structures on the html page (were the server not able to run JS).
 * Aggressive client side caching to minimize network roundtrips:
 * Client DB for storing fetched data. (IndexedDB|WebSql|localStorage)
 * Browser AppCache for JS/CSS/FONTS and main HTML.
 * Browser Service worker for caching HMTL pages, and JS/CSS/FONTS.