Get Low-Level

Understanding Browsers, Specs
& Standards Bodies

On the whiteboard:

list all libraries & frameworks you've used

  • look through the lesson plans listed on the frontend site
  • look through your `package.json` files in projects you've built

Learning 100 different libraries is still easier
than building an application with none.

Identifying the Layers

Layer #3 - The Library

  • previously used Dexie - library wrapping IndexedDB
  • code was concise and read similar to English

On Your Own:

look through the Dexie source code
and find the following implementations:

  • `put`
  • `get`
  • `delete`

Layer #2 - The Web API

  • Downsides of IndexedDB: "The API is brutal".
  • code is verbose and difficult to read

But y tho?

  • Web APIs need to be flexible to handle many scenarios
  • This means they have to be as bare-bones as possible

Layer #1 - The Browser

  • browsers are made up of many different parts
  • working with APIs is dependent on the built-in JavaScript Engine and Browser Engine

Browser Architecture

Layer #1a - The Browser Engine

The browser engine is responsible for implementing Web APIs and functionality like IndexedDB, geolocation, web audio, etc.

  • Chrome - Webkit (C++)
  • Firefox - Gecko (C++)

Check the source

  • which modules sound familiar to you?
  • bump up a directory and explore the rest of /WebCore/
  • what other APIs live in the browser engine?

Layer #0a - The Web API Specification

The specification for a Web API gives platform engineers a strict set of rules for how the API should behave, which guides how it is implemented in the browser

  • spec writers agree on functional behavior
  • platform engineers implement the API in the browser
  • app developers build applications using the API

IndexedDB Spec

Specs are notoriously difficult for app developers to read because they are written for platform engineers who write C++

Reverse!

Let's walk through a single point of IndexedDB functionality from the bottom up.

Opening a Database:

Standards Bodies

Standards bodies facilitate creating technical documents that define how proposed web functionality should be implemented.

  • W3C - World Wide Web Consortium
  • WHATWG - Web Hypertext Application Technology Working Group

Why Standards?

  • promote a more stable and consistent web
  • follow patterns that make implementation and maintenance easier
  • are developed with all demographics in mind
  • make it easier to share common knowledge and learn from each other

Standardization Process

  • "Working Groups" (clubs of old white men) are formed and discuss new ideas for Web APIs
  • "Working Draft" (WD) - document to be reviewed by the community
  • "Candidate Recommendation" (CD) - released for implementation experience
  • "Proposed Recommendation" (PD) - technical report sent to advisory board
  • "W3C Recommendation" (REC) - technical report endorsed by W3C members/directors

Web Incubator Community Group (WICG)

WICG is a Community Group where people discuss changes to pre-existing APIs and pitch potential new ones. Some of the discussions include:

Layer #1b - The JS Engine

The JavaScript Engine is responsible for interpreting the JavaScript we write and doing something meaningful with it.

  • Chrome - V8 (C++)
  • Firefox - Spidermonkey (C/C++)

Check the source

  • which file names sound familiar to you?
  • bump up a directory and explore the rest of /src/
  • what other functionaliy lives in the JS engine?

Array Methods in V8

Layer #0b - The ECMAScript Spec

The ECMAScript spec defines the entire JavaScript language, and is very scary.