11 ms·
We've been cagey about this over the months since the Servo team at Mozilla was disbanded, since there were various moving pieces that needed to fall into place
by lastontheboat 6y ago
We've been cagey about this over the months since the Servo team at Mozilla was disbanded, since there were various moving pieces that needed to fall into place. We're excited about the possibility for Servo to continue growing and evolving in its new home, though!
- erickt 6y agoThis is great news! I'm glad Servo found a place to land. Are you planning on sticking with the MPL-2.0 license, or are you also considering relicensing as well?
- deleted 6y ago[deleted]
- lastontheboat 6y agoThere is no plan to relicense at this time.
- simias 6y agoWhat'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 agoThis 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 agoIs 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 agoSeems 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 agoI would still expect servo to at loosely remain "firefox shaped", at least far more than the separately-developed webkit lineage.
- smnthermes 6y agoThe true difference is that Servo is more modular than WebKit.
- eznzt 6y agoSo the Servo developers will now work for free but Mozilla will start to leech from it? That would be uncool.
- DominoTree 6y agoIt's an open-source project - a lot of us have already been working for free :)
- edgyquant 6y agoWould 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 6y agoWith 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 agoYou 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 agoThanks 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.
- throwaway894345 6y ago
- an_opabinia 6y agoIt’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 agoApple 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 agoApple forked WebKit from KDE KHTML.
- bsimpson 6y agoThey 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 agoThere'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 agoThe 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 agoI'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 agoA 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 agoServo 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 agoWhy 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 agoYap, it's magic
- ben-schaaf 6y agoRust isn't what can bring that "magic", but a rewrite sure can.
- nine_k 6y agoWhy, 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 agoI'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++.
- webmaven 6y agoI don't imagine this is news to you, but just in case, the 'Contributing' link 404s.
- networkimprov 6y agoI looked for a list of projects currently embedding Servo, or planning to, but didn't find one. Is any software embedding it now?
- andrewmcwatters 6y agoKinda hard when they don't even tell you how.
- kbumsik 6y agoServo is not production ready yet. We don't even know how may years it will take for 1.0. So no software would use it for now.
- networkimprov 6y agoPlenty of pre-production software is built with pre-production dependencies. Does it not work for a useful subset of HTML/CSS?
- codys 6y agoCan you talk a bit about the "moving pieces" and/or the process here? Interested in the process of doing this type of migration.
- SimonSapin 6y agoThere’s things like finding an agreement over https://uspto.report/TM/87796973 https://uspto.report/TM/87796973 and setting up everything in https://servo.org/governance/ https://servo.org/governance/. And on the technical side, although it’s not a blocker for announcing: https://github.com/servo/project/issues/25 https://github.com/servo/project/issues/25
- wiz21c 6y agoHmmm Well, I'm not in the business, but if the team was disbanded, then where's the knowledge gone and who will be the next paid team ? I ask because I guess Servo is not the kind of project you just commit some patch over the weekend...
- lastontheboat 6y agoHonestly the project has had >1000 contributors over the past 8 years and a lot of them did just that.
- wiz21c 6y agoha, should have checked that. Thanks for pointing out :-)
- barkingcat 6y agoWell, it could be. Almost all open source projects are like this. If you find a typo in a readme file, put in a pull request. Do 10 of those, and you'll probably have enough understanding to fix one off errors in the documentation. Do 10 more of those, and you might start answering questions from other people re: how to help the servo project. Answer 10 of those questions, and you might go, oh hell, I'm already answering questions, why don't I write a blog post introducing people to the servo project so you aren't repeating the same thing over and over again. write 10 of those kinds of articles, and you'll be ready to be mentored by the great servo and rust community and start making larger code changes, algorithm changes, implementing a feature that you really wanted, and so on. You gotta start small!
- vanderZwan 6y agoTangent: is your username in combination with that comment a reference to the Mozilla Lifeboat?
- lastontheboat 6y agoNo, it was a name I took when joining a bunch of social sites back in 2012 and feeling like I was the last person in my circles to do so.
- deleted 6y ago[deleted]
- patafrita 6y agoyes