9 ms·

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, W

by simias 6y ago

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.

sergiomattei 6y ago
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.
- jfk13 6y ago
  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 6y ago
    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 6y ago
      I would still expect servo to at loosely remain "firefox shaped", at least far more than the separately-developed webkit lineage.
    - smnthermes 6y ago
      The true difference is that Servo is more modular than WebKit.
  - eznzt 6y ago
    So the Servo developers will now work for free but Mozilla will start to leech from it? That would be uncool.
    - DominoTree 6y ago
      It's an open-source project - a lot of us have already been working for free :)
    - edgyquant 6y ago
      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.
- danShumway 6y ago
  > 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 6y ago
    This is a big one for me. I have to use CEF because it's the only easily embeddable engine for me.
throwaway894345 6y ago
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 6y ago
  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 6y ago
    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 6y ago
      The Servo CSS engine is what powers Stylo to handle CSS in Firefox Quantum.
    - szundi 6y ago
      Very true, just wanted to find out what it is and not easy.
  - throwaway894345 6y ago
an_opabinia 6y ago
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 6y ago
  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 6y ago
    Apple forked WebKit from KDE KHTML.
    - bsimpson 6y ago
      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 6y ago
        > 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 6y ago
        There's more to a project than code. A project can absolutely be founded, even if the code is entirely based on another project.
LockAndLol 6y ago
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 6y ago
  > 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 6y ago
  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 6y ago
nvrspyx 6y ago
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 6y ago
  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 6y ago
    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.
    - alexusgracia 6y ago
      Yap, it's magic
    - ben-schaaf 6y ago
      Rust isn't what can bring that "magic", but a rewrite sure can.
    - nine_k 6y ago
      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.)
    - asveikau 6y ago
      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++.

by simias 6y ago

sergiomattei 6y ago

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.

jfk13 6y ago
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 6y ago
  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 6y ago
    I would still expect servo to at loosely remain "firefox shaped", at least far more than the separately-developed webkit lineage.
  - smnthermes 6y ago
    The true difference is that Servo is more modular than WebKit.
- eznzt 6y ago
  So the Servo developers will now work for free but Mozilla will start to leech from it? That would be uncool.
  - DominoTree 6y ago
    It's an open-source project - a lot of us have already been working for free :)
  - edgyquant 6y ago
    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.
danShumway 6y ago
> 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 6y ago
  This is a big one for me. I have to use CEF because it's the only easily embeddable engine for me.

throwaway894345 6y ago

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 6y ago
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 6y ago
  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 6y ago
    The Servo CSS engine is what powers Stylo to handle CSS in Firefox Quantum.
  - szundi 6y ago
    Very true, just wanted to find out what it is and not easy.
- throwaway894345 6y ago

an_opabinia 6y ago

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 6y ago
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 6y ago
  Apple forked WebKit from KDE KHTML.
  - bsimpson 6y ago
    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 6y ago
      > 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 6y ago
        There's more to a project than code. A project can absolutely be founded, even if the code is entirely based on another project.

LockAndLol 6y ago

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 6y ago
> 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 6y ago
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 6y ago

nvrspyx 6y ago

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 6y ago
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 6y ago
  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.
  - alexusgracia 6y ago
    Yap, it's magic
  - ben-schaaf 6y ago
    Rust isn't what can bring that "magic", but a rewrite sure can.
  - nine_k 6y ago
    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.)
  - asveikau 6y ago
    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++.