5 ms·

I'm happy to hear servo is going to continue to exist. Please forgive the beginner's question: my understanding is that servo is "just" an engine, which needs

I'm happy to hear servo is going to continue to exist. Please forgive the beginner's question: my understanding is that servo is "just" an engine, which needs to be wrapped into a browser to really become usable. I've just tried (not for the first time, btw) your tech demo, which I think illustrates this perfectly. The rendering was lightning fast, but it's not a full browser. You state that your goals are "to provide a high-performance, safe rendering engine for embedding in other applications." Given that browsers are notoriously big software projects, do you think it will be an obstacle that servo is no longer tightly integrated with any sizeable browser project? Of course, I'm asking because I'm really afraid that the amazing effort that is servo might dwindle into irrelevance simply because there is no "killer app" for it, and embedding it into several small/niche products simply doesn't generate the same involvement as a web browser.

Finnucane 6y ago
Presumably any app that wants this kind of rendering could make use of it, not just browsers--consider all the apps that now use Electron for this.
- coddle-hark 6y ago
  Electron (WebKit) is much more than a rendering engine though. Sure, you could use Servo in a desktop app, but you’d have to also bundle all the other browser components (a JS engine, for example) individually. You’re basically building a browser at that point.
  - danShumway 6y ago
    Well, to be honest though, a lot of the criticism of Electron stems from the fact that it's more than just a rendering engine. There are a lot of applications where you'd want to take advantage of a browser view or a renderer or a JS engine, but not the rest of the stack. There are native apps where you might want a well-sandboxed JS engine for extension support, or where you're writing all of your core logic in C/Rust but you want to use HTML/CSS for your interface. Splitting up those components would be useful in a lot of situations.
    - smnthermes 6y ago
      > or where you're writing all of your core logic in C/Rust but you want to use HTML/CSS for your interface DOM is highly intertwined with JavaScript, so that wouldn't be possible.
      - RussianCow 6y ago
        This is clearly not true, since the DOM interface is implemented in something like C++ (or Rust, in this case) in browser engines, so you could write your logic in the same language, or even write a binding for any language you like.
        amaranth 6y ago
        Last time I looked in to it this is true for at least Servo though. DOM objects use the SpiderMonkey GC for memory management since that makes them easier to work with from JS and means they didn't have to write a separate graph manager or GC. DOM hierarchy is worst case scenario for the Rust borrow checker, they don't work well together at all.
  - lastontheboat 6y ago
    Servo currently incorporates a network stack, a JS engine, the DOM, JS APIs, an HTML parser, a CSS styling engine, graphical rendering, media parsing and playback, etc. It is not a browser, since it doesn't impose requirements about how to load specific pages, interact with tabs, expose history or bookmarks, etc.
    - M2Ys4U 6y ago
      I thought Servo linked with SpiderMonkey rather than including their own JS engine
      - lastontheboat 6y ago
        Correct. I didn't mean to imply otherwise.
    - oatmealsnap 6y ago
      Could it be used as a Linux desktop environment? I.e. Alternative to Gnome? I would love to be able to contribute improvements to the desktop environments I use, but I don’t have the time to learn languages that aren’t applicable to my daily work.
Manishearth 6y ago
Servo was never tightly integrated with a sizeable browser project. It shared some components with Firefox, but the only time Servo itself was inside an actual browser release was Firefox Reality for AR. Which still exists, though I'm not sure what the future of development for it will look like.
- dralley 6y ago
  I was holding out some hope that maybe Valve or Microsoft would consider it a worthwhile project to invest in.
  - kbenson 6y ago
    I think Valve and Microsoft are better served (for different reasons) by there being only one browser engine, the one they use. It's users that really gain from the competition. Companies may gain in the long run because of better performance and features (but I think most the low hanging fruit for performance has been picked), but in the short run it's a lot of risk just to help everyone, not yourself, which isn't where public companies shine.

Finnucane 6y ago

Presumably any app that wants this kind of rendering could make use of it, not just browsers--consider all the apps that now use Electron for this.

coddle-hark 6y ago
Electron (WebKit) is much more than a rendering engine though. Sure, you could use Servo in a desktop app, but you’d have to also bundle all the other browser components (a JS engine, for example) individually. You’re basically building a browser at that point.
- danShumway 6y ago
  Well, to be honest though, a lot of the criticism of Electron stems from the fact that it's more than just a rendering engine. There are a lot of applications where you'd want to take advantage of a browser view or a renderer or a JS engine, but not the rest of the stack. There are native apps where you might want a well-sandboxed JS engine for extension support, or where you're writing all of your core logic in C/Rust but you want to use HTML/CSS for your interface. Splitting up those components would be useful in a lot of situations.
  - smnthermes 6y ago
    > or where you're writing all of your core logic in C/Rust but you want to use HTML/CSS for your interface DOM is highly intertwined with JavaScript, so that wouldn't be possible.
    - RussianCow 6y ago
      This is clearly not true, since the DOM interface is implemented in something like C++ (or Rust, in this case) in browser engines, so you could write your logic in the same language, or even write a binding for any language you like.
      - amaranth 6y ago
        Last time I looked in to it this is true for at least Servo though. DOM objects use the SpiderMonkey GC for memory management since that makes them easier to work with from JS and means they didn't have to write a separate graph manager or GC. DOM hierarchy is worst case scenario for the Rust borrow checker, they don't work well together at all.
- lastontheboat 6y ago
  Servo currently incorporates a network stack, a JS engine, the DOM, JS APIs, an HTML parser, a CSS styling engine, graphical rendering, media parsing and playback, etc. It is not a browser, since it doesn't impose requirements about how to load specific pages, interact with tabs, expose history or bookmarks, etc.
  - M2Ys4U 6y ago
    I thought Servo linked with SpiderMonkey rather than including their own JS engine
    - lastontheboat 6y ago
      Correct. I didn't mean to imply otherwise.
  - oatmealsnap 6y ago
    Could it be used as a Linux desktop environment? I.e. Alternative to Gnome? I would love to be able to contribute improvements to the desktop environments I use, but I don’t have the time to learn languages that aren’t applicable to my daily work.

Manishearth 6y ago

Servo was never tightly integrated with a sizeable browser project. It shared some components with Firefox, but the only time Servo itself was inside an actual browser release was Firefox Reality for AR. Which still exists, though I'm not sure what the future of development for it will look like.

dralley 6y ago
I was holding out some hope that maybe Valve or Microsoft would consider it a worthwhile project to invest in.
- kbenson 6y ago
  I think Valve and Microsoft are better served (for different reasons) by there being only one browser engine, the one they use. It's users that really gain from the competition. Companies may gain in the long run because of better performance and features (but I think most the low hanging fruit for performance has been picked), but in the short run it's a lot of risk just to help everyone, not yourself, which isn't where public companies shine.