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.
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.
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.
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.
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++.
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
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.
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.
Hey, please don't be a jerk in HN comments. If you know more than others, that's great, but the thing to do is to share some of what you know so the rest of us can learn something. If you don't want to do that, not posting anything is always an option. But please don't post unsubstantive comments and especially not nasty unsubstantive comments.
I didn't mean that all of your posts were that way, only some of them.
Can I try my luck at persuading you a little? The reason we moderate like this is not because of morality or taste. It's because of the dynamics of a community of HN's size. The goal is simply to have a community that doesn't suck. That is in all our interests, including yours, as you're participating here.
There are other internet communities, smaller and more cohesive ones, and usually with a specific technical focus, that have a culture of shaming people for being wrong or knowing less. Arguably this can help to keep signal/noise ratio high by punishing low-quality, low-effort posts, demanding that people do their homework first, and so on. Some of these communities have functioned pretty well for many years.
But it's not an option for HN—this community is too large and incohesive. If we were to allow it, such tactics would soon spread, not in service of technical accuracy, signal/noise ratio, or anything like that, but just general douchery. Ignorant users would see knowledgeable users treating others that way and would follow the worst part of their example—not the becoming-knowledgeable part (that would require an effort!) — just the being-a-jerk part.
Then we'd see an exodus of users who don't want to be surrounded by that kind of thing. Then general douchery would comprise a higher percentage of what remained, making the next exodus even bigger. For a community like HN, this is how you get catastrophic decline.
In order to keep HN worth participating in, we have to have a culture that is on the good side of these nonlinear effects—i.e. we need interactions that raise overall quality rather than damaging it. Situations when a user posts something wrong or ignorant are a classic example. Correcting misinformation is good, but some ways of doing it harm the ecosystem while others benefit it. You have to consider not only the local (comment-to-comment) interaction but the systemic effect of such interactions as they compound.
That's why, in situations like this, we ask people who know more to share some of what they know, so others can learn. That way you're not just executing a local destroy operation on some mistake, you're helping to raise the level of knowledge of the community and the quality of the thread. These actions have systemically beneficial effects instead of toxic ones. If you (i.e. we all) do that repeatedly, you end up with a community that you actually want to be part of.
Holy shit, Dan! I just gained so much respect for you as a moderator (and therefore participant) in this community.
Taking the time to write out this very thoughtful, insightful reply to someone who may be knowledgeable but was throwing out hostile one-liners, that is impressive and gives such a great deal of credibility to the work you're doing here -- work that largely goes unseen, of course.
Amazing.
(I actually put down the piece of food I was eating, mid-bite, to write this out. You made my day!)
> 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.
Is it really so unlikely? Firefox integrates all kinds of components from elsewhere; why shouldn't it continue adopting parts of Servo where appropriate?
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.
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.
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).
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.
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.
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.
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.
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.
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,
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?
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.
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 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.
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.
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.
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.
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.
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 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.
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.
>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
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.
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.
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.
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.
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...
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.
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.
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.
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.
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)
- 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 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.
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.
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.
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.
> 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.
> 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.
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.
> 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.
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.
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.
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!
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.
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]
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.
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.
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.
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?
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
> 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.
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.
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.
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?
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.
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.
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.
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 info@servo.org
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!
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.
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...
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.
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.
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!
(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)
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)?
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.
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.
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 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.
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.
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.
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
None of those things point me in the direction of how to embed it.
Maybe they should spent more time catering to the people they claim to be providing the software for and less to the Rust crowd.
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.
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 :)
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).
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.
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.
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?
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.
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.
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.
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
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)
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.
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.
Now they are free to spend their (free) time on what they want. When most of the core contributors where payed by Mozilla, they could not chose to eg. "focus on web compat", hence they went on something you consider useless, but that kept the project alive. That allowed a few other things to be done like the re-write of the parallel layout.
Of course we can't know for sure what would have happened if they refused to work on VR, but my gut feeling is that this would not have helped the project.
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.
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 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.
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.
The LGPL definitely allows static linking, you just have to make it feasible for the user to modify the open source parts of the library and relink them into your proprietary application.
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.
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.
