[simias]

What's the plan exactly? Will there be a Servo browser that integrates the servo rendering engine with some open source components (for instance from Firefox, WebKit or Chromium) that will let us use the engine stand-alone, or is it "just" going to be an engine for embedding in third-party programs?

The former seems like it would be a huge amount of work, but if it's the latter I fear for the long term survival of the project because it's going to be hard to build a community around such a project IMO.

Or is there a possibility that Firefox will try to integrate Servo even if it's developed outside of Mozilla? Seems unlikely to me.

[nvrspyx]

A third-option that I would like to see is extending the latter to an Electron alternative (aka using Servo as a cross-platform GUI). There's definitely positives to Electron, but it would be nice to see a more performant, less memory hungry, and more battery friendly alternative.

[devwastaken]

Servo last time I checked used the same if not more memory (100MB) for basic pages. There doesn't appear to be major differences for that application yet.

[jhoechtl]

Why should there be any great difference? Firefox is already written in a language where compilers have been optimized since decades.

Rust will not bring that magic.

[trevyn]

Rust makes it much easier to do complex performance optimizations safely, particularly those involving concurrency. The canonical example is the multi-threading of Servo’s CSS processor.

It’s not an automatic magic bullet, but in a world where humans are still writing the code, Rust’s feature set makes many performance optimizations much more practical.

[jhoechtl]

When did Firefox last crash on you? Aren't we optimzing on a problem which is practically non-existing?

[ben-schaaf]

Rust isn't what can bring that "magic", but a rewrite sure can.

[nine_k]

Why, better lifetimes' control could reduce the RSS, and reduce the GC time / energy.

(Provided that the C++ version is not strictly optimal WRT resource allocation; I think it's a rather safe bet.)

[devwastaken]

Hypothetically there should be possibilities for significant memory reduction by being able to deploy only what you need from the runtime instead of having everything loaded at once.

The memory usage part isn't really apart of rust or C, but rather that projects like chromium require significant hoops to jump through if you wanted to compile electron with only what you need.

I expect that servo will be tackling this issue, the browser works standalone and that's a hefty achievement in itself.

[asveikau]

I'm not personally a rust zealot, but I know that rust builds on LLVM and therefore benefits from some of that very same engineering effort that was built to optimize C and C++.

[Subsentient]

Clang usually has worse performance than GCC.

[trevyn]

Is there anything specific GCC does for performance that Clang/LLVM could adopt? How is this race expected to evolve over time?

[chubot]

Has anyone tried Cobalt? It looks like something based on it could be an alternative to Electron.

https://cobalt.foo/

It's meant for embedded but that probably just means it's easy to build and uses low memory.

A high-performance, small-footprint platform that implements a subset of HTML5/CSS/JS to run applications, including the YouTube TV app.

[spankalee]

Cobalt lags on modern web APIs pretty badly. I wouldn't recommend it.

[chubot]

Can you elaborate on that?

To be clear I wasn't suggesting that Cobalt is a replacement for Electron. Electronic has a lot of its own APIs too.

Rather, I wonder if Cobalt could be better than Servo along some dimensions as an engine for something like Electron.

[Razengan]

I wonder if they could also adapt into a game UI framework; design fast, cross platform, scalable game HUDs with HTML/JS.

[NetOpWibby]

I’ve posed this question several times online and in the Servo repo and the response was always, “Umm, no, not interested.”

[pjmlp]

The alternative exists since 20 years now, run a background daemon with local browser, or ping back in the platform WebWidgets.

[sergiomattei]

This is also my concern. Everyone's cheering on, but I'm just thinking... What's the mission and end goal now?

Previously it was doing research, with the possibility of landing in Firefox. Now that's highly unlikely.

[danShumway]

> Servo’s high-level goals remain unchanged: to provide a high-performance, safe rendering engine for embedding in other applications.

This is exactly what I want their goals to be. Embedding Chromium in applications is cumbersome, bloat applications, etc...

In the long run, having more options of web renders to use will help with everything, including browsers. Maybe it won't all be pulled into Firefox, but (ignoring all the other problems with DRM/regulation/anticompetive behavior/etc) it'll at least make it a little easier for other people to build browsers, and it opens the door for us to have more lightweight alternatives to applications like Electron.

[kodablah]

This is a big one for me. I have to use CEF because it's the only easily embeddable engine for me.

[jfk13]

Is it really so unlikely? Firefox integrates all kinds of components from elsewhere; why shouldn't it continue adopting parts of Servo where appropriate?

[cogman10]

Seems just more unlikely.

It's one thing for a mozilla team member to say "Hey, let's pull the servo css layout engine into firefox" It's a whole different thing for someone to say "Hey, let's pull the webkit css layout engine into firefox".

The servo stuff, while for experimentation, was ultimately geared towards the notion of landing parts of it into firefox. It was built for that. Under an opensource foundation maintainer model, there's a strong possibility that it moves from that as a goal.

[yjftsjthsd-h]

I would still expect servo to at loosely remain "firefox shaped", at least far more than the separately-developed webkit lineage.

[smnthermes]

The true difference is that Servo is more modular than WebKit.

[eznzt]

So the Servo developers will now work for free but Mozilla will start to leech from it? That would be uncool.

[DominoTree]

It's an open-source project - a lot of us have already been working for free :)

[edgyquant]

Would be preferable imo, helps keep the name in the news and is a reason for the product to exist and expand. If FF uses it and it gets embedded into web apps outside of that it will a big boon to the project and rust community.

[throwaway894345]

With respect to the latter, I agree that it seems unlikely that the project would attract users. Maybe it’s my own ignorance, but I don’t know what kind of apps (besides web browsers) would want just the web rendering engine and not various other components in a web browser. What are the responsibilities of a “web rendering engine” anyway? How tightly coupled is it to the DOM? Does it “own” the DOM, or is that owned by some other component in the browser? In the latter case, how are the relevant aspects of the DOM communicated to servo? And does the rest of the web engine query servo for things (e.g., “what are the exact coordinates of this <div>?”)? If this engine ends up not being so web-specific, then maybe it could be used as a replacement for Skia, more or less.

[akiselev]

You send Servo raw display lists, which is a format tailored specifically to represent the DOM but it acts like a generic slicing compositor in practice. It's not coupled in the classical sense - the display lists represent shapes, colors, stacks, rounded borders, etc..

It's more like Skia and can be used to develop GUI frameworks (which is exciting because Servo is Rust and Rust's GUI story is still in its early stages).

[tannhaeuser]

Thanks for that explanation. From the website, it wasn't quite clear to me (and still isn't tbh) whether servo is merely a rendering or also a CSS layout (+ parsing etc) engine.

[mst]

The Servo CSS engine is what powers Stylo to handle CSS in Firefox Quantum.

[szundi]

Very true, just wanted to find out what it is and not easy.

[throwaway894345]

Thanks for clarifying. This is exciting indeed! Are you aware of usage outside of browsers?

[LockAndLol]

The latter would be better, imo.

Chromium won because it introduced a sane API before Mozilla's Gecko. That's why you see so many Electron apps. Seriously, we don't need to wrap a whole browser. Just the engine and a debugger would've been fine.

The engine could be distributed as a lib and other frameworks could just bind it. Apps could be distributed without an 150MB behemoth just to have a chat client.

Making the engine also mobile compatible would mean Android and iOS could maybe have the same base. I also look forward to what this means for Linux phones. Custom browsers could be written for those that don't have to use WebKit or try to launch Chromium or Firefox on a mobile device.

Not only for mobile devices, but also displaying things in VR can be made significantly easier if you don't have to write all the UI yourself. Give it an opengl rectangular surface (or vulkan?) and you can then use web technologies to make UIs in VR.

All in all, I'm very for an engine. It would definitely allow a competitor with a good name to enter the market. Developer should be able to reach for something else than WebKit because nobody in their right mind is going to reach for Gecko.

[smnthermes]

> That's why you see so many Electron apps. Seriously, we don't need to wrap a whole browser

Actually, Electron wraps an entire browser, except for its UI part.

[tsimionescu]

I'm not sure what you mean by 'an engine', but people who choose Electron typically don't want a rendering engine like Servo, they want to write a web app and have it installed locally. They need a rendering engine, a JS runtime, a DOM handler, an HTTP client library, WebSockets support etc - they want a whole browser.

Also, 150MB is not really that scary of a size in today's world. Also, a huge part of it is simply because of static linking - if they split it into dynamic libraries, the actual content of any individual Electron-based app would be reduced significantly. But people are mostly allergic to dynamic libraries, so we pay the cost in larger binaries. Also note that vim with all its dependencies is ~40 MB, without a GUI.

[Deukhoofd]

> Also note that vim with all its dependencies is ~40 MB, without a GUI

That's mostly just due to vim-runtime though, and the documentation in many different languages. The actual vim executable is around 3 MB.

[tsimionescu]

Can the vim executable run without vim-runtime, or the other shared libaries it installz? I don't know the internal architecture of vim, I am genuinely asking.

[int_19h]

> Also, 150MB is not really that scary of a size in today's world

That very much depends on where you live.

[Jweb_Guru]

To be honest, a lot of people really do just want a layout engine.

[an_opabinia]

It’s tough. People really do want Flash, it’s just Google Chrome now.

The bigger question is when will Mobile Safari retire its WebKit fork? What role will Servo play in that inevitable end point?

[bsimpson]

Apple founded WebKit, so I doubt it will retire its repository.

Are you asking for iOS and macOS Safari to converge, or for Apple to ship straight from the open-source HEAD?

[satya71]

Apple forked WebKit from KDE KHTML.

[bsimpson]

They aren't mutually exclusive.

WebKit was originally based on KHTML, but Apple still founded WebKit and controls its source code. Even if WebKit was just Apple's name for their internal fork of KHTML, I don't see any reason they'd retire it.

Blink was originally spun-out of WebKit too. Similarly, Google controls Blink, and the two have diverged significantly in the intervening years. I suspect patches for any of them won't apply cleanly to the other two.

Regardless of their origins; KHTML, WebKit, and Blink are now independent pieces of software.

It's still unclear to me why anyone should expect Apple to retire WebKit for iOS.

[cies]

> Apple still founded WebKit

> Blink was originally spun-out of WebKit too

Founded, spun out of, forked... What's in the name?

I think one cannot "found" something that's largely based on a fork of something else.

[bsimpson]

There's more to a project than code. A project can absolutely be founded, even if the code is entirely based on another project.