shuppy (shuppy.org) — 2025-06-02T10:24:13.053Z

wintertc: standards for server-side js runtimes

what is ~~wintercg~~ wintertc?

finding a standards body

W3C community groups can’t publish specs, so we need to find a standards body proper
invited experts are important because you don’t want to limit collaboration to dues-paying companies
ECMA TC55

current work

building a wintertc test suite, subset of wpt
- sometimes need to modify tests to be compatible with the minimum common api
- want to work upstream. how do we do this without forking the whole wpt suite?
decoupling upstream specs from the web platform where possible (e.g. fetch)
- fetch has a lot of web-specific concerns that don’t apply on server-side
- there is no current page, cookie jar, cross-site security, atomic redirect handling
- need to add cookies to the client-facing API, because there’s no cookie jar
- want to add control over protocol (h1/h2/h3), mTLS, http proxies, CA certificates, etc
- want to work upstream. how do we do this without forking the whole fetch spec?
adding functionality (e.g. streaming data in web crypto)

minimum common api

subset of [Exposed=*], which is in turn the subset allowed in any shadow realm
typically includes compute-only APIs and generally useful things like async I/O
what can wpt authors do to ensure they adhere to the minimum common api?
- try to write your tests as .any.js, not as .html
- currently you can check if you are server-side-compatible by landing your tests and checking wpt.fyi
- they are working on ways to make this easier, such as running wpt tests locally in deno
what about the dom? wouldn’t it be useful to manipulate dom trees server-side?
- this is complicated, because it’s tangled up in things like html parsing

additional conformance levels

useful for optional feature sets that we don’t want to mandate across all runtimes
for example, a graphics feature set would have WebGPU, OffscreenCanvas, etc

join the meetings!