Intent to implement: Layered API infrastructure
Hiroshige Hayashizaki
Contact emails
hiro...@chromium.org, dk...@chromium.org, oj...@chromium.org, dom...@chromium.org
Explainer
Link to explainer
Design doc/Spec
Summary
Layered APIs (LAPIs) are a new standards effort for shipping high-level features, exposed to the web as JavaScript modules. Their specifications are required to be layered on top of existing lower-level platform features, and never use any "magic" that is inaccessible to JS developers.
This intent to implement is for the infrastructure to enable this in Blink. Specifically, the infrastructure will introduce std:x|y syntax, support for the import syntax for LAPIs, and serving LAPI scripts bundled with the browser. The syntax is:
<script type="module"
src="std:infinite-list|https://some.cdn.com/infinite-list.js">
</script>
or
<script type="module">
import "std:infinite-list|https://some.cdn.com/infinite-list.js";
</script>
Where std:infinite-list points to a browser-provided LAPI while https://some.cdn.com/infinite-list.js is a web-developer-provided fallback to network.
This proposal is in a very early stage. We’re just looking to prototype behind a flag as we continue discussion with the web community. Its likely that the syntax and design will change considerably.
Motivation
The Extensible Web Manifesto promotes a healthy, well-layered platform that encourages innovation and experimentation in JavaScript. But focusing on low-level primitives means that developers must build most application-level components on their own, creating a high barrier to entry for new web developers. This lack of built-in high-level features also bloats page load size. The average site payload is 2.5 MB and takes 19 seconds to load.
Historically, we have accepted this cost because shipping high-level features carries its own risks. Standardizing and building the right API becomes exponentially harder as the complexity of a feature increases. When we get something wrong with a high-level feature, developers are often left with no other way to achieve their goals.
Shipping features also incurs an ongoing maintenance and runtime cost - every new feature pollutes the browser namespace, increases JS startup costs, and represents a new surface to introduce bugs throughout the codebase.
We believe LAPIs is our best opportunity to reduce site payloads and provide a more expressive, ergonomic platform while mitigating the downsides of shipping high-level features.
Risks
Interoperability and Compatibility
Edge/Firefox/Safari:
Representatives from all three seemed moderately positive on the broad shape of the idea in informal discussions at TPAC. However, this is very early-stage and we don't want to overstate their support.
Web developers:
No feedback. Private, informal conversation with framework authors was received positively.
We are especially keen to get web developer feedback on the ergonomics of the LAPI infrastructure; see below.
Ergonomics
LAPIs are heavily integrated into JS modules; furthermore, we expect many LAPIs to use the web component APIs. Both of these technologies should be familiar to web developers.
If the number of LAPIs grows large, there is a potentially large number of imports/web component instantiations that Chrome needs to run. This is no different than a site that chooses to use a lot of web components today, but the fact that they are browser-bundled could increase the number used, or provide an expectation of performance. Fortunately, making JS imports and web components performant are existing ongoing projects.
We're especially interested in developer feedback on the ergonomics of importing a LAPI. Is the fallback-to-polyfill syntax OK? Is it OK that it only falls back to a polyfill in browsers that support LAPIs? Should we allow multiple fallback URLs? What about different imports specifying different fallbacks?
Activation
The LAPI infrastructure is specifically designed to improve the activation experience for features shipped as LAPIs. It provides an easy fallback to a polyfill for such features.
The LAPI infrastructure itself can be feature-detected, using old-fashioned polyfill loading in such cases.
Debuggability
LAPI infrastructure has similar debuggability to JS modules, and will be able to leverage much of the existing tooling there. Some open questions:
For cases where Blink implements the LAPI in JavaScript, should we allow debugging into Blink's LAPI source file?
Will LAPI fetches (for std: URLs) show up in the network tab?
Will we have a special notification that a fallback is being used, perhaps as a non-error console info log?
We plan to work out these sorts of issues by gathering feedback on the flagged implementation.
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
Yes.
Is this feature fully tested by web-platform-tests?
Yes; we have extensive tests under development in https://chromium-review.googlesource.com/c/chromium/src/+/1013322. They will be marked as tentative tests given the experimental nature of this feature.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/6555299569729536
Requesting approval to ship?
No.