Servo’s new home(blog.servo.org)
blog.servo.org
Servo’s new home
https://blog.servo.org/2020/11/17/servo-home/
323 comments
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!
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.
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.
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.
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.
Rust will not bring that magic.
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.
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.
When did Firefox last crash on you? Aren't we optimzing on a problem which is practically non-existing?
Rust isn't what can bring that "magic", but a rewrite sure can.
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.)
(Provided that the C++ version is not strictly optimal WRT resource allocation; I think it's a rather safe bet.)
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.
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.
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++.
Clang usually has worse performance than GCC.
Is there anything specific GCC does for performance that Clang/LLVM could adopt? How is this race expected to evolve over time?
Not answering your question but in my experience reading assembly output of the two compilers the unoptimized output of Clang is atrocious while GCC is closer of what a human could have wrote. Clang seems to have to do better in optimization passes to archive similar results. Usually Clang was a faster compiler in O1 but I don’t think it’s true anymore.
that's just because gcc has certain optimization passes that can't be disabled
(that said gcc -O0 is still absolutely nothing like what a human would write)
(that said gcc -O0 is still absolutely nothing like what a human would write)
it's not so much that gcc does anything specific so much as LLVM is just really really inefficient—they don't track compilation time at all so it's easy for releases to regress, half the stuff in there is academics implementing their PhD thesis aiming for algorithmic accuracy with little regard for efficiency, and LLVM's design itself is somewhat inefficient (multiple IRs, lots and lots of pointers in IR representation, etc)
that said this makes it an excellent testbed but compilation time will keep getting slower every release until they start caring about it
that said this makes it an excellent testbed but compilation time will keep getting slower every release until they start caring about it
The rust compiler team now tracks LLVM performance, see [0]. They are able to spot regressions as soon as they get merged, and petition to get the change reverted or performance fixed when the impact is large. This has been fairly successful so far, but obviously needs sustained efforts if we are to ever dream of ever getting halfway decent compilation times.
[0]: https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html
[0]: https://nikic.github.io/2020/05/10/Make-LLVM-fast-again.html
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.
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.
Cobalt lags on modern web APIs pretty badly. I wouldn't recommend it.
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.
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.
I wonder if they could also adapt into a game UI framework; design fast, cross platform, scalable game HUDs with HTML/JS.
I’ve posed this question several times online and in the Servo repo and the response was always, “Umm, no, not interested.”
The alternative exists since 20 years now, run a background daemon with local browser, or ping back in the platform WebWidgets.
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.
Previously it was doing research, with the possibility of landing in Firefox. Now that's highly unlikely.
Is it really so unlikely? Firefox integrates all kinds of components from elsewhere; why shouldn't it continue adopting parts of Servo where appropriate?
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.
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.
I would still expect servo to at loosely remain "firefox shaped", at least far more than the separately-developed webkit lineage.
The true difference is that Servo is more modular than WebKit.
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's an open-source project - a lot of us have already been working for free :)
> 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.
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.
This is a big one for me. I have to use CEF because it's the only easily embeddable engine for me.
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.
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).
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).
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.
Thanks for clarifying. This is exciting indeed! Are you aware of usage outside of browsers?
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.
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.
> 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.
Actually, Electron wraps an entire browser, except for its UI part.
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.
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.
> 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.
That's mostly just due to vim-runtime though, and the documentation in many different languages. The actual vim executable is around 3 MB.
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.
> Also, 150MB is not really that scary of a size in today's world
That very much depends on where you live.
That very much depends on where you live.
To be honest, a lot of people really do just want a layout engine.
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?
The bigger question is when will Mobile Safari retire its WebKit fork? What role will Servo play in that inevitable end point?
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?
Are you asking for iOS and macOS Safari to converge, or for Apple to ship straight from the open-source HEAD?
Apple forked WebKit from KDE KHTML.
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.
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.
> 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.
> 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.
There's more to a project than code. A project can absolutely be founded, even if the code is entirely based on another project.
Hmmm 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...
Well, 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!
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!
Honestly the project has had >1000 contributors over the past 8 years and a lot of them did just that.
ha, should have checked that. Thanks for pointing out :-)
I looked for a list of projects currently embedding Servo, or planning to, but didn't find one.
Is any software embedding it now?
Is any software embedding it now?
Servo 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.
Plenty of pre-production software is built with pre-production dependencies.
Does it not work for a useful subset of HTML/CSS?
Does it not work for a useful subset of HTML/CSS?
Kinda hard when they don't even tell you how.
This 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?
There is no plan to relicense at this time.
[deleted]
I don't imagine this is news to you, but just in case, the 'Contributing' link 404s.
Tangent: is your username in combination with that comment a reference to the Mozilla Lifeboat?
No, 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]
Can you talk a bit about the "moving pieces" and/or the process here? Interested in the process of doing this type of migration.
There’s things like finding an agreement over https://uspto.report/TM/87796973 and setting up everything in https://servo.org/governance/. And on the technical side, although it’s not a blocker for announcing: https://github.com/servo/project/issues/25
Pretty good news day for Rust between this, min_const_generics stabilizing[0], and CXX 1.0 (including a nice "book")[1] being released.
EDIT: Oh, and the Rust performance book[2].
[0]: https://github.com/rust-lang/rust/pull/79135
[1]: https://cxx.rs
[2]: https://nnethercote.github.io/perf-book/
EDIT: Oh, and the Rust performance book[2].
[0]: https://github.com/rust-lang/rust/pull/79135
[1]: https://cxx.rs
[2]: https://nnethercote.github.io/perf-book/
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
I thought Servo linked with SpiderMonkey rather than including their own JS engine
Correct. I didn't mean to imply otherwise.
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.
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.
With the growing concern about browser monopoly and engine monopoly going against everything the web was intended to be, are you planning on acquiring funding from government grants? EU at least used to give out money to interesting projects, is there hope for servo to get some?
Quite possible. But you need an EU entity for that and it's likely why Eclipse Foundation (Eclipse Foundation != Eclipse IDE for those who are not aware but rather a competitor to Apache and Linux foundations) has moved to Europe: https://newsroom.eclipse.org/news/announcements/open-source-...
Indeed, as an FYI the LF is truly "Foundation as a Service" and has entities in the US, EU, Japan and China. The RISC-V Foundation (hosted by the LF) is even based out of Switzerland.
> Linux Foundation is truly "Foundation as a Service"
That made me chuckle. If you have a reading about that, I think I would enjoy.
That made me chuckle. If you have a reading about that, I think I would enjoy.
heh, here's a couple links that should be useful:
https://www.linuxfoundation.org/blog/2020/05/building-a-succ... https://www.linuxfoundation.org/blog/2020/09/software-define...
Along with an older presentation I gave on the topic: https://docs.google.com/presentation/d/1Q2jKVpeGkbDVdcUhrzxC...
https://www.linuxfoundation.org/blog/2020/05/building-a-succ... https://www.linuxfoundation.org/blog/2020/09/software-define...
Along with an older presentation I gave on the topic: https://docs.google.com/presentation/d/1Q2jKVpeGkbDVdcUhrzxC...
I am confused. I thought it is the raison d'être of Mozilla to develop a browser. So how does it come that the brand new browser engine they developed is being given away?
I mean, even if they need to cut costs, isn't Servo part of the team they should keep until the end?
I mean, even if they need to cut costs, isn't Servo part of the team they should keep until the end?
Because they wanted to "put a crisper focus on new product development and go to market activities."[1] I'm sure that explains it well...
[1] https://blog.mozilla.org/wp-content/uploads/2020/08/Message-...
[1] https://blog.mozilla.org/wp-content/uploads/2020/08/Message-...
>I am confused. I thought it is the raison d'être of Mozilla to develop a browser.
To put it bluntly: Mozilla is no longer a browser company. It is a patsy for google to point to and say "See we're not a monopoly.". Secondary goals are increasing the supply of devs for big tech and lowering wages.
To put it bluntly: Mozilla is no longer a browser company. It is a patsy for google to point to and say "See we're not a monopoly.". Secondary goals are increasing the supply of devs for big tech and lowering wages.
> lowering wages
Except for the leadership.
Except for the leadership.
oof
There is some cost/effort to building a better browser engine. They might believe that the same cost/effort would better benefit the business if put elsewhere.
You see this at companies when engineering teams get it into their heads that they need to rewrite in a new framework. There's a trade-off between that work and building new features for customers. The benefits might be worth it in the long term! They also might not be.
That seems to be the call Mozilla made. I don't know if it's the right one, but it seems to be what they did.
You see this at companies when engineering teams get it into their heads that they need to rewrite in a new framework. There's a trade-off between that work and building new features for customers. The benefits might be worth it in the long term! They also might not be.
That seems to be the call Mozilla made. I don't know if it's the right one, but it seems to be what they did.
>There is some cost/effort to building a better browser engine. They might believe that the same cost/effort would better benefit the business if put elsewhere.
Yes, because all those years the Mozilla executive team has proved that they have a good grasp of where the cost/effort optimum lies... /s
Yes, because all those years the Mozilla executive team has proved that they have a good grasp of where the cost/effort optimum lies... /s
From the outside it seems like eating the seeds for next years harvest.
I can't speak for how things were at Mozilla, I have no idea. But separate teams working on "rewrites" of platforms that other teams have to maintain often leads to a demoralized environment, pointless duplicated work, and elongated schedules and failure to deliver on milestones.
I've seen it several times: Often after years of promises from "the new hot" team, with them cannibalizing resources and top talent but missing milestones and still having failed to deliver, the new beast is cancelled and the value of the "old" system is suddenly recognized.
There's the classic Spolsky essay about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
What's better? Refactor the old thing as you go. Include the "legacy" team in the development team of the new thing. Even more so, make the "new" team work on the old thing as well. Rotate developers between the two, build a culture of respect.
Not saying that is what happened at Moz, but I've seen it play out so many times. And without a concrete commitment to be forced to deliver to actual customers projects like these can just go forever noodling around in perfection-land.
I've seen it several times: Often after years of promises from "the new hot" team, with them cannibalizing resources and top talent but missing milestones and still having failed to deliver, the new beast is cancelled and the value of the "old" system is suddenly recognized.
There's the classic Spolsky essay about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
What's better? Refactor the old thing as you go. Include the "legacy" team in the development team of the new thing. Even more so, make the "new" team work on the old thing as well. Rotate developers between the two, build a culture of respect.
Not saying that is what happened at Moz, but I've seen it play out so many times. And without a concrete commitment to be forced to deliver to actual customers projects like these can just go forever noodling around in perfection-land.
My understanding is that Servo was more experimental research, with an eye towards possibly being integrated at some point.
Except multiple parts of it had already been integrated into Firefox, providing its most recent performance gains (Webrender, Stylo).
Yes, they were developed in Servo first, then brought over when mature.
I wonder if this is the end of that model, or more an effort to get external people to contribute more to Servo.
I wonder if this is the end of that model, or more an effort to get external people to contribute more to Servo.
Based on their public communications, it's the former. They want to focus on rustifying Firefox directly rather than trying to integrate massive chunks of Rust code written in an external project.
Does Firefox have any Rust component at all if Servo is not apparently used at all by it, currently?
People have been claiming Firefox components were written in Rust for ages, usually meaning Servo, but it seems now that those claims were just misleading.
People have been claiming Firefox components were written in Rust for ages, usually meaning Servo, but it seems now that those claims were just misleading.
They weren't misleading, and they didn't mean servo. Several Firefox parts are written in Rust. Stylo is the most famous, here's a list of various parts that have already shipped, and others that were/are in progress...
https://wiki.mozilla.org/Oxidation
https://wiki.mozilla.org/Oxidation
> Does Firefox have any Rust component at all
Yes, lots (and increasing). E.g.:
https://searchfox.org/mozilla-central/source/servo/component...
https://searchfox.org/mozilla-central/source/gfx/wr
https://searchfox.org/mozilla-central/source/third_party/rus...
Yes, lots (and increasing). E.g.:
https://searchfox.org/mozilla-central/source/servo/component...
https://searchfox.org/mozilla-central/source/gfx/wr
https://searchfox.org/mozilla-central/source/third_party/rus...
https://wiki.mozilla.org/Oxidation#Rust_Components is probably the most up to date
The first Rust component in Firefox was the URL parser, followed by the MP4 metadata arser for audio. Then the charset conversion component was rewritten in Rust, and then some other tiny components. And then Firefox imported Stylo (the CSS parsing and rendering) from Servo as the biggest Rust component yet. The Web Assembly portion of the JS engine is shifting to cranelift (written in Rust) as its backend, another massive component, but I don't believe it has done so in a released browser version yet.
In general, a lot of text handling, and parsing in general, is moving to Rust, although some code is moving far more slowly than others. Additionally, APIs that had been implemented in JS that are too slow (or memory-heavy) are being moved to a Rust implementation instead, such as the l10n implementation.
In general, a lot of text handling, and parsing in general, is moving to Rust, although some code is moving far more slowly than others. Additionally, APIs that had been implemented in JS that are too slow (or memory-heavy) are being moved to a Rust implementation instead, such as the l10n implementation.
[deleted]
A lot of people misunderstand what Servo was. It was for developing components that could be integrated into a browser. Firefox integrated most of those and continues to develop more code in Rust. Servo lost it's use.
From an outsider point of view, I feel like Mozilla really missed the opportunity to invest in servo as a real world renderer and build a community around it. In this day and age is a shame that various out-of-date versions of webkit are the only things that you can build a niche browser on.
By niche I mean the myriad of keyboard driven browsers. kiosks, QML, electron, etc.
By niche I mean the myriad of keyboard driven browsers. kiosks, QML, electron, etc.
Damn, so Mozilla just threw away Servo.
I most definitely agree.
All I can think is that they took a look at Servo and decided it was cool tech but was really nowhere near delivering things they needed for Firefox aside from Stylo which it had already delivered.
All I can think is that they took a look at Servo and decided it was cool tech but was really nowhere near delivering things they needed for Firefox aside from Stylo which it had already delivered.
That seems to be what everyone was wondering about when they laid off a large portion of their web teams
How many paid developers will it have now, and how many did it have at Mozilla?
None at the moment. Help is welcome: https://servo.org/#support-and-donations :)
I have a hard time believing that a project as ambitious as servo can survive without several paid core developers.
Look at the corporate sponsors (that include Samsung and Huawei) - they may provide paid contributors.
I strongly believe that you could get funded by Google if you attempted to port stylo to chromium.
Firefox still has state of the art css performance I believe, thanks to stylo.
First the Chrome team needs to be convinced to use Rust.
They have done some exploratory work, but nothing that shows they would actually do it.
They are most likely to just double down on the ongoing C++ lifetimes support on LLVM than switch languages.
They have done some exploratory work, but nothing that shows they would actually do it.
They are most likely to just double down on the ongoing C++ lifetimes support on LLVM than switch languages.
The same Google that suffers from "Not Invented Here" syndrome? We're talking about a company that literally tried to supplant the defacto language of the web!! Highly doubt it.
Besides, nothing's stopping them from porting it without funding the project.
Besides, nothing's stopping them from porting it without funding the project.
Right - unfortunately I feel like this is the most important question. I would have loved for someone with deep pockets like MS to take over servo. (Or even like Alibaba or Tencent)
Wow, this is awesome.
- Mozilla engineering finally gets the green light to beat Chrome through a from-scratch rendering stack
- This skunkworks initative popularizes the world's first viable C++ contender and interesting "mainstreamable" programming language
- Manglement suddenly lays off the teams responsible for both projects (Rust and Servo)
- Some awesome person from the trenches convinces said manglement to release governance of the rendering engine so it can be developed independently ((of said manglement))...
- ???
- Profit...?
This is real engineering and strategic problem solving. It's inspiring to see.
What is very annoying is that a Mozilla-branded web browser already took the "Phoenix" product name. :(
- Mozilla engineering finally gets the green light to beat Chrome through a from-scratch rendering stack
- This skunkworks initative popularizes the world's first viable C++ contender and interesting "mainstreamable" programming language
- Manglement suddenly lays off the teams responsible for both projects (Rust and Servo)
- Some awesome person from the trenches convinces said manglement to release governance of the rendering engine so it can be developed independently ((of said manglement))...
- ???
- Profit...?
This is real engineering and strategic problem solving. It's inspiring to see.
What is very annoying is that a Mozilla-branded web browser already took the "Phoenix" product name. :(
Why is Mozilla not betting on Rust anymore?
Mozilla has decided to move to a different mission less about improving the web and more about enacting things that make them money, so they can continue to pay a large CEO salary and push policy objectives against free speech.
Unfortunately Mozilla seemed to go from "awesome" to really disappointing in a very short time window.
Unfortunately Mozilla seemed to go from "awesome" to really disappointing in a very short time window.
Wow, that is a hugely loaded statement. Even if it is 100% true, the level of derision and bias should make any person not familiar with the situation question everything you say.
If you're going to be that biased, at least back it up. And by back it up, I mean at LEAST throwing in some statements of fact, if not URLs.
If you're going to be that biased, at least back it up. And by back it up, I mean at LEAST throwing in some statements of fact, if not URLs.
Every thread tangentially related to Mozilla has a bunch of people who don't understand how non-profits work come in and complain about executive compensation.
I'd say >$2.4M in exec comp[1] isn't just making up for a lack of stock options.
[1] - https://www.cnet.com/news/mozilla-cuts-70-staff-as-part-of-p...
[1] - https://www.cnet.com/news/mozilla-cuts-70-staff-as-part-of-p...
The absolute number doesn't matter. Non-profits participate in the same labor market as for-profit companies. You have to compare it to executive salaries for other similarly sized companies in their market segment to make the argument that she is overpaid. Otherwise you're just arguing against income inequality, which is not a problem exclusive to Mozilla, and crippling Mozilla's ability to participate in that labor market will not fix it.
Does Mozilla compete with for profit companies for C suite market? Which technology intensive company hire a CEO who is lawyer by profession and hasn't had any redeeming resume for management and technology. If you look at firefox's market share, the only growth it had was when she was not a CEO. Seriously, Mozilla is not competing with for profit companies in C suite labor market.
Does Mozilla compete with for profit companies for C suite market?
Yes, Baker is CEO of the for profit corporation.
Which technology intensive company hire a CEO who is lawyer by profession and hasn't had any redeeming resume for management and technology.
Are you aware that she cofounded the project in the 90s? Mozilla (corporation) didn't just decide to hire a lawyer out of the blue in 2018.
Yes, Baker is CEO of the for profit corporation.
Which technology intensive company hire a CEO who is lawyer by profession and hasn't had any redeeming resume for management and technology.
Are you aware that she cofounded the project in the 90s? Mozilla (corporation) didn't just decide to hire a lawyer out of the blue in 2018.
> You have to compare it to executive salaries for other similarly sized companies in their market segment to make the argument that she is overpaid.
No, a non-profit does not need to attract someone who only cares about making money.
Hiring someone willing to work for less would ultimately be better for a non-profit, since it's an indicator that they care about the mission, and not purely about the money.
If you hire someone who wants over 2M, you hire someone who cares about your money, not your ideals, and will push the organisation in that direction.
No, a non-profit does not need to attract someone who only cares about making money.
Hiring someone willing to work for less would ultimately be better for a non-profit, since it's an indicator that they care about the mission, and not purely about the money.
If you hire someone who wants over 2M, you hire someone who cares about your money, not your ideals, and will push the organisation in that direction.
> The pay for Mozilla Chair and longtime leader Mitchell Baker in 2018, the most recent year for which the organization released the information, surpassed $2.4 million.
[deleted]
Mozilla currently cares more about surviving than its main mission. And yes, it can't accomplish its mission if it dies, but don't they understand? If Mozilla falls, another will take its place.
The way to kill Mozilla is from the inside: to quash its soul.
The way to kill Mozilla is from the inside: to quash its soul.
> Mozilla currently cares more about surviving than its main mission.
In the open market, any organization that doesn't cares more about its survival than its mission will eventually be replaced by one that does. This is fundamental to the definition of "survival".
> If Mozilla falls, another will take its place.
The one that will take its place will be an organization that prioritizes survival, not its mission.
In the open market, any organization that doesn't cares more about its survival than its mission will eventually be replaced by one that does. This is fundamental to the definition of "survival".
> If Mozilla falls, another will take its place.
The one that will take its place will be an organization that prioritizes survival, not its mission.
Organisations are made of people. There are enough people who care about Mozilla's mission that they'd do the things even if Mozilla didn't, and if they got together they could get at least 10% of the funding from non-Google people who currently donate to Mozilla, if Mozilla ceased to exist.
The only real downside is that they wouldn't have a seat on the WHATWG.
The only real downside is that they wouldn't have a seat on the WHATWG.
> If Mozilla falls, another will take its place.
Yes, another chrome skin perhaps?
Yes, another chrome skin perhaps?
> pay a large CEO salary
Sure, I’ll buy that.
> push policy objectives against free speech
Can people please stop this latent homophobia? Mozilla fired a person who donated money to a deplorable cause. You can try to hide behind free speech, but we all know what this is about.
Sure, I’ll buy that.
> push policy objectives against free speech
Can people please stop this latent homophobia? Mozilla fired a person who donated money to a deplorable cause. You can try to hide behind free speech, but we all know what this is about.
> Can people please stop this latent homophobia? Mozilla fired a person who donated money to a deplorable cause. You can try to hide behind free speech, but we all know what this is about.
He quit. And I don’t agree with it, but I wouldn’t exactly call his cause deplorable. People with those views can believe they’re being completely ethical. That was also in 2008, a different political climate, and nobody allowed him to learn from it or to restitute.
Of course, I agree that wasn’t their downfall—it was simply misdirected goals and funding.
He quit. And I don’t agree with it, but I wouldn’t exactly call his cause deplorable. People with those views can believe they’re being completely ethical. That was also in 2008, a different political climate, and nobody allowed him to learn from it or to restitute.
Of course, I agree that wasn’t their downfall—it was simply misdirected goals and funding.
>He quit. And I don’t agree with it, but I wouldn’t exactly call his cause deplorable.
The purpose of Proposition 8 was to remove the right to marry from gay couples - yes remove - because the courts had already granted them that right.
If I was a gay Mozilla employee and I learned that my CEO wanted to remove rights which the legal system had already granted me, I would be so incredibly demoralized and pissed.
Regardless of personal beliefs, it's a bad thing for a leader of a tech company to be doing if they want to retain talent.
The purpose of Proposition 8 was to remove the right to marry from gay couples - yes remove - because the courts had already granted them that right.
If I was a gay Mozilla employee and I learned that my CEO wanted to remove rights which the legal system had already granted me, I would be so incredibly demoralized and pissed.
Regardless of personal beliefs, it's a bad thing for a leader of a tech company to be doing if they want to retain talent.
It was a really weird and messy situation, and unpleasant to live through.
I agree that Brendan's Prop 8 donation was bad. But he did it privately, and never (AFAIK) made anti-LGBT comments in public. People who had worked with him for many years were surprised to find he had these views. It was only found out because of political donation public disclosure laws.
Some Mozilla employees publicly criticized Brendan for the Prop 8 donation, but some defended him, because of the aforementioned privateness of it. A number of the defenses came from LGBT employees.
The pile-on at the time was intense. It lasted more than a week. It reached the front page of my local paper. Crazy stuff.
Brendan chose to stand down as CEO and also quit Mozilla. He wasn't fired, and Mozilla leadership asked him to stay.
All this nuance was lost. Lots of left-leaning people concluded that Mozilla had knowingly promoted a proudly anti-LGBT guy to CEO. Lots of right-leaning people concluded that Mozilla had fired their CEO for his political views. Both conclusions were greatly over-simplified. Almost everyone found a reason to hate Mozilla. Bad times!
I agree that Brendan's Prop 8 donation was bad. But he did it privately, and never (AFAIK) made anti-LGBT comments in public. People who had worked with him for many years were surprised to find he had these views. It was only found out because of political donation public disclosure laws.
Some Mozilla employees publicly criticized Brendan for the Prop 8 donation, but some defended him, because of the aforementioned privateness of it. A number of the defenses came from LGBT employees.
The pile-on at the time was intense. It lasted more than a week. It reached the front page of my local paper. Crazy stuff.
Brendan chose to stand down as CEO and also quit Mozilla. He wasn't fired, and Mozilla leadership asked him to stay.
All this nuance was lost. Lots of left-leaning people concluded that Mozilla had knowingly promoted a proudly anti-LGBT guy to CEO. Lots of right-leaning people concluded that Mozilla had fired their CEO for his political views. Both conclusions were greatly over-simplified. Almost everyone found a reason to hate Mozilla. Bad times!
What even is Mozilla betting on at this point?
It seems like they're just not placing big bets now. Creating an entire new programming language is a big bet, one that I'd argue already looks like it's paid off, but Mozilla has decided their future is as a much leaner company that does fewer experiments. It really is a shame.
IDK they put a lot of resources into the quantum project and it didn't really increase their market share, in fact in Germany it dwindled more quickly. Now it's stabilized again IIRC but which signal does that send to management? The market didn't reward Rust adoption, as successful as the language is outside of the browser.
the CEO needs a new house.
She's hardly the most overpaid CEO in tech, but she seems to come up pretty often for some reason.
> for some reason
This isn't a mystery. Mozilla accept donations. It isn't an ordinary for-profit corporation.
Yes, they separate Mozilla Corporation from Mozilla Foundation, but the point stands. If Mozilla are going to claim to make browsers, apps, code and tools that put people before profit, [0] they should expect backlash when they lay off engineers while continuing to overpay their leadership, despite continuing poor outcomes under their stewardship. [1]
[0] https://www.mozilla.org/en-US/about/
[1] http://calpaterson.com/mozilla.html
This isn't a mystery. Mozilla accept donations. It isn't an ordinary for-profit corporation.
Yes, they separate Mozilla Corporation from Mozilla Foundation, but the point stands. If Mozilla are going to claim to make browsers, apps, code and tools that put people before profit, [0] they should expect backlash when they lay off engineers while continuing to overpay their leadership, despite continuing poor outcomes under their stewardship. [1]
[0] https://www.mozilla.org/en-US/about/
[1] http://calpaterson.com/mozilla.html
Some people have an axe to grind with Mozilla since that whole Brendan Eich thing, and on top of that there's just good old sexism.
This all contributes to create a very toxic subject that I generally tend to avoid, but I think that it's fair at this point to question Mozilla's execs results at this point. These past few years have been pretty brutal for Mozilla, and there's no clear path ahead from where I stand.
This all contributes to create a very toxic subject that I generally tend to avoid, but I think that it's fair at this point to question Mozilla's execs results at this point. These past few years have been pretty brutal for Mozilla, and there's no clear path ahead from where I stand.
> good old sexism
The only comment mentioning her gender was someone defending her, you're pulling hair here
The only comment mentioning her gender was someone defending her, you're pulling hair here
yes because one can only be sexist by explicitly mentioning gender
This is encouraging. An Electron competitor would be really nice.
I'd be especially interested in an Electron-but-for-Python, along the lines of PythonWebkit: https://www.gnu.org/software/pythonwebkit/
I'd be especially interested in an Electron-but-for-Python, along the lines of PythonWebkit: https://www.gnu.org/software/pythonwebkit/
The rust electron competitor is already here https://tauri.studio/en/
Interesting project as they seem to be tackling the same problem as the Flutter team whom started with mobile and are steadily working their way up the stack.
Though it should be said repurposing a desktop first framework for a mobile paradigm is much harder than the inverse.
Cheers for this. Definitely keeping tabs on the project.
Though it should be said repurposing a desktop first framework for a mobile paradigm is much harder than the inverse.
Cheers for this. Definitely keeping tabs on the project.
Flutter does seem super cool. I agree with you too about it being easier to focus on mobile first.
The problem is the ecosystem is small. If your use case doesn't fit their widgets, you have to do a lot of workaround stuff.
Although this app stands out as a success in my mind: https://fluffychat.im/en/
The problem is the ecosystem is small. If your use case doesn't fit their widgets, you have to do a lot of workaround stuff.
Although this app stands out as a success in my mind: https://fluffychat.im/en/
Nice!
Okay, so now I want Tauri-but-for-Python.
Okay, so now I want Tauri-but-for-Python.
The Electron competitor is called the Web platform.
Just write your application in Django and start the local browser. Use Web APIs to trigger interactions with native APIs from Python code.
Just write your application in Django and start the local browser. Use Web APIs to trigger interactions with native APIs from Python code.
Okay, so I'm curious as to why you think desktop applications are ever built as Electron apps rather than just as a local web app server that opens the desktop browser?
After all, that approach was pioneered by Dave Winer around 2000 or so, and never really caught on. On the other hand, Electron has exploded as a platform.
After all, that approach was pioneered by Dave Winer around 2000 or so, and never really caught on. On the other hand, Electron has exploded as a platform.
Because of lazy devs stuck into worshiping Chrome.
Using daemons implies actually knowing the underlying platforms and writing proper cross browser applications.
Using daemons implies actually knowing the underlying platforms and writing proper cross browser applications.
Umm. You're basically implying that all desktop developers are lazy.
There ought to be some desktop developers who see the advantages of your preferred solution, where are they, and where are their apps?
There ought to be some desktop developers who see the advantages of your preferred solution, where are they, and where are their apps?
Those using Electron aren't desktop developers, so no I am to implying that all desktop developers are lazy.
Thankfully Electron is just a tiny percentage of apps that with exception of VSCode and Slack I can abstain myself from ever touching, with plenty of native or proper Web alternatives that don't augment the hegemony of ChromeOS.
As for examples with daemons using Web GUIs, ever heard of CUPS and SharePoint?
Thankfully Electron is just a tiny percentage of apps that with exception of VSCode and Slack I can abstain myself from ever touching, with plenty of native or proper Web alternatives that don't augment the hegemony of ChromeOS.
As for examples with daemons using Web GUIs, ever heard of CUPS and SharePoint?
> Those using Electron aren't desktop developers,
I think you are getting into "No True Scotsman" territory here.
> ever heard of CUPS and SharePoint?
I haven't messed with either in quite a while, but are the use-cases for those UIs supposed to be from the same machine serving them (ie. a desktop app equivalent), rather than over the network?
I think you are getting into "No True Scotsman" territory here.
> ever heard of CUPS and SharePoint?
I haven't messed with either in quite a while, but are the use-cases for those UIs supposed to be from the same machine serving them (ie. a desktop app equivalent), rather than over the network?
> or donating to help cover the project’s new CI and hosting costs,
Planning to do exactly that tonight.
I'm one of those who stopped donating to Mozilla once I realized none of the money donated could ever be used for developing the browser.
If anybody else thought like me tonight might be a good time to prove we were principled, not cheap.
Edit: one more thing. Hopefully at some time we can now recreate Firefox with a new name, a new engine and a new, safe but also complete extension API that allows us to recreate what we've lost over the last few years.
Edit2: done.
Planning to do exactly that tonight.
I'm one of those who stopped donating to Mozilla once I realized none of the money donated could ever be used for developing the browser.
If anybody else thought like me tonight might be a good time to prove we were principled, not cheap.
Edit: one more thing. Hopefully at some time we can now recreate Firefox with a new name, a new engine and a new, safe but also complete extension API that allows us to recreate what we've lost over the last few years.
Edit2: done.
I’m not in a position to donate right now, so thanks a lot for donating to this project.
Though I do wonder how much influence Servo will have on preventing browser monoculture given that as a stand-alone thing it can’t be or isn’t involved in developing standards. Mozilla will still have to play that role. I hope they step up to the plate and stay focused on this most important thing.
Though I do wonder how much influence Servo will have on preventing browser monoculture given that as a stand-alone thing it can’t be or isn’t involved in developing standards. Mozilla will still have to play that role. I hope they step up to the plate and stay focused on this most important thing.
> I’m not in a position to donate right now, so thanks a lot for donating to this project.
I've been there myself for years.
I'm happy to now be in a position not even have to think to donate tonight.
Hopefully you too will get there soon too!
Edit: and thanks for your contributions to netty and graphql-java!
I've been there myself for years.
I'm happy to now be in a position not even have to think to donate tonight.
Hopefully you too will get there soon too!
Edit: and thanks for your contributions to netty and graphql-java!
Thanks a lot! Hope I will too :).
Yep, I threw them $10 -- it was pretty easy (there was some strange scrolling problem on the first page, but I just hit the donate button and it went away) https://crowdfunding.lfx.linuxfoundation.org/projects/servo
Do we really have to created an account to donate ?
I donate to Blender from time to time and I like how they just put an IBAN on their donation page ( https://www.blender.org/foundation/donation-payment/ )
I copy paste the IBAN in my e-banking app, send, done.
Why here do I have to read pages and pages of privacy policy, create an account, give my email, etc.
I donate to Blender from time to time and I like how they just put an IBAN on their donation page ( https://www.blender.org/foundation/donation-payment/ )
I copy paste the IBAN in my e-banking app, send, done.
Why here do I have to read pages and pages of privacy policy, create an account, give my email, etc.
> I'm one of those who stopped donating to Mozilla once I realized none of the money donated could ever be used for developing the browser.
I never donated to Mozilla for this precise reason. Now I'm seriously considering it.
Edit: Done
I never donated to Mozilla for this precise reason. Now I'm seriously considering it.
Edit: Done
The irony is that from both of these comments it implies you have a concern about the future and the stability of Firefox as both an open source project, and it's role in preventing a browser monoculture.
Setting aside concerns about leadership, because IMO it's time for most of the current leadership to retire and make space for more innovative folks, Mozilla needs two things to preserve Firefox and Gecko, money and relevance. The have had numerous misfires on diversifying revenue, and they have been challenged on how to do that for a long time, but MoCo (Mozilla Corporation) has been profitable for quite some time due to the business deals with Google. That funds Firefox and many other related projects.
The other thing that Mozilla needs is relevance, and over and above the presence of Firefox, MoFo (Mozilla Foundation) has played an activist role across many different initiatives, standards bodies, and lobbying. That requires money, and because of the legal manoeuvring that Mozilla has done in structuring MoFo and MoCo it requires that Mozilla Foundation be largely self-funding.
Donations help with that, and pay for relevance in a way that Firefox alone can't. Please rethink the hostility towards donating to Mozilla Foundation.
Setting aside concerns about leadership, because IMO it's time for most of the current leadership to retire and make space for more innovative folks, Mozilla needs two things to preserve Firefox and Gecko, money and relevance. The have had numerous misfires on diversifying revenue, and they have been challenged on how to do that for a long time, but MoCo (Mozilla Corporation) has been profitable for quite some time due to the business deals with Google. That funds Firefox and many other related projects.
The other thing that Mozilla needs is relevance, and over and above the presence of Firefox, MoFo (Mozilla Foundation) has played an activist role across many different initiatives, standards bodies, and lobbying. That requires money, and because of the legal manoeuvring that Mozilla has done in structuring MoFo and MoCo it requires that Mozilla Foundation be largely self-funding.
Donations help with that, and pay for relevance in a way that Firefox alone can't. Please rethink the hostility towards donating to Mozilla Foundation.
>> Please rethink the hostility towards donating to Mozilla Foundation
Once Mozilla rethink;s its hostility to its user base maybe the user base will rethink its hostility towards Mozilla
Mozilla left us, we did not leave Mozilla
Once Mozilla rethink;s its hostility to its user base maybe the user base will rethink its hostility towards Mozilla
Mozilla left us, we did not leave Mozilla
I don't see any irony there; people care about firefox, and there is literally no way to donate money to develop firefox. Maybe donating to the foundation sorta indirectly helps firefox, but a reasonable person could easily view them as mostly unrelated.
Sure, you can donate money to develop Firefox, but it's not a core part of Mozilla's business model to support that. Instead you would need to track down an OSS developer that is either an active contributor, or who is willing to work on Firefox, and then sponsor their work through a number of different contributor pathways. There are Github sponsorships, direct funding, or any of the options here - https://itsfoss.com/open-source-funding-platforms/
It's not easy because supporting open source contributors is hard, and Mozilla is trying to keep their staff focused on corporate and foundation priorities.
Even if users could directly donate money to develop Firefox, the implication is that any such donations should only be used for Firefox development, when in practice, shipping a modern browser in a way that is competitive requires an enormous amount of non-"Firefox" related work (safe browsing, sync, telemetry, marketing ,release engineering work, advocacy, documentation, etc, etc, etc). Earmarking donations for engineering work is kind of silly in the context of an OSS project designed to compete with some of the largest juggernauts in the industry.
It's not easy because supporting open source contributors is hard, and Mozilla is trying to keep their staff focused on corporate and foundation priorities.
Even if users could directly donate money to develop Firefox, the implication is that any such donations should only be used for Firefox development, when in practice, shipping a modern browser in a way that is competitive requires an enormous amount of non-"Firefox" related work (safe browsing, sync, telemetry, marketing ,release engineering work, advocacy, documentation, etc, etc, etc). Earmarking donations for engineering work is kind of silly in the context of an OSS project designed to compete with some of the largest juggernauts in the industry.
> Sure, you can donate money to develop Firefox,
My understanding:
I'm fairly sure they've said they are not allowed to direct money from the Foundation to Mozilla Corporation, and it kind of makes sense until you realize it is the coroporation that creates the outcome you want not the other way around.
Also - from my point of view it looks like the Foundation is overfunded the last few years while the guys who create Firefox are underfunded, but I'm not an expert so it might very well be more complicated.
I also don't want to say Mozillas management are useless: they somehow managed to land a huge deal earlier this year, but I will admit I sometimes find some of their decisions puzzling.
My understanding:
I'm fairly sure they've said they are not allowed to direct money from the Foundation to Mozilla Corporation, and it kind of makes sense until you realize it is the coroporation that creates the outcome you want not the other way around.
Also - from my point of view it looks like the Foundation is overfunded the last few years while the guys who create Firefox are underfunded, but I'm not an expert so it might very well be more complicated.
I also don't want to say Mozillas management are useless: they somehow managed to land a huge deal earlier this year, but I will admit I sometimes find some of their decisions puzzling.
You are correct; you can't direct money to Mozilla to develop Firefox, by way of the foundation. You can fund OSS contributors, not Mozilla staff (and they are well funded already, to work on Firefox).
There are consulting companies that do OSS development on web related projects, Igalia is probably the closest one, or maybe Collabora.
https://www.igalia.com/ https://www.collabora.com/
https://www.igalia.com/ https://www.collabora.com/
Donations to a corrupt organization helps to make it even more corrupt. Just look at any destroyed country where ,,outside help'' is coming. Stopping the money flow is the only way to change corrupt management to people who care even if there's less money involved.
I suppose it depends on your definition of self-funding (or possibly of "largely"): the Foundation receives roughly half its total income from the Corporation, in the form of license fees for trademarks. Of course both figures are drops in the bucket compared to the Corporation's revenue. I don't know if that "half and half" nature is coincidence, an internal directive, or necessary to maintain their tax-exempt status, but it's pretty consistent.
For-profit entities can, of course, lobby and sit on standards bodies just fine. We certainly see plenty of that behavior from the other vendors.
I'm not saying the Foundation is worthless or that people shouldn't donate to it, just that they should know what they're paying for and what they're not.
For-profit entities can, of course, lobby and sit on standards bodies just fine. We certainly see plenty of that behavior from the other vendors.
I'm not saying the Foundation is worthless or that people shouldn't donate to it, just that they should know what they're paying for and what they're not.
If Mozilla were serious about Firefox and privacy, they'd move it to the Foundation, allow direct donations, remove all the Googleware, Pocket and whatever else they unnecessarily shoved into Firefox + all the problems you stated.
I'm not going to consider affirming bad leadership by giving them money. Mozilla Corp employees aren't locked into anything (unless they signed really shitty contracts). They can leave and rebuild.
Servo might finally provide the foundation for a browser that really is about privacy and not just a cash-cow for a bloated upper echelon.
I'm not going to consider affirming bad leadership by giving them money. Mozilla Corp employees aren't locked into anything (unless they signed really shitty contracts). They can leave and rebuild.
Servo might finally provide the foundation for a browser that really is about privacy and not just a cash-cow for a bloated upper echelon.
what googleware is in Firefox, and what impact does pocket have on your privacy?
Google is the default search engine of a "privacy aware" browser. It uses Google Safe browsing which, from what I understand, is practically an embedded call home to Google for each new domain you visit. For quite a while they were using Google as the default location provider.
Pocket was an unnecessary acquisition that wasted money for an opt-out solution to... I don't even know what problem. The money spent on acquiring it could've gone into more developers, technical writers, testers, etc. Clickz (or however it's written) was also an unnecessary fail investment.
Pocket was an unnecessary acquisition that wasted money for an opt-out solution to... I don't even know what problem. The money spent on acquiring it could've gone into more developers, technical writers, testers, etc. Clickz (or however it's written) was also an unnecessary fail investment.
So pocket in no way detracts from your privacy. It's an very useful feature to many people. It's fine if you don't like it, but to use the privacy argument against it is incredibly disingenuous.
Edit: Also, you understand incorrectly about safe browsing. It does its checks locally.
Edit: Also, you understand incorrectly about safe browsing. It does its checks locally.
I never claimed pocket detracted from privacy. I actually explained my problem with pocket... To add to that, it shouldn't be embedded in the browser. It's an extension and they have a marketplace for that.
And even if Safe Browsing does do what you say, the other google stuff still does and did exist.
And even if Safe Browsing does do what you say, the other google stuff still does and did exist.
> If Mozilla were serious about Firefox and privacy, they'd.. remove all the Pocket they unnecessarily shoved into Firefox
Even if you're backing down from that statement, why should it be an extension? why should they remove a popular feature and source of income just because you don't like it?
Yes Firefox will perform Google searches or location requests if you ask it to. It doesn't if you don't.
Even if you're backing down from that statement, why should it be an extension? why should they remove a popular feature and source of income just because you don't like it?
Yes Firefox will perform Google searches or location requests if you ask it to. It doesn't if you don't.
Servo is starting to remind me a little of Minix, where it is an ambitious project attempting to fix underlying architectural problems, but the scale of the project being so large that ecosystem progress outpaces it's ability to adapt. I hope I'm wrong.
That's a well-known problem unfortunately. http://doc.cat-v.org/bell_labs/utah2000/utah2000.html
To be a viable computer system, one must honor a huge list of large, and often changing, standards ... A huge amount of work, but if you don't honor the standards, you're marginalized. ... At another level, instruction architectures, buses, etc. have the same influence. With so much externally imposed structure, there's little slop left for novelty. Even worse, commercial companies that "own" standards, such as Microsoft and Cisco, deliberately make standards hard to comply with, to frustrate competition.
To be a viable computer system, one must honor a huge list of large, and often changing, standards ... A huge amount of work, but if you don't honor the standards, you're marginalized. ... At another level, instruction architectures, buses, etc. have the same influence. With so much externally imposed structure, there's little slop left for novelty. Even worse, commercial companies that "own" standards, such as Microsoft and Cisco, deliberately make standards hard to comply with, to frustrate competition.
This is fantastic news. Servo has been doing exciting work, and it was disappointing to hear that Mozilla had disbanded the Servo team. I'm really excited to see where this will go. Will improvements from Servo continue to make their way down into Firefox?
> Will improvements from Servo continue to make their way down into Firefox?
Unlikely.
Unlikely.
It's difficult to characterize this as inherently bad, though. We could end up with three competing engines and major browsers, plus a long tail of webkit browsers. That's a pretty decent scenario for the rest of us.
For all I know, Servo will go on to conquer the world.
However -- after surveying the comments here, I am left with a poignant sense that this launchpad project has already contributed way beyond its share of heavy lifting to shape and to popularize the rust programming language. Servo no longer needs to succeed in order for rust to win.
Back before multi-core x86 CPUs or the C10K paper came out, a unique engineer decided to show the world[0] how an event-driven web server could perform way better than the threaded web servers of the day. Nobody really uses thttpd in serious production work anymore, but its influence and example can be traced through Zeus web server, lighttpd, litespeed, and on to haproxy and nginx today.
[0] http://acme.com/software/thttpd/
However -- after surveying the comments here, I am left with a poignant sense that this launchpad project has already contributed way beyond its share of heavy lifting to shape and to popularize the rust programming language. Servo no longer needs to succeed in order for rust to win.
Back before multi-core x86 CPUs or the C10K paper came out, a unique engineer decided to show the world[0] how an event-driven web server could perform way better than the threaded web servers of the day. Nobody really uses thttpd in serious production work anymore, but its influence and example can be traced through Zeus web server, lighttpd, litespeed, and on to haproxy and nginx today.
[0] http://acme.com/software/thttpd/
The Linux Foundation. A place where projects which have nothing to do with Linux go off to die.
FWIW Mozilla gave up on producing an alternative browser engine years ago, much to the annoyance of its developers. The recently brought out one for Android aka GeckoView, but I doubt if any developers will have some interest in using it.
When Microsoft ports its new Chromium based WebView2 which is currently available on Windows to both desktop Linux and Android I doubt anyone will be interested in GeckoView any more. Mozilla's current role is to enable Google and Microsoft to point out to regulators that there are alternatives to their market dominance and gain some referral revenue in the process. The simple thing is no one is interested in an alternative browser engine from Mozilla because they gave up on that ages ago.
https://www.reddit.com/r/firefox/comments/ag0ug0/what_is_it_...
https://www.reddit.com/r/firefox/comments/9ugy1h/this_week_i...
https://www.reddit.com/r/firefox/comments/bld586/what_is_you...
https://www.reddit.com/r/programming/comments/akovnq/the_leg...
https://www.chrislord.net/2017/06/28/goodbye-mozilla/
FWIW Mozilla gave up on producing an alternative browser engine years ago, much to the annoyance of its developers. The recently brought out one for Android aka GeckoView, but I doubt if any developers will have some interest in using it.
When Microsoft ports its new Chromium based WebView2 which is currently available on Windows to both desktop Linux and Android I doubt anyone will be interested in GeckoView any more. Mozilla's current role is to enable Google and Microsoft to point out to regulators that there are alternatives to their market dominance and gain some referral revenue in the process. The simple thing is no one is interested in an alternative browser engine from Mozilla because they gave up on that ages ago.
https://www.reddit.com/r/firefox/comments/ag0ug0/what_is_it_...
https://www.reddit.com/r/firefox/comments/9ugy1h/this_week_i...
https://www.reddit.com/r/firefox/comments/bld586/what_is_you...
https://www.reddit.com/r/programming/comments/akovnq/the_leg...
https://www.chrislord.net/2017/06/28/goodbye-mozilla/
Is anyone paying Servo developers now? This is the real issue.
Many of us are looking for (or have found) dayjobs, but it's possible some folks may be open to contracting work on servo/etc. But nobody is being paid to work on servo right now.
Not at the moment. Help is welcome: https://servo.org/#support-and-donations :)
Does being part of the Linux Foundation mean financial support?
The project will be forming a funding membership charter, similar to other foundations in the LF like say GraphQL Foundation (https://foundation.graphql.org/members/) which will pool financial resources and ensure a sustainable long term home, if your company is interested in helping out, shoot an email to [email protected]
I don't know about the Linux foundation, but the Apache Foundation is where a lot of code goes to die...
Can Servo be used as an Electron replacement?
Not yet, there is an embedding API, but it's designed for embedding into native apps. Servo uses Spidermonkey rather than v8 as the JS engine, so integrating into the node ecosystem would be tricky. But it would be nice to see a JS-first runtime system built around Servo!
Could Servo use v8 as the JS engine?
I'd guess many Electron users don't care about the node.js parts at all, they simply choose electron because it's more popular than the alternatives like CEF.
Node has done a lot of work in defining a runtime outside of the browser. I'm guessing much of this work would need to be done with spidermonkey in order to match common functionality. It'd also help out an electron equivalent for gecko, too.
Some electron users are certainly take advantage of the features node.js provides. But others just want a html+js based UI on top of a local webserver written in their preferred language.
My ideal model would be having one piece of trusted javascript which works similar to web extensions which can control the window, trigger navigations, approve or deny permission requests by origins and can interact with the current web control. Any advanced integration with the host operating system would happen though the local webserver (which could be implemented in node.js if that's your thing, or in C#, Rust...). This would not require many changes to a browser runtime.
My ideal model would be having one piece of trusted javascript which works similar to web extensions which can control the window, trigger navigations, approve or deny permission requests by origins and can interact with the current web control. Any advanced integration with the host operating system would happen though the local webserver (which could be implemented in node.js if that's your thing, or in C#, Rust...). This would not require many changes to a browser runtime.
Could be awesome! But it would need a JS engine.
Why would it, though? Any language should do, as long as you can package a runtime for the environment.
Be it lisp, WASM, plain old C... It's just functions to call, that change the DOM, CSS properties, load pages, perform computations, call APIs...
Of course, the thing you lose is the hardware and software abstraction layer provided by chromium's javascript APIs. Those could be exported to a select number of languages, it wouldn't be hard for a single dev to create a usable runtime in their language if they are provided with C bindings to the H/SAL...
Be it lisp, WASM, plain old C... It's just functions to call, that change the DOM, CSS properties, load pages, perform computations, call APIs...
Of course, the thing you lose is the hardware and software abstraction layer provided by chromium's javascript APIs. Those could be exported to a select number of languages, it wouldn't be hard for a single dev to create a usable runtime in their language if they are provided with C bindings to the H/SAL...
Thanks, is there a public Servo C API with function calls to change the DOM?
That's the spirit!
Those are exciting news. Both for Rust and for the project -- I think that's a really cool direction. The web becomes more and more a commodity to execute code remotely, and I think this step will help leverage Website-as-Interface as the default GUI for our programs, and empower us to commoditize it even more. And the Linux Foundation is a very lovely home -- they're dedicated to open standards and great stewards. However, complete lack of talk about funding and "every bit helps" makes it sound like this is actually the death of commercial support for this project. And I think it's super sad that Mozilla can't fund it anymore and would've hoped someone else would have picked up the banner monetarily. Does anyone know if the project has a good chance of survival (Rust is a great dev community, but might alienate broader adoption) -- can this survive purely within the open source community?
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.
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.
UWP now has first-class Rust bindings.
You missed Android. Firefox for mobile is so far behind Chrome, it’s unusable for me, most plugins don’t work.
I would vote for HTML/CSS based browser (React / React Native?), though I know that a lot of operating system specific code needs to be written.
I would vote for HTML/CSS based browser (React / React Native?), though I know that a lot of operating system specific code needs to be written.
The C API has JNI bindings, which is relevant to Android. https://github.com/servo/servo/tree/master/ports/libsimplese...
I find Firefox more usable than Chrome on Android. uBlock Origin works perfectly, and that's part of the reason.
I tried to install Google Translate extension and it was not supported. So when I have to choose between Google Translate or adblocking, it's already bad for me, as I like to use both of them on the PC.
I use kiwi which provide uBlock Origin for chromium
Chrome on Android doesn't even have plugins and never will.
You can with e.g kiwi browser
https://azul.rs/ Maybe?
Neat! Thanks for this!
I'm not sure azul is being actively developed any more; the repo looks a bit tumbleweedy.
The best place if you want to keep tabs on this area is probably https://www.areweguiyet.com/
The best place if you want to keep tabs on this area is probably https://www.areweguiyet.com/
Awesome news! The world needs another prominent browser engine that browser vendors would want to use, and detaching Servo from Mozilla makes it better positioned for that task IMHO. I'm also very happy that work on Webrender continues. I love what you're doing guys!
For what it’s worth, these days WebRender is mostly being worked on by the Firefox graphics team at Mozilla.
As long as it still works for both!
Should we start calling it Servo by Linux now?
Servo Rust Kernel™ ... coming soon to a hacked up Linux kernel near you.
What's the connection to Linux?
The Linux Foundation is a legal and fiscal host for many projects, not just the kernel: https://www.linuxfoundation.org/projects/
It's now part of the Linux Foundation.
(through that's all there is to it, calling it "by Linux" would still be misguided I think as the foundation is named after Linux and not the other way around)
(through that's all there is to it, calling it "by Linux" would still be misguided I think as the foundation is named after Linux and not the other way around)
The Linux Foundation ?
I haven’t been following Servo closely for the last few years (I’d looked at it during its early days). I recall that parts of it were already integrated into Firefox, but could someone state what percentage of the Firefox engine is based out of Servo and what the roadmap is for bringing Servo to a stage where it could almost replace Gecko? Does this new home for Servo (and detachment from Mozilla) still mean that Firefox would continue to aim to use it?
Tangentially, what’s the headless browser space with Firefox at the core looking like? When would it be able to provide something like Electron (possibly without being such a RAM hungry piece of software)?
Tangentially, what’s the headless browser space with Firefox at the core looking like? When would it be able to provide something like Electron (possibly without being such a RAM hungry piece of software)?
FF is using the CSS engine (Stylo) and rendering engine (WebRender) from Servo. Webcompat is certainly on our radar!
On the surface, this seems like great news.
Does anyone have any insight into what level of influence Linux Foundation's Platinum Corporate Members have over it's priorities and direction?
Beyond the obvious (Google), MS are invested in Blink and Tencent/QQ in Webkit. I guess there's scope for branching out in terms of engine use but... MS have already tried that quite a lot.
I'm not saying that it's necessary for all Foundation Corporate Members to be actively adopting Foundation projects, but more that some may have commercial interest in those projects not competing with their own.
Does anyone have any insight into what level of influence Linux Foundation's Platinum Corporate Members have over it's priorities and direction?
Beyond the obvious (Google), MS are invested in Blink and Tencent/QQ in Webkit. I guess there's scope for branching out in terms of engine use but... MS have already tried that quite a lot.
I'm not saying that it's necessary for all Foundation Corporate Members to be actively adopting Foundation projects, but more that some may have commercial interest in those projects not competing with their own.
Setting priorities and direction is the responsibility of the Technical Steering Committee: https://servo.org/governance/
The plan is to later have a Board responsible for financial decisions. Paid sponsorship to Servo (not just to LF) can grant a seat on the Board but not on the TSC.
The plan is to later have a Board responsible for financial decisions. Paid sponsorship to Servo (not just to LF) can grant a seat on the Board but not on the TSC.
Any servo developers arround ? I remember reading that a lot of CSS layout problems stem from having to support legacy stuff like floats etc that complicates reflow etc.
Would it be possible to create a rendering path that just supports flexbox/grid and stuff that's not performance limiting ?
This wouldn't be great for existing websites but it would be amazing if you had a CSS "strict mode" for electron like apps and new content.
Stoked this project isn't dead and isn't tied to Mozilla, I like lsf much more.
Would it be possible to create a rendering path that just supports flexbox/grid and stuff that's not performance limiting ?
This wouldn't be great for existing websites but it would be amazing if you had a CSS "strict mode" for electron like apps and new content.
Stoked this project isn't dead and isn't tied to Mozilla, I like lsf much more.
Not the same but css: contain is a quite revolutionary strict mode, performance-wise
How about making a browser in addition to a "rendering engine for embedding in other applications", in the form of a standalone program and/or a Firefox (desktop and mobile) fork that can use Servo as well as Gecko?
You could also go for the more ambitious plan of creating a brand that can take over Mozilla as a "trusted browser maker", which seems feasible given the falling reputation of Mozilla and the technical security advantages of Servo.
You could also go for the more ambitious plan of creating a brand that can take over Mozilla as a "trusted browser maker", which seems feasible given the falling reputation of Mozilla and the technical security advantages of Servo.
You first need a regarding engine to write a browser just doing a embedded html rendering engine is a lot of work so it's a good idea to start with a more viable/reachable goal and then if viable expand to a bigger goal.
the fact that you can now donate directly to Servo is fantastic.
before, a donation for Firefox or Servo was just a donation to the Mozilla Foundation, which probably went to Mozilla's unrelated monetization efforts rather than the thing you intended.
https://crowdfunding.lfx.linuxfoundation.org/projects/servo
before, a donation for Firefox or Servo was just a donation to the Mozilla Foundation, which probably went to Mozilla's unrelated monetization efforts rather than the thing you intended.
https://crowdfunding.lfx.linuxfoundation.org/projects/servo
Edit: It's clear to me Servo is vaporware right now. The discussions in this thread and crawling servo.org make that abundantly clear.
Original post: As an embedder, I just don't get the point. Servo is a nonstarter. The idea of Servo minus Rust is great, because most embedders don't use Rust. They use C, because C is easy to embed with, and the availability of FFIs across languages that interface with C is tremendous.
As someone who has used CEF, looked at Webkit ports, and has even written a compositor compliant with a subset of CSS 2.1, you just cannot sell Servo to me without a C interface.
My problem isn't, "I need an embeddable web browser written in Rust." My problem is I need any embeddable web software―at least a CSS 2.1 compliant compositor―as an alternative to CEF accessible through C, C++, or an FFI that talks to C, but almost no one makes one.
I don't even necessarily need anything beyond a CSS 2.1 compositor, because so much of "web development" is either CSS 2.1 or JavaScript, and I don't need the latter for my embedding purposes.
Original post: As an embedder, I just don't get the point. Servo is a nonstarter. The idea of Servo minus Rust is great, because most embedders don't use Rust. They use C, because C is easy to embed with, and the availability of FFIs across languages that interface with C is tremendous.
As someone who has used CEF, looked at Webkit ports, and has even written a compositor compliant with a subset of CSS 2.1, you just cannot sell Servo to me without a C interface.
My problem isn't, "I need an embeddable web browser written in Rust." My problem is I need any embeddable web software―at least a CSS 2.1 compliant compositor―as an alternative to CEF accessible through C, C++, or an FFI that talks to C, but almost no one makes one.
I don't even necessarily need anything beyond a CSS 2.1 compositor, because so much of "web development" is either CSS 2.1 or JavaScript, and I don't need the latter for my embedding purposes.
Servo already has a C embedding API in https://github.com/servo/servo/tree/master/ports/libsimplese....
That's not an embedding API. It's definitely Rust exposed to C, but there's nothing meaningful there as an embedder to get started.
Reading code isn't reading documentation. The fact that someone on HN had to search for it and paste it here tells me enough about where they emphasize their time.
Reading code isn't reading documentation. The fact that someone on HN had to search for it and paste it here tells me enough about where they emphasize their time.
Rust has the ability to expose a C API. So, I don't see it as a non-starter.
It's just that no one bothered to expose it.
EDIT: I'm wrong, but I do think the documentation isn't that great.
https://github.com/servo/servo/tree/master/ports/libsimplese...
https://github.com/paulrouget/servo-embedding-example
It's just that no one bothered to expose it.
EDIT: I'm wrong, but I do think the documentation isn't that great.
https://github.com/servo/servo/tree/master/ports/libsimplese...
https://github.com/paulrouget/servo-embedding-example
> It's just that no one bothered to expose it.
Almost the entire quick start guide is about using Rust. So you know, if I want to embed it, how do I do it?
If I need a view offscreen rendered to a framebuffer, how do I get it? Can I blit? If so, how? How do I pass events to the browser abstraction?
Servo talks about none of these things and leaves it up to you, but 110% emphasizes everything possible about Rust.
I don't care about Rust, I care about embedding web technologies. So how do I do it? They don't explain.
The front page prioritizes these things, in this order:
Maybe they should spent more time catering to the people they claim to be providing the software for and less to the Rust crowd.
Almost the entire quick start guide is about using Rust. So you know, if I want to embed it, how do I do it?
If I need a view offscreen rendered to a framebuffer, how do I get it? Can I blit? If so, how? How do I pass events to the browser abstraction?
Servo talks about none of these things and leaves it up to you, but 110% emphasizes everything possible about Rust.
I don't care about Rust, I care about embedding web technologies. So how do I do it? They don't explain.
The front page prioritizes these things, in this order:
* How to use Rust
* How to contribute to Servo
* Servo's blog
* How Servo is governed
* How to donate to Servo
* Contacting those involved with Servo
* Downloading Servo
Maybe they should spent more time catering to the people they claim to be providing the software for and less to the Rust crowd.
Having looked at it more, it seems servo does expose C API. The part I was working on doesn't.
Anyway servo comes with libservo and libservosimple. Admittedly they don't seem to be well documented for people coming from C world.
Perhaps you might want to comment on raise an issue for Servo?
I haven't worked on it in quite a while.
Anyway servo comes with libservo and libservosimple. Admittedly they don't seem to be well documented for people coming from C world.
Perhaps you might want to comment on raise an issue for Servo?
I haven't worked on it in quite a while.
Why would I ask people working on embeddable web technologies how to embed their software? They should just tell me. I don't care that there's 19 people on their "technical steering committee" if not a single one of those 19 people is responsible for actual adoption.
If they don't have a getting started guide for people like me to actually embed and use the software it's a waste of my time and hypeware or vaporware depending on how you want to look at it.
18k stars and I know there aren't 18k embedders out there.
If they don't have a getting started guide for people like me to actually embed and use the software it's a waste of my time and hypeware or vaporware depending on how you want to look at it.
18k stars and I know there aren't 18k embedders out there.
Servo is a WIP. Some components are mature, and have actually been merged into firefox.
Embedding is a primary aim, but certainly requires a lot of wrapping at present to be as functional as more mature engines.
No doubt it would be nice to have an easily portable lib - maybe with a compatible interface to other engines - but its certainly not there yet.
I agree that the project could/should be a bit clearer on its current status.
Embedding is a primary aim, but certainly requires a lot of wrapping at present to be as functional as more mature engines.
No doubt it would be nice to have an easily portable lib - maybe with a compatible interface to other engines - but its certainly not there yet.
I agree that the project could/should be a bit clearer on its current status.
Servo has been around for 8 years. If embedding was a primary aim, which it clearly isn’t, you’d start with that first, and enjoy spec compliance updates as they came.
As I stated, it IS embeddable. It just isn’t as user friendly as the off-the-shelf libs you mention you are familiar with.
I’m really not understanding your hate. Servo is a WIP. If you don’t have the time/skills to embed it in its current state, then don’t! But it’s still embeddable :)
I’m really not understanding your hate. Servo is a WIP. If you don’t have the time/skills to embed it in its current state, then don’t! But it’s still embeddable :)
You're right, I should take a look at all the great apps using Servo to figure out how to use it myself.
On the face of it, this sounds great! I hope it leads to bold new things.
It also produces an interesting coherence:
Google + MS -> Blink
Apple -> Webkit
Linux -> Servo
All the main OSs now have their own web rendering engine.
The 00s saw anti-trust against MS for this practice (ok, for the rigid way MS forced their engine onto their users)... but today the market has coalesced around the same core idea, cementing the notion that general purpose OSs need a web rendering engine.
Might this pave the way for a better cross-platform UI development? Rather than shipping Electron to every device for every app, apps might leverage the web renderer tied to the OS?
I'm just wondering out loud. I was actually hoping we'd collectively move back towards native apps with better cross-platform tools, rather than integrating web apps deeper into OSs (even tho' I'm a web developer by trade and stand to gain from this).
It also produces an interesting coherence:
Google + MS -> Blink
Apple -> Webkit
Linux -> Servo
All the main OSs now have their own web rendering engine.
The 00s saw anti-trust against MS for this practice (ok, for the rigid way MS forced their engine onto their users)... but today the market has coalesced around the same core idea, cementing the notion that general purpose OSs need a web rendering engine.
Might this pave the way for a better cross-platform UI development? Rather than shipping Electron to every device for every app, apps might leverage the web renderer tied to the OS?
I'm just wondering out loud. I was actually hoping we'd collectively move back towards native apps with better cross-platform tools, rather than integrating web apps deeper into OSs (even tho' I'm a web developer by trade and stand to gain from this).
The Linux Foundation is basically a catch-all foundation for smaller open source projects, this is not "Linux owns a browser engine".
The "Linux" there is more of an indicator of its origins than its purpose.
The "Linux" there is more of an indicator of its origins than its purpose.
Thanks for the clarification.
Despite the name the Linux kernel is only one of many projects hosted by the Linux Foundation these days. Browser engine to operating system relationships haven’t changed with this move.
So feel free to correct me if you think I'm wrong.
I thought the biggest draw to Electron was that it was a single stable platform that worked and looked the same everywhere.
I feel like (based on that) any attempts to move to OS bundled web engines would completely miss the point of why Electron is popular.
I thought the biggest draw to Electron was that it was a single stable platform that worked and looked the same everywhere.
I feel like (based on that) any attempts to move to OS bundled web engines would completely miss the point of why Electron is popular.
I think the biggest advantage of Electron is that you can write one code and it will run on all major desktop platforms AND web. There isn't really any other good solution for this.
> I feel like (based on that) any attempts to move to OS bundled web engines would completely miss the point of why Electron is popular.
If the web platform is modern enough (chrome, firefox and mayybe safari) then supporting these different platforms is not that difficult.
> I feel like (based on that) any attempts to move to OS bundled web engines would completely miss the point of why Electron is popular.
If the web platform is modern enough (chrome, firefox and mayybe safari) then supporting these different platforms is not that difficult.
Not difficult no.
But certainly not anywhere close to the 0 extra effort required by an app developer to support other platforms with Electron as it currently is.
But certainly not anywhere close to the 0 extra effort required by an app developer to support other platforms with Electron as it currently is.
Haven't heard of Servo before so was excited about the possibility of a lean new engine, but was pretty deflated when the preview build is 200Mb+ on disk (80Mb just for the main exe). It's possible some of it comes from the unoptimized extras like the JS engine, media libraries, etc.
I don’t recall that disk size was ever something we’ve optimized or tracked. Why is it important?
> I don’t recall that disk size was ever something we’ve optimized or tracked. Why is it important?
If you're targeting application developers, minimizing the system requirements (including size-on-disk) for an installed app that embeds Servo is going to matter.
I don't know how much it matters, though.
If you're targeting application developers, minimizing the system requirements (including size-on-disk) for an installed app that embeds Servo is going to matter.
I don't know how much it matters, though.
Other resources' usage (memory, I/O) tends to scale up with size on disk. And empirically, the more code you have, the slower your program runs.
Lots of folks in this thread brought up Electron and Servo being a potential replacement for it, but the preview build is already larger than Electron today.
Lots of folks in this thread brought up Electron and Servo being a potential replacement for it, but the preview build is already larger than Electron today.
Is there a chance the Servo code base could be used to develop a new browser? You know, like phoenix rising from the ashes much like FF rose from the Netscape code base (wasn't FF even called phoenix at some point)? Because that's certainly something to get HNers behind.
Of course, but they won't be working on it.
While this is great news on one hand, on the other hand, how could Mozilla manage to lose its browser engine project ? If a web browser company can't even keep its browser engine project, what is really Mozilla working on these days ?
Mozilla is still obviously working on Gecko, which is the browser engine powering Firefox. You can check the activity here for instance: https://github.com/mozilla/gecko-dev
A VPN service, apparently.
https://vpn.mozilla.org
https://vpn.mozilla.org
Reselling Mullvad, last I heard... Has that changed?
It's really a classic situation, the greenfield project is stopped and the historical "old" project keeps going on.
Servo wasn't a Gecko replacement. It was rather "2nd biggest rust project" and a place to work on thing that might end up in firefox.
That's it. Firefox already has big chunks of Servo inside, those aren't going anywhere - without them firefox will be slow again.
That's it. Firefox already has big chunks of Servo inside, those aren't going anywhere - without them firefox will be slow again.
[deleted]
Is WebGPU part of Servo? I know the guys at Mozilla were developing WebGPU API in Rust. Looking to see where it's going (I assume Firefox has to use it too. Chrome already has experimental support)
Any idea?
Any idea?
No, separate project, although both Servo and Gecko (the C++ Firefox codebase) are aiming to use it.
This diagram [1] kvark posted the other day might help. (I think dotted-outline boxes indicate external components, but couldn't swear to it.)
[1] https://gfx-rs.github.io/2020/11/16/big-picture.html
This diagram [1] kvark posted the other day might help. (I think dotted-outline boxes indicate external components, but couldn't swear to it.)
[1] https://gfx-rs.github.io/2020/11/16/big-picture.html
The wgpu crate is being developed by Firefox engineers for Firefox. As lastontheboat said we had a student integrate it into Servo this year.
We had a summer of code student implementing support in Servo: https://blog.servo.org/2020/08/30/gsoc-webgpu/
Excellent news. Thank you!!
Is Servo planning to get back to the whole "writing a web rendering engine" part, and backburner the "let's play around with VR and stuff" plans? Because until then, I don't think Servo is especially interesting as a project. As far as I can tell, the last few years of Servo have been characterized by an obsession with chasing shiny things, and not with the kind of rigid and dedicated engineering efforts necessary to write a new web engine.
We spent a significant amount of effort in the last year and a half working on a redesigned modular/parallel layout subsystem.
The VR focus was because it was a good way to get servo out to end users early without needing to be fully web compat -- WebXR doesn't require complex layout. We didn't drop our focus on full web compat during this, but full web compat has always been a more long term goal given how complex the web platform is.
The VR focus was because it was a good way to get servo out to end users early without needing to be fully web compat -- WebXR doesn't require complex layout. We didn't drop our focus on full web compat during this, but full web compat has always been a more long term goal given how complex the web platform is.
WebXR is also completely inane. What users are you "shipping" to? A tenth of a tenth of a tenth of a tenth of a percent of internet users?
You have a massive effort ahead of you, and you won't get there by chasing distractions. You need to have a singular focus if you're going to accomplish this goal.
You have a massive effort ahead of you, and you won't get there by chasing distractions. You need to have a singular focus if you're going to accomplish this goal.
They're not interested in "[providing] an independent, modular, embeddable web engine," they're interested in writing software in Rust and having their name associated with a Mozilla/Linux Foundation project. Go look at their governance.[1]
Their webpage tells you what they really care about, and it isn't embedding.
[1]: https://servo.org/governance/tsc/readme/
Their webpage tells you what they really care about, and it isn't embedding.
[1]: https://servo.org/governance/tsc/readme/
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.
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.
ddevault(1)
I wish servo would adopt a more permissive license, something like MIT or BSD instead of MPL. I think that existing projects like chromium have a competitive advantage because they have permissive licenses. If the community around servo would like to see more projects like electron built around servo they should consider it.
MPL is a perfectly fine license. It has most of the benefits of permissive licenses (non-virality, worry-free integration with proprietary code) with most of the benefits of copyleft licenses also (changes to the library itself must be public).
I fail to see what benefits a more permissive license would bring.
I fail to see what benefits a more permissive license would bring.
I have read this claim many times and yet to see any empirical evidence to back it up. If this license really hit the “sweet spot" between GPL and MIT/BSD then why haven't other projects outside of Mozilla funded projects adopted it. I think the reality is just the opposite. It neither gives the impression to contributors that their contributions are "protected" nor does it give lisensees the comfort that they will not accidentally run afoul of it's terms.
For one, the MIT/BSD/GPL licenses are all between 30-40 years old, whereas the MPL is only 8 years old. So that's 4x younger.
For another, Mozilla has never really tried to "market" the license. It's hard to make something gain traction if you don't really try.
And then nobody really cares that much about licensing so if something is "good enough" and does what they want it to then they're going to stick to it. Especially if it means they get to avoid doing research about licenses.
And people that do really care about licenses tend to fall into camp permissive or camp copyleft with not a whole lot of in-between.
For another, Mozilla has never really tried to "market" the license. It's hard to make something gain traction if you don't really try.
And then nobody really cares that much about licensing so if something is "good enough" and does what they want it to then they're going to stick to it. Especially if it means they get to avoid doing research about licenses.
And people that do really care about licenses tend to fall into camp permissive or camp copyleft with not a whole lot of in-between.
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, and extending it with subclasses or traits is OK, as long as any modifications made to the original library itself are made available. And there is no limitations on linking proprietary libraries from MPLv2 code as there is with (L)GPL.
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, and extending it with subclasses or traits is OK, as long as any modifications made to the original library itself are made available. And there is no limitations on linking proprietary libraries from MPLv2 code as there is with (L)GPL.
Thank God, I am so happy to hear that Servo isn't being abandoned, and I'm very happy to see the Linux foundation getting involved.
It's still going to be an uphill battle for Servo to really make an impact on the overall browser/web industry/ecosystem, but at least for now this is very positive news.
It's still going to be an uphill battle for Servo to really make an impact on the overall browser/web industry/ecosystem, but at least for now this is very positive news.
This is great news! Really nice to see another browser engine out there being developed. Hope to be able to use this in a project one day in the future and all the best to the team - quite a feat how far Servo has come in supporting web standards in such a short span of time (comparatively).
Overjoyed to see this, and best wishes to the team. Looking forward to seeing the future of Servo, and possibly contributing.
I see Servo as a great Electron alternative. And I think eventually it could become a browser, though I understand that at least as of a few months ago that wasn't the plan.
I see Servo as a great Electron alternative. And I think eventually it could become a browser, though I understand that at least as of a few months ago that wasn't the plan.
Happy to hear that Servo lives on! Anyone knows if Firefox Lite will be rescued too, now that the FF Lite team has been laid off as well?
I don't wanna be that guy but can we stop with all the namespace conflicts.
seems like a great step for Rust adoption in the Linux community!
We are seeing the birth of a new browser ( age )
Mozilla -> Linux Foundation -> Graveyard
Very good news for Rust.
open up 'cause here I come (yes I am)
[deleted]
[deleted]