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:
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
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++)
- 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
Specs are notoriously difficult for app developers to read because they are written for platform engineers who write C++
Let's walk through a single point of IndexedDB functionality from the bottom up.
Opening a Database:
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
- 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
- "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
- Chrome - V8 (C++)
- Firefox - Spidermonkey (C/C++)
- 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?
Layer #0b - The ECMAScript Spec