Add initial drafts of high-level design docs #1
Conversation
lukewagner
force-pushed
the
initial-contents
branch
from
85807f2 to
70465d8
Compare
| * *Web platform integration*: ensure components can be natively supported | ||
| in browsers by extending the existing WebAssembly integration points: the | ||
| [JS API], [Web API] and [ESM-integration]. Before native support is | ||
| implemented, ensure components can be polyfilled in browsers via | ||
| Ahead-of-Time compilation to currently-supported browser functionality. |
There was a problem hiding this comment.
It has been mentioned insistently during foregoing discussions that JS needs a separate JS-API mechanism due to its inherent semantic mismatch and is not covered by Interface Types. Is this still the plan, say will there be another layered proposal under the Component Model umbrella to guarantee that integration with JS and between JS-like languages is reliable, or what's suddenly going on here?
There was a problem hiding this comment.
As already described in the interface types explainer, the idea is to extend the existing JS API spec in-place to map to and from JS values and the interface types defined by the component model.
There was a problem hiding this comment.
The interface types explainer is horribly outdated, as you said yourself. It does not mirror anything discussed recently, and now conveniently saying that it would while skipping over all the contrary claims made to win the polls is dishonest.
|
@dcodeIO if you want to claim that the current design doesn't meet the design goals (or suggest different design goals), then you can do that. I agree that the interface types explainer could use an update to cover new developments (and it seems fine to ask about what has changed). But these attacks are not acceptable (and in any case are only going to make it harder/impossible to actually engage productively). |
|
Alright, well that's enough time for initial feedback. As always with these types of initial PRs, we can iterate on these documents by filing issues and PRs. |
Following the proposed next steps for the component model, the
component-modelrepo has (finally) been created and this PR adds docs containing the high-level goals, use cases, and design choices that were presented in the April 27th presentation. In the meantime, we've gotten a bunch more feedback, so the docs reflect an improved understanding of the goals and use cases since April.The READMEs in this PR explain the repo structure and how the placeholder directories will be filled in by the
module-linkingandinterface-typesproposal repos (which I'll soon be rebasing onto this repo from the core spec repo, as previously presented).