What would be a meaningful niche for Servo?

[sandstrom]

For Servo to live on after Mozilla cut the ties, I think it would be helpful to find a small niche where it is unique and useful. Basically, being a "general web rendering engine" is probably to wide a scope right now, given the amount of open-source effort that's being put into it.

Take embedding as an example. If Servo became a great choice for embedding (similar to WebViews, Electron or maybe as an "engine" to Electron), where there is usually a single set of CSS and Javascript that it's expected to run (basically a bundled app), the downsides of Servo not supporting all Web APIs, or not handling all edge cases, is reduced. Basically, if it runs your code, that's enough.

So it'll become "useful" (regardless of where you put the bar for useful) earlier in an embedding context, compared to it becoming useful as a general browser.

Should it catch on as a tool for embedding, that would drive more usage and more contributions, which would be a beneficial circle.

But this niche could also be something entirely different, of course, I'm not sure embedding is the "right" one.

Let me know your thoughts on this, and feel free to add your own ideas (mark them up with Idea in bold at the top of the post, to separate them from other discussion points).

(there is also some discussion in this HackerNews thread, with more thoughts https://news.ycombinator.com/item?id=27700836)

cc @okias @bjorn3 @yvt @jdm @lrazovic @sagudev @emilio @SimonSapin @heycam

[sandstrom]

Idea

A secure/sandboxed rendering engine inside (or along-side) Lucet and/or Wasmtime. For example, if you wanted to quickly rasterize/render a PDF or web-page with lucet/wasmtime, maybe Servo could be used for that?

Vote up (using the arrow left of this box) if you think this would be a useful niche for Servo.

[sandstrom]

Idea

As an embedding engine for Electron (the idea mentioned as an example at the top).

Vote up (using the arrow left of this box) if you think this would be a useful niche for Servo.

[sandstrom]

Idea

As a GUI or web engine for deno.

If you go read in e.g. denoland/deno#3234 there are many people suggesting Deno and Servo could be used together. However, there are also mentions of servo not supporting enough of e.g. CSS to make it useful. I'm not in a position to judge how much work that is, or what other obstacles there would be.

If people on the servo team things this is a worthwhile path, it would probably make sense to discuss with people on the Deno core team to get their view, and maybe here what obstacles they see to start using Servo.

Vote up (using the arrow left of this box) if you think this would be a useful niche for Servo.

[SimonMeskens]

This would be amazing

[sagudev]

Deno uses v8 and servo uses SpiderMonkey, so that would be another problem in this way.

[bjorn3]

While the script crate which implements the actual web api's depends on SpiderMonkey, most of the rendering related code is engine agnostic and may even be used outside of javascript AFAIK. Deno already has support for many javascript api's that the script crate implements too. Writing glue code for deno that uses the rendering related code is probably non-trivial, but still likely much easier than starting from scratch.

[SimonSapin]

The script crate is Servo’s biggest by far. Replacing it with something not tied to SpiderMonkey would involve rewriting bindings − and in some cases implementation − for many APIs like the DOM, canvas, WebGL, WebAudio, etc. components/script/dom/webidls/ has 13k lines in 445 files.

Deno already has support for many javascript api's

Those may not be what you want though. For example deno-canvas is apparently a thing that exists but it renders to an in-memory pixel buffer that won’t be part of a web page rendered by Servo.

[SimonSapin]

I think the whole premise of this question is flawed. Let’s say we do find a niche where Servo would really be awesome, then what? Who will do the work to make it happen? Unpaid volunteer contributions and donations from individuals cannot sustain a project of this scale, and being useful does not by itself bring funding.

[sagudev]

What is the current plan for servo? How it will become something? How it will get funding?

[SimonSapin]

If you know anyone who can answer this let us know!

[sandstrom]

You have a good point, I mostly agree. It is indeed difficult to sustain a large project like this without funding.

I guess it could work if success in that niche would bring funding somehow. But yeah, that's probably an important thing to consider for any "niche idea" – would success in this niche bring money and if so how?

For example, a GUI for Electron, that may bring funding (paid work) from Slack, Github/Microsoft, etc. Much work on Lucet is sponsored by Fastly. And so on. (these are just examples though, I'm not sure what's written in this last paragraph would turn out to be true)

[okias]

I guess investor would be wondering, what can Servo do better than Chrome and Firefox and that's hard to find, but has to be done before asking for the money.

[coffeenotfound]

A fast, secure and modern, embeddable (!) web engine seems to be more than a small niche...

[harryfei]

I'd like to embedd servo into emacs-ng/emacs-ng#394 (comment)

[timClicks]

I think the only viable option is a new layout engine

This is probably true and also a tremendous amount of work 😓. Who has the skills and time to take something like that on?

[SimonSapin]

Re "having the time": this not the scale of project that can be done as a hobby. So a better question is who has interest and budget to hire a time of people who have (or can learn) the skills.

[okias]

Re "having the time": this not the scale of project that can be done as a hobby. So a better question is who has interest and budget to hire a time of people who have (or can learn) the skills.

I believe that's the most critical issue of all engines (Gecko, Blink, Webkit, Servo). Maybe Servo could be the one engine which make each component more standalone and maintainable by small amount of people? Is that reachable goal or completely no-go with-in scope of Servo?

Theoretically could be more realistic to have few people working on each separate part of Servo than having people having volunteers with "the whole insight"?

[SimonSapin]

From the start Servo has steered away from a monolithic design and has many crates developed semi-independently with a well-defined API. For example see url, cssparser, and html5ever crates. But that only goes so far. CSS layout alone (input: a DOM tree with a computed value for every CSS property for every element, output: the position and size of everything) is huge (see #28582 (reply in thread) above) and cannot really be split into independent parts.

[DemiMarie]

I think embedding is the best niche. To me, embeddability doesn’t just mean having an API for embedding. It also means modest memory and CPU requirements, a stable C API and ABI to allow Servo to be updated independently of its users, taking a reasonable amount of time to compile, easy cross-compilation, and easy packaging. It also means support for embedded systems.