-
Notifications
You must be signed in to change notification settings - Fork 6
2024 WinterCG
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/29
Dan: Also trying to find use cases that are different between browsers and servers for the same API. What would be people interested in chatting about?
Andreu: One thing that came up is to what extent should WinterCG define APIs other than those coming from the web, such as CLIs. Also, there was some discussion about whether in an ideal world when we have some fully flashed out APIs, should runtimes be able to have their own runtime-specifc APIs.
Dan: WinterCG is focusing first on the common minimum API, and extensions are something that we are just starting to think about.
Andreu: Web Crypto Streams is interesting because it's an extension of a web API.
Dan: The idea is to upstream it to the Web Crypto spec.
Andreu: In this case, server side runtimes have much more interest than browsers in it. We benefit from designing it as a group.
Dan: To go in more deail in the common minimum API, right now we are quite informal and just list APIs. Window ⊃ Common Minimum API ⊃ ShadowRealm.
Dan: We try to watch as many standards as possible, how should we work together on it?
Dominic: What is the working mode? How do we interact with each other? Is there a repository that WhatWG should open an issue in asking for a standard position? Or should we just join the right meeting?
Dan: We haven't worked on a process for that at all, we don't even have a repo.
Andreu: For simple things an issue is enough -- for something more complicated maybe join the matrix room.
Dominic: Are there regular meetings?
Andreu: Yes, monthly.
Dan: So, open an issue in the common minimum API repo, join the matrix room, and/or join the meetings. Maybe we should provide another place to give feedback.
Dan: We are also working with Node.js to have Node standard positions on issues, but Node.js is not involved as a project in WinterCG (only Node.js individuals are).
Ujjwal: When you talked about WinterCG following different standard processes, I was curious about... all of these standards can be important for WinterCG - do you have a process for having some kind of engagement with different standard bodies, and is there a WinterCG standard position?
Dan: That is what we were talking about WinterCG before. File an issue in the common minimum API repo.
Andreu: With the work I'm doing on AsyncContext, I'm often looking at how web APIs should integrate with it. For WinterCG, that will be automatically be taken care of if the Web side will take care of it. However, since runtime-specific APIs are not going away, should we have a similar document/guideline for runtimes with their own project-specific APIs?
Dan: What's the question?
Andreu: Thinking out aloud.
Dan: For context, AsyncContext is about adding dynamically scoped variables to JS. It's like thread-local variables but for async functions. You want to be able to save and restore the thread-local variables when you do an await. It's similar to Node.js' AsyncLocalStorage (which has nothing to do with Local Storage). You create a variable, call .run(), and it sets a variable to a value for a particular function. When callbacks are scheduled, for example by setTimeout, the value is restored. It captures the snapshot when calling setTimeout.
Andreu: The point is that we are making sure it works for await, but it should also work for any API that schedules a task. And runtimes can have their own ways of doing so.
Dan: To clarify, current focus is on web API. That is a possible extension for that work.
Andreu: And WinterCG could be the place where that happens.
Dan: Can we talk about how WinterCG can work better with folks working on the web platform?
[CanadaHonk shows compat table for server-side runtimes for common minimum API - https://runtime-compat.unjs.io]
Dan: Would it be welcome for wpt to refactor some tests to be less web-specific?
Luca: We have been doing so for the past two years. It's being going good. A lot of older tests are still written in HTML, which is more difficult to run for us. We have been converting them to .js, and it also benefits browsers that can now run them in workers.
Dan: This table is excellent, it shows that for every row that are different envs that fail the tests.
CanadaHonk: It doesn't actually use wpt, it's MDN data.
Dan: Can we make a runner for wpt?
Nicolò: Doesn't wpt suppot server-side runtimes? Node.js results are there.
Luca: Node.js and Deno have their own runners, and we upload the results to https://wpt.fyi.
[Luca shows wpt.fyi]
Andreu: What's interesting about it is that a lot of WPT tests are in HTML, and last time I checked Deno parses the HTML?
Luca: WPT has been evolving for a long time. A lot of files have these meta comments at the top that describe some info about the test. The wpt runner takes these input files, and generates HTML files. So we parse that HTML and grab the script tags that we need. We could re-parse those files and handle the meta comments -- we did that but wasn't working too well.
Luca: To test authors, please write them in JS!
Andreu: Should WPT run on a runner for server-side runtimes?
Dan: WPT is just an open source projects, so it should be us in WinterCG contributing that.
Ujjwal: Luca, you mentioned the idea of having more JS-based tests. From ??? two days ago we heard the opposite, that a rendered would need WPT to not reqire JS.
Luca: That's not for JS APIs, so obviously something you need HTML for and that we won't ever need to run.
Ujjwal: Should then WPT into two?
Luca: It's already split in 200 -- all these folders are written differently.
Dan: Maybe you are thinking about tests lice ecma402, but it's not the case here.
Ms2ger: I'm a little disappointed to hear that working diretly with .any.js files didn't work for you, I'd be interested in talking on Matrix about it to make sure you don't have to go through HTML. We are already encouraging people to use .js tests. We'd be happy to accept contributions to make easier for you to use WPT. The existing test runner is already preatty complex with many ways to run tests, so I hope we could fit it somehow.
Luca: We tried integrating in the WPT harness 2 years ago, but run into difficulties with something and couldn't figure out how to get help. I'll reach out to you.
Dan: Joyee, feedback from Node.js?
Joyee: It'd be helpful to have some kind of common test runner for JS runtimes. Currently Node.js's runner is not very capable, like you cannot specify conditions like "skip this test on platform X" -- you have to re-implement all of that.
Dan: I want to contraddict what I said before to Ujjwal -- URL also il like this, when some tests are just about parsing URLs and others are about how it works in the browser.
Luca: They are already extracted, for example rust-url uses them.
Luca: deno has a runenr that can filter, but it uses Deno-specific API. We should work together on integrating this in wpt.py. A complication Deno has is that we don't support running scripts, so we have some secret flags for WPT.
Andreu: I remeber the problems with classic workers in Deno.
Joyee: Do you run tests in their own context?
Luca: One process per test.
Joyee: I think Node.js does one worker per test. We could abstract that, and runtimes implement adapters. The harness already does that, but only for browsers.
Luca: Yes, we had to upsteam some changes to the test runner that has some expectations about the environment that you probably also benefited from.
Joyee: We patch a bunch of stuff to make Node.js look like a browser. Or we need to detect errors.
Andreu: Would it make sense to use a WinterCG environment?
Ms2ger: I added this to run tests directly in the SM JS shell without any editing on top of that. It would probably be better to do something inspired by that.
Luca: We tried to use that at some point and was not what we needed. There are some potability problems about onerror and uncaught rejections. We should write down a list.
Andreu: If Node.js and Deno already patch the global...
Luca: We don't.
Joyee: Only we do.
Andreu: but maybe run a script before the harness that sets the necessary flags?
Dan: I'm happy to hear intesest from WPT upstream to work together.
Dan: I wonder if there's more we could discuss here wrt interaction b/w WinterCG and folks working on new features on the web platform side of things. Should we now talk about interactions for standards? Luca, you worked on Response.json.
Luca: There are two classes of things here: things that have shipped purely due to the needs of server-side runtimes and then there's stuff where we've influenced the design of things. In the case of response.json static method that allows you to create a response in a simple way. Many runtimes are used for building web servers although
Less of a feature and more like feedback from runtimes, when Chrome wanted to ship Request bytes streaming and fetch, they were going to do a half duplex stream since that's what they support but Deno supports full duplex streaming. This meant either Deno was incompatible with browsers or... well, that's it. What we ended up doing was to add a property to control the behavior. This allows us to keep compatibility and also hopefully deal with the case of browsers adopting full duplex streaming eventually.
Dan: appreciate WHATWG here. Browser vendors still cover most of the cost but I appreciate the contribution by server runtimes here.
Luca: shout out to Anne for being super supportive in WHATWG.
CanadaHonk: nice to see implementation bugs in both browser and server runtimes.
Dan: we're proposing WinterTC as an ECMA TC so that it could publish standards. This would be both for the common minimum API.
Dan: For fetch changes, should we upstream them or publish a fork? It sounded like we could upstream them if we can show capacity to maintain them upstream.
CanadaHonk: Why in Ecma and not W3C?
Dan: They are all possible places...
Ujjwal: Thanks for raising this, I wanted to ask -- the way you put it it's clear that WinterCG getting a TC in Ecma is to beenfit everyone. It's udnerstandable that you want to publish specs, and it also brings new work to Ecma. How is somebody that might work for Ecma members and is interested in WinterCG, how do we communicate this importance to Ecma?
Dan[answering to CanadaHonk]: The reason we are doing with Ecma is that W3C's process is much more complex. And some people want W3C to only focus on browsers. Also, it relates closely to the work of TC39. Technical work continues in WinterCG, and Ecma TC55 would just validate the spec and do the formal standardization. What I imagine happening is that there are annual versions where we say "X is WinterCG-2025 compliant", meaning that it implements a given snapshot. So we have concrete targets.
CanadaHonk: We should make sure that people cannot say they are compliant why they are not.
Dan: That's exactly why I wanted to do it.
Michael: Upstream we don't version specs, so I fear that trying to release snapshots would be problemating.
Luca: Fetch and HTML have snapshots every 6 months.
Dan: We should indicate which set of the web is included, but given that the web evolves in backwards-compat ways it's stable enough.
Andreu: It's like baseline.
Dan: It's different, because it's also a target.
CanadaHonk: Testing make sense -- ECMAScript shows that yearly versions work.
Dan: Right -- ECMAScript is in practice unversioned, but the community really wants to see the annual versions.
CanadaHonk: We also have test262.fyi
Dan: These days, is eshost accurate? In the past, when the engines used their own runenrs they got better results.
CanadaHonk: It's within 1% of error.
Philip: It sounds like you made a bunch of improements -- is anybody in contact with Brian to take over maintainenship of eshost? I also have improvements but couldn't upstream them.
CanadaHonk: No
Ujjwal: Based on what we heard, maybe at this point we should consider having a different upstream?
CanadaHonk: We could make a wpt runner using eshost, so it could be adopted in wintercg or something.
Andreu: Should we have ecma maintain it?
Nicolò: Just keep it in a personal repo?
Dan: Changing topic, can we go to AsyncContext? The biggest issue is fiuring out the context for the callbacks.
Andreu: The idea is that setTimeout would have to resume the context when running the callback. For setTimeout it's easy, because at the same time it is called and schedules the callback. Also other schedulers, or completion callbacks like .then. The big question is for things like events: is the context when you register it, or when the callback is scheduled? A lot of the time the event is dispatched synchronously, like if you call .click() on an element or change location.hash. However, you wouldn't want usually a difference between calling a .click() method and users clicking on a button. So maybe, the context should be always empty for user-generated events, or maybe it should always be the regsitration time.
Dan: For context, you might use this for performance tracking. So you might store an AsyncContext variable when some task/action logically starts, and you want to keep that variable around to see how long something takes.
Andreu: Or for example store an ID for the current action, and you cannot use a global because two async concurrent operations would overwrite eachother.
Andreu: The default cannot cover every possible use case.
Dan: Zone.js implementing this by patching the whole world, but we don't want that to be necessary. So we should figure out a good default that can be overwritten.
Andreu: The originating context has to be exposed somehow.
Dan: One example of use case for the originating context is that for the unhandledrejection event you want to know where the error came from, rather than when the callback was registered.
Dan: It would be great to hear from people who work in specs how to handle mainteinance, how to we make sure future specs to the right thing.
Andreu: For async events the registration context is handled automatically, but the originating context is not. Sometimes maybe it could be handled with promises.
Dan: One minute left -- thoughts?