- Date: Monday 11th December 2023 at 16:00 UTC
- Location: https://meet.jit.si/Servo-TSC
- Status update
- TSC elections
- Embedding API: status & plans
- How to make Servo more modular
- Quick intro to Web/Mini apps
- State of performance testing
- Tracking support of certain sites or framework
- Roadmap update
- Outreach
- AOB
Attending:
- TSC members: ajeffrey, atbrakhi, emilio, gterzian, Loirooriol, mrego, mrobinson
- Other: joshua-holmes, matlu, nicoburns, wusyong
Rego: Started work on CSS tables support, behind a runtime flag. Work on embedding API adding new features like multiple browser context, offscreen canvas and shared objects for mozjs and mozangle. Servo can now build with Rust stable versions. Stylo has been upgraded to June 2023.
Rego continues with chair role.
Martin takes over secretary role.
Rakhi: Update on the embedding API: Quite a bit of work going on. Yu Wei, Delan and Rakhi are working on this. PRs up handling offscreen rendering, multiple windows. Also working on having shared objects for larger C++ dependencies to make the build process easier for the Tauri team.
Yu Wei: Current API is pretty good and clear. It's also quite flexible. In that sense everything is here, but not in a hurry to advance more advanced features. Offscreen rendering and shared objects are more like good-to-have features.
Yu Wei: we would like to make servo a bit more modular -- which Greg will talk about today. This will make it more useful than electron & chromium. We can make something more modular and flexible.
Greg: Shares a presentation about making Servo more modular.
Greg: Integrating with SpiderMonkey
Greg: https://github.com/servo/project/files/13632608/Servo--modular.JS.engine.pdf
Greg: Places where we integrate:
- Rust bindings to SpiderMonkey (mozjs)
- Generated glue code for WebIDL: this creates the DOM all generated by Python.
- Utilities
- root.rs: rooting rust types into the garbage collector
- refcounted.rs: sharing pointers to rooted objects across threads. Mostly for callbacks across IPC.
- structuredclone.rs: Integration for safe passing structured data
- Misc
- BHM can interrupt running script
- Readable stream (currently implemented in SpiderMonkey)
- Microtasks, script runtime, window proxy
Greg: Use safe and unsafe APIs directly in script?
Greg: gives example of Blob refactor reducing dependence on SpiderMonkey
Greg: gives bad example of Readable stream, other potential candidates for this pattern.
martin: this looks pretty good to me, I love the idea of using more of the safe SpiderMonkey API; if we need to make a generic interface that seems fine and a good separation of the concerns; it allows to split out the script crates somehow; that would be great; how much of this is iterative and how much is big architectural changes; for the small things iterative I'm fine
emilio: at the high level seems fine, but a lot of DOM API are very tight to JS semantics
emilio: it seems it might introduce like a lot more complexity that it removes, depending on how the abstractions end up looking
gerg: a lot of stuff ends up in the global scope because you still have to link both things, a couple of things we tried on the past was to make it really simpler
greg: example there are three timelines in WebGPU: dom, engine, GPU,
greg: Not all of these timelines are accessible to JavaScript so you can split it out more easily. I agree that you should not make things super complex, but sometimes abstraction makes the system more simple.
rego: high-level comment. This year we managed to upgrade SpiderMonkey, but we haven't re-implemented streams in Rust. Is the goal to fix these kind of problems? What's the goal of this effort?
greg: Everyone who integrates with a JavaScript engine does it with V8. The goal is more to not depend on SpiderMonkey, because it isn't the choice that would've been made today. You separate yourself from other projects that would have used v8.
nico: I don't have a justification specifically, but I guess it would make sense if modularizing everything was a goal of the project. If it can be a kit to build a browser that seems like it's a bit contribution to the landscape of browsers.
greg: You were looking at layout, Nico?
nico: Yes, it depends on style, but the style crate has all the logic for selectors, passing styles, etc. Layout only needs to depend on the value objects.
emilio: If the idea is to get rid of SpiderMonkey...I don't have the technical competence to say if it's a good idea. They have very different memory models (GC) though. SpiderMonkey has a rooting GC and V8 is stack scanning. I feel a bit worried that looks like it abstracts away SpiderMonkey, but doesn't end up working for V8.
greg: Good idea to get rid of low hanging fruit like unsafe code.
greg: Removing SpiderMonkey would be further down the road.
emilio: In general, the more incremental steps you take the better.
greg: walks through document
greg: https://github.com/servo/project/files/13632609/Servo.mini-.and.web-app.pdf
nico: I feel like the people who want to embed servo want a bit more control. Maybe you just want web view, maybe you just use Chromium.
rego: We have talked about this in previous TSC calls. It would be cool to experiment with. They also need a host app -- not just a progressive web app. This seems aligned with finding usecases for Servo.
greg: I agree with nico that it doesn't solve the whole embedding story, but it's one way of doing standards stuff.
greg: Is there some performance testing happening now?
rego: From what I know, we haven't done anything related for performance recently. It's still a bit early in some sense.
greg: I recently opened an issue about xterm.js and the maintainer gave a list of the APIs that the software requires. I was wondering what the state of that is. Can we start doing that again?
rego: https://wpt.servo.org/
rego: We have been targeting some folders there and making progress. It would be nice to have some framework or site with fixes to focus on.
greg: We also have a Mozilla test folder.
martin: mozilla folder does exist, though nowadays is better to add tests directly to WPT than having downstream tests
rego: With the Tauri collaboration is that we will create some demo apps with Servo which will help us to identify some gaps and try to close them. Not sure with apps or frameworks yet, but aligned with that idea.
rego: https://github.com/servo/servo/wiki/Roadmap
rego: Will accept questions or comment or we can continue the conversation on Zulip.
rego: Rakhi had a talk accepted at FOSDEM. Will present a talk in the Rust room.
Yu Wei: A possibility for the roadmap would be to make the script crate more maintainable. 99% of the compilation problems are with SpiderMonkey.
Yu Wei: I think Rakhi is working on making SpiderMonkey use a shared object. I think that the v8 crates does this.
rego: We also chatted about having a shared object for Servo itself.
rego: Thanks.