Rewrite with a stronger dependency on package name maps #33
Conversation
This incorporates some of the ideas touched on in the issue tracker, mostly around using package name maps to provide a better fallback story and web developer control. It touches on the following issues: * Fixes #10, fixes #14, fixes #15, and fixes #24 by moving away from std:x|y and its attendant problems. * Opens the door to solutions for #5 based on the speculative package name map fallback ideas. It also adds a bit more motivation to the intro, and rearranges to emphasize the standards process, before diving into many details on the importing infrastructure. For now we delete the "Trying these ideas out" section, and spec.md, as they are all about the old infrastructure.
|
|
||
| We propose a renewed focus in the web-standards space on higher-level APIs. In particular, we'd propose a marketing-brand of "layered APIs" for high-level API standardization efforts which follow these two constraints: | ||
|
|
||
| - **Layered**: Their specifications _must not_ use any "magic" that is inaccessible to web developers, i.e. they must be layered on top of the platform's existing lower-level features. A concrete way of stating this is that a web developer must be able to implement a given layered API's specification, purely in unprivileged JavaScript. |
There was a problem hiding this comment.
does this include implementing an API in an engine that does not yet support it, at the relevant URL (not just a bare package name alias)?
There was a problem hiding this comment.
No; layered APIs are implemented by engines that support them.
(Note, this sentence was preexisting, just moved around.)
There was a problem hiding this comment.
what's the value in ensuring that layered APIs can be implemented in JS, when it'd be impossible to transparently provide a missing layered API using JS? (iow, when in practice would anyone ever actually implement a layered API in JS, except to polyfill it?)
There was a problem hiding this comment.
The benefits of layering on top of primitives are explained elsewhere in the README (both the current one in the repo and the one in this PR).
Perhaps this would be less confusing if we removed the last sentence, since it's just an operationalization of the layering requirement.
domenic
added
fallback syntax
This incorporates some of the ideas touched on in the issue tracker, mostly around using package name maps to provide a better fallback story and web developer control. It touches on the following issues:
It also adds a bit more motivation to the intro, and rearranges to emphasize the standards process, before diving into many details on the importing infrastructure.
For now we delete the "Trying these ideas out" section, and spec.md, as they are all about the old infrastructure.
Review much appreciated. I'd suggest just re-reading the entire doc using the rendered view on GitHub.
The
layeredapi:URL scheme is an interesting aspect here. I'd like to get folks' reactions to it, especially if they are negative. In a package name map based system, it is most natural to have a package -> URL mapping, and so we need some URL system to exist to map to. We could re-conceptualize how package name maps work, or add special exceptions for built-in packages/LAPIs, maybe. But this makes the most sense to me. Still, I'm wary of the extra complexity it adds.