HTML is the “reader” of the Web.

IPFS/IPLD data reading is, in many ways, stuck in the past. Inspiration is often taken from “backend” systems like traditional databases and server interfaces.

IPFS for HTML 2.0

First, let’s leave the “write the HTML file into IPFS” story aside. We’re not going to break it, but it’s not relevant.

What we’re building towards are applications that put the data into IPFS. Not the view (HTML page) but the data necessary to build that page.

What we need to figure out is how all the IPFS data can be retrieved for a page to render.

If you look at what has been happening for years in Web Frameworks, you’ll see a lot of work being put into “server side rendering.” But the term is a little miss-leading, SSR not only allows the server to render, it forces the framework into a pattern where the entire render pipeline has to be defined in terms of initial and dynamic loading, with each dynamic component potentially being included in a static render.

The Web is a Graph, and so is HTML

The Web has always been a graph because of the nature of URL linking.

Modern web frameworks have taken this a step further, allowing components to be re-used throughout applications and pages. This effectively turns the entire view layer into a graph.

If you look at how these frameworks have accomplished this, it doesn’t speak well to the way we’ve traditionally approached query interfaces.

Each component is able to query for data however it wants. The framework doesn’t enforce a specific database or query language, but i does standardize the calls to render the page and force the reading of any necessary data.