Is it really so unlikely? Firefox integrates all kinds of components from elsewhere; why shouldn't it continue adopting parts of Servo where appropriate?
So the Servo developers will now work for free but Mozilla will start to leech from it? That would be uncool.
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.
It seems more than a bit presumptuous to tell open source maintainers what they “need to” do. If they announced tomorrow they’d decided to focus all their efforts on using Rust to calculate digits of pi, that’s their perogative. As a prolific creator with a strong sense of vision for your projects, I’d have expected this to be obvious.
They're free to spend their time on whatever they want, and I wouldn't presume to tell them what to do. What I am doing here is not that. I am explaining a fact. If you want to go to the moon, you need a rocket. Building a zero-gee deep fryer to serve hotdogs on the way is not going to get the job done.
Now they are free to spend their (free) time on what they want. When most of the core contributors where payed by Mozilla, they could not chose to eg. "focus on web compat", hence they went on something you consider useless, but that kept the project alive. That allowed a few other things to be done like the re-write of the parallel layout.
Of course we can't know for sure what would have happened if they refused to work on VR, but my gut feeling is that this would not have helped the project.
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.
I was holding out some hope that maybe Valve or Microsoft would consider it a worthwhile project to invest in.
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.
> 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.
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.
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.
Awesome! I've been tire kicking their nightlys. I was thinking about building a "browser" but really mean just wrapping an engine. With the shakeup at M I was nervous that Servo would die, it's got a lot of promise. This is great news. Now, thoughts on a UI framework for Rust?
My personal opinion is that, for a servo based browser, it's probably better to just use UWP/C++ on Windows, C/GTK on Linux, and SwiftUI on Mac, and just embed Servo via its C-API layer. Rust shine when it comes to building a safe and fast web engine. For the OS "glue" code, I would stick to whatever is best for each platform.
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.
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.
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++.
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 th…
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.
I wonder if they could also adapt into a game UI framework; design fast, cross platform, scalable game HUDs with HTML/JS.
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.
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++.
I'd prefer the LGPL to the MPL for projects where a less viral copyleft is wanted.
LGPL doesn't work for languages that don't have good support for dynamic linking. Static linking is mostly incompatible with the LGPL. That makes it unusable for Rust, Go, and some C++ libraries. Wheras with MPLv2 the contract is basically "if you make a change to any of the source code files derived from the original work, those changes have to remain under MPLv2". But linking that code from non-copyleft code is OK,…
The LGPL definitely allows static linking, you just have to make it feasible for the user to modify the open source parts of the library and relink them into your proprietary application.