1 of 21

Layered APIs

by @domenic / at BlinkOn 9

https://bit.ly/blinkon9-lapis

2 of 21

What are layered APIs?

https://bit.ly/blinkon9-lapis

3 of 21

Layered APIs overview

  • A new standards effort for adding high-level APIs in a sustainable way
  • Per-page opt-in via importing a module
  • Built-in fallback to polyfills
  • Always layered on top of existing platform primitives

�Explainer: https://github.com/drufball/layered-apis�Blink design doc: https://bit.ly/lapis-design

https://bit.ly/blinkon9-lapis

4 of 21

Why high-level features?

  • This is the second half of the extensible web manifesto
  • Web apps are too big: let's make more possible with less code
  • With only low-level primitives, the web unergonomic and hard to do right

Let's give the web a "standard library" comparable to other platforms.

https://bit.ly/blinkon9-lapis

5 of 21

Example potential LAPIs

  • Async local storage
  • WebSocket stream interface
  • Shadow-piercing querySelector
  • Run this function in another thread
  • Better date/time library
  • Custom element-building helpers
  • Better drag-and-drop API
  • Adaptive video-streaming player
  • Infinite/virtual list
  • Carousel
  • Accordion
  • Tabbed UI
  • Sortable table
  • Masked <input>
  • Automatic morphing transitions
  • Navigation drawer

https://bit.ly/blinkon9-lapis

6 of 21

Using LAPIs

<script type="module"� src="std:virtual-list|https://some.cdn.com/virtual-list.js">�</script>��<infinite-list>...</infinite-list>

https://bit.ly/blinkon9-lapis

7 of 21

Using LAPIs

<script type="module">�import { storage } from� "std:async-local-storage|https://other.cdn.com/als.mjs";��storage.get("key").then(...);�</script>

​

https://bit.ly/blinkon9-lapis

8 of 21

Implementation

In Blink, we plan to implement LAPIs in JavaScript.

  • Enforces layering
  • Allows code reuse with other engines if they desire
  • Automatically pay-when-imported, instead of pay-per-context

https://bit.ly/blinkon9-lapis

9 of 21

LAPI status update

https://bit.ly/blinkon9-lapis

10 of 21

The project has solidified

  • Formerly known as: permafills (misleading), LWAPIs (unpronounceable)
  • Explainer re-focused to emphasize that this is a new standards effort
    • Implemented in JavaScript / possibility for code sharing is just a Blink implementation detail, not an inherent part of the technology
  • Polyfill fallback syntax tentatively settled, pending more feedback on the prototype

https://bit.ly/blinkon9-lapis

11 of 21

LAPI projects in-flight

  • LAPI loading infrastructure
  • Async local storage
  • Virtual list
  • Mystery third LAPI

https://bit.ly/blinkon9-lapis

12 of 21

LAPI loading infrastructure

Settled on std:x|y module specifier syntax for now, after much deliberation. Now hiroshige@ is prototyping it so we can get feedback!

  • Spec
  • Design doc
  • CL

https://bit.ly/blinkon9-lapis

13 of 21

Async local storage

Like localStorage, but async!

  • On top of IndexedDB
  • Spec: a proving ground for what a LAPI spec looks like
    • Highlighted some general missing LAPI primitives (see later slides)
  • Have been gathering web developer and other-implementer feedback
  • Next up: implementation behind a flag (this quarter)
    • And, of course, web-platform-tests!

https://bit.ly/blinkon9-lapis

14 of 21

Virtual list (aka "infinite list")

  • Infinite list study group studied 4 implementations and distilled common patterns and requirements
  • valdrin@ is prototyping a <virtual-list> element
    • Very small public API for now, for simplicity
    • May expose the composable pieces used to build this later
    • Some fun demos (some require Canary)
  • Potentially missing primitives: find-in-page, indexability, in-page anchors, ...

Goal for this quarter: comprehensive public explainer + standards outreach

https://bit.ly/blinkon9-lapis

15 of 21

Mystery third LAPI

More LAPIs out of the gate for a stronger offering

  • Probably want to do something with UI to push ourselves a bit
  • Perhaps a popular control like tab panel, accordion, or carousel?

Suggestions welcome!

https://bit.ly/blinkon9-lapis

16 of 21

Open questions and issues

https://bit.ly/blinkon9-lapis

17 of 21

fn.toString()

  • You can read the implementation details of any web-dev-implemented function/class/etc. using fn.toString()
  • LAPIs are not supposed to use any magic inaccessible to web devs
  • Solution: allow web devs to censor fn.toString() too!

TC39 proposal

https://bit.ly/blinkon9-lapis

18 of 21

Original built-ins

  • Browser-level features should not be disturbed by modifications to the built-ins
    • E.g., window.indexedDB = null should not break async local storage
  • When writing C++, we automatically access the "original" versions of everything. Web devs can't do that.
  • Solution: give web devs a way to access the originals?
    • Not super-ergonomic, but it does the job
    • Need to discuss feasibility with V8 and bindings folks

https://bit.ly/blinkon9-lapis

19 of 21

Fallback syntax

For now, we're settled on std:x|y

  • Let's get a prototype out and see what web devs and other browsers think
  • Potential concerns:
    • Only provides fallback for browsers implementing LAPI infrastructure
    • Can result in different fallbacks throughout the app
    • Really long to type ;)
  • Package name maps are an interesting alternative

https://bit.ly/blinkon9-lapis

20 of 21

What other LAPIs should we prioritize?

We have a rough backlog of ideas. What's important?

  • Ask web developers
  • Survey popular, settled patterns in library-space
  • Ask other vendors

Does your team work on some low-level capability, that could benefit from a high-level wrapper LAPI?

https://bit.ly/blinkon9-lapis

21 of 21

Thanks!

https://bit.ly/blinkon9-lapis