In an ideal world, Servo would become a competitive engine for browsers, but in the shorter term I think there’s a lot of value in it for non-browser uses. Electron uses embedded Chrome, but most Electron apps have 100% control over the HTML and CSS that they generate. This means that they can work around missing features in the browser engine, whereas a real browser has to handle whatever it gets back from an HTTP request to any third-party server.
There are lots of places where people use HTML+CSS+JavaScript because they also work on the web, but where you don’t need to support everything that the web does. Servo is a great fit there. And that path makes them able to ship something that’s useful now and add missing features gradually, rather than having to get to 100% immediately for it to be useful. And, at some point, enough will be working that it can function as a drop-in web view for the general case.
I’m ignorant - what is the pitch for servo over chrome there? Won’t they both be about the same size, eventually anyway, if the goal for servo to be a complete engine?
The original releases of Chrome were something like 10mb, and it was able to render most of the web. Today it is well over 100mb. Not sure what it’s doing that is >10x more than before.
A complete engine could still be potentially stripped down for distribution for an embedded case where you know you don’t need certain things. I would hope they design it with these cases in mind. Generally, if you use chrome you get like a gigabyte blob you’re expected to distribute with all kinds of web features supported you’ll probably not use. Fine for embedding a browser you put on arbitrary websites, overkill for something where you know what you want.
Some bike lanes advocates claim that a city must install bike lanes to generate the demand that justifies them.
It seems Servo is going to be something similar: by manifesting an engine, they hope to generate the demand that keeps this project going.
The most celebrated aspect of Servo, in my opinion, is that it uses Rust and somehow that’s a Good Thing (TM).
It feels like someone celebrating their house pipes are great because they used Knippex Pliers to put them together.
Using Rust is alluring to create developer engagement (and it shows), but it’s not what would drive the adoption of Servo - being used is what will drive adoption. Rust is at best neutral in this regard, and waving it as if it were some kind of strong benefit feels odd to me. In any case, better Rust than historical C++ for sure.
Are you saying that you don’t understand the bike lane argument? The classic explanation goes like this… say you have a river, and pedestrians aren’t crossing it, because the only way to cross is to swim the river, so like 2 weirdos do this each year. Naysayers argue “there’s no point in building a bridge across this river, because only 2 people cross it each year!” But surprise, if you let people walk across the river instead of swimming, you’ll get a lot more foot traffic on the other side.
If we bring this analogy to the browser, it seems possible that the situation is similar. Servo being usable would result in it being used. If Igalia can actually manifest a working browser engine, and it’s not too much of a pain to integrate into other programs (such as a full web browser), then it’ll get used a lot more than a browser engine that doesn’t render web pages properly (or can’t be easily embedded). It probably helps if you partner with someone who definitely wants to use your engine, such as the partnership they have with Tauri, so you can be sure at least one group will use it and demand isn’t completely imaginary.
Yeah bike lanes is the worst analogy to make, because it’s obvious that they have utility, and there is demand
I’ve lived in some of the most crowdest cities (SF and NYC), and you absolutely need bike lanes.
For one, there are A LOT more people than there were 20 or 30 years ago. And two, the status quo 20 or 30 years ago wasn’t sufficient either
A parked car is objectively a bad economic use of space, compared to a bike lane
Also, two new browsers are moving to Swift - the one by the Browser Company, and LadyBird
C++ isn’t good enough for a highly concurrent program, that’s more than 10M lines, with hundreds of engineers in it
And I say this as someone who’s worked with the Chrome team, sat with them, etc. The quality of the code varies immensely, as you would expect for anything with hundreds of engineers in it at a given time.
(not saying Swift is necessarily the best, I don’t know that much about it)
I should add that my preference is not to have these huge browsers that require hundreds of engineers to build, but if you take that as a constraint, then there are downsides to doing it in C++ …
A small team can definitely write good C++. Large teams have problems in any language, but with C++ the problems can have pretty bad consequences that are not easy to work your way out of … it’s sort of a “one-way door”
I personally would be thrilled to have a browser that wasn’t a pile of CVEs in a trenchcoat. Having one that isn’t developed by an advertising company would be great too!
Me too. And having an embeddable browser engine that can be used in browsers that cater to specific accessibility needs not served by Firefox would be great. The only realistic options currently, as far as I can tell, are Chromium and WebKit, both by advertising companies.
It feels like someone celebrating their house pipes are great because they used Knippex Pliers to put them together.
If in 99% of houses flushing a turd of a particular size gave someone else remote code execution, you’d be pretty proud if your plumbing wasn’t vulnerable.
Rust/Servo did succeed in replacing selector matching and GPU rendering in Gecko where previous attempts in C++ have failed.
I don’t know if there’s demand for Servo specifically (web compat is hard and there’s more to engines than safety), but all major engines have issues with memory safety of C++, and are looking for a solution. Blink and Gecko are replacing parts with Rust. Apple is working on making a lower-level Swift to replace their C++.
I don’t know if there’s demand for Servo specifically (web compat is hard and there’s more to engines than safety),
I think it would be quite nice to have an alternative to Blink and WebKit for embedded / Electron-like use cases. Gecko isn’t embeddable, and even using it as an application framework isn’t exactly a well supported use anymore.
The Servo project has been started to replace crufty non-thread-safe C++ in Gecko, and Rust has been created specifically for Servo.
I hope you don’t mind, but a minor grammar nit: “was”, rather than “has been” in this case in English.
Yes, the difference in meaning is that “was” describes an event in the past, and “has been” describes something that was true for some period in the past.
I love having more diversity in the browser engine market - and maybe they can show what a CVE-less browser looks like. If Rust makes it easy to them, I’m not gonna complain. (Mozilla already showed that they got speedups from using rust by allowing them to multithread worry free.)
I and I imagine most English speakers of my acquaintance would assume both of these mean the same thing. “Smokeless” and “smoke free” both mean “without smoke” (though in different senses). Ditto “childless” and “child free” (with different valences). Etc.
“X-less” and “X-free” generally mean the same thing; without any X. There might be some exceptions but none are coming to mind, so your response looked a bit like pulling a weird technicality rather than a misunderstanding. Sorry for any rudeness!
A web engine is by nature a CVE-magnet, even if you don’t have any memory issue. But being free of most memory issues allows you to concentrate on everything else, and Rust has other correctness tricks up its sleeve that have nothing to do with memory or data races.
Performance-wise, beside Mozilla’s well-known “we failed to parallelize this in C++ but succeeded in Rust” return on experience, there’s Google’s “we isolate C++ libs in their own process but use Rust libs directly” to consider. Servo isn’t full-featured, fast, or battle-tested yet, but I’m hopeful.
Does Servo being a Rust project make it easier to embed in other applications?
I don’t speak from a whole lot of experience here, but my perception is C/C++ dependencies can be a pain to set up, and one of the benefits of the Rust ecosystem is the ease of installing dependencies. Need to render an HTML document in your app? Maybe someday the answer will be to import servo-whatever, and you won’t have to spend mental effort on stuff like (I’m making this up) installing the correct versions of libjpeg and cairo.
I’m not sure about rust per se but the post and additional content in linked posts highlights how their current development goals and partnership with Tauri has led them to make changes to make Servo specifically more ergonomic to embed in other applications.
Rust doesn’t make embedding easier (unless the host is in Rust), at best it makes compiling more straightforward. What matters for embedding is the architecture and intent of the project.
Servo is designed to be embeddable, and judging by how fast Tauri was able to integrate it, they do a good job. None of the other engines fare well in that regard: Gecko is bound to its browser, Blink is marginally better but has problematic leadership, the various webkits are lagging behind development, Ladybird is (I’m guessing) not interested in the outside world, Flow is proprietary… Servo is an enticing project, whether you care about Rust or not.
I think in theory Rust could be easier to embed because the contracts at interfaces are more explicit.
With C or C++ it can be unclear who is responsible for freeing an allocation or what preconditions need to hold about the environment and objects crossing boundaries. I guess this is true for any library though, not just embeddable things.
I suspect it depends a lot on the API. Most other languages allow more aliasing than Rust permits, so you’re likely to end up with a lot of things where the Rust type system prevents certain API misuse but a foreign API doesn’t. If I pass a borrowed Rust pointer to Lua, for example, ensuring that it isn’t captured is not trivial (I can probably wrap it in an object that is explicitly nulled at the end of the call, but then I have a thing that suddenly goes away from Lua at surprising times). Owning references are easier, but then borrows from them may be difficult.
You can almost certainly design an API that uses a narrow set of Rust that’s easy to bridge, but it requires some careful thought. From the sounds of it, the Igalia folks are doing that thinking, which is probably more important than the underlying language.
It’s always been a feature because it influences what runtime you need to depend on. This comes up all the time in managed languages, whether you need .NET installed, or JDK, or Python, etc.
It is rather a cost than a feature. Software has some benefits (functions-features, qualities…) and brings some costs (price, time to learn, dependencies to install, complexity to deal with…). Users starts with benefits (is software useful for me?) and then, only if significant benefits are present, they evaluate the costs (are they reasonable? lower then benefits?).
(of course, there are also users or customers that do not think this rational way)
P.S. I use the word „feature“ as some positive value, reason to buy or use. If you define it as an general characteristic that could be both positive or negative, then I agree that programming language is such a characteristic.
P.P.S. Similar discussion: Is price a selling point? If you offer just „cheap something“ will people buy it? Probably not. But if you offer some useful product for a reasonable price or cheaper than your competitors, than yes. However the main selling point is that usefulness, not the cheapness itself.
In an ideal world, Servo would become a competitive engine for browsers, but in the shorter term I think there’s a lot of value in it for non-browser uses. Electron uses embedded Chrome, but most Electron apps have 100% control over the HTML and CSS that they generate. This means that they can work around missing features in the browser engine, whereas a real browser has to handle whatever it gets back from an HTTP request to any third-party server.
There are lots of places where people use HTML+CSS+JavaScript because they also work on the web, but where you don’t need to support everything that the web does. Servo is a great fit there. And that path makes them able to ship something that’s useful now and add missing features gradually, rather than having to get to 100% immediately for it to be useful. And, at some point, enough will be working that it can function as a drop-in web view for the general case.
I’m ignorant - what is the pitch for servo over chrome there? Won’t they both be about the same size, eventually anyway, if the goal for servo to be a complete engine?
The original releases of Chrome were something like 10mb, and it was able to render most of the web. Today it is well over 100mb. Not sure what it’s doing that is >10x more than before.
A complete engine could still be potentially stripped down for distribution for an embedded case where you know you don’t need certain things. I would hope they design it with these cases in mind. Generally, if you use chrome you get like a gigabyte blob you’re expected to distribute with all kinds of web features supported you’ll probably not use. Fine for embedding a browser you put on arbitrary websites, overkill for something where you know what you want.
Some bike lanes advocates claim that a city must install bike lanes to generate the demand that justifies them.
It seems Servo is going to be something similar: by manifesting an engine, they hope to generate the demand that keeps this project going.
The most celebrated aspect of Servo, in my opinion, is that it uses Rust and somehow that’s a Good Thing (TM).
It feels like someone celebrating their house pipes are great because they used Knippex Pliers to put them together.
Using Rust is alluring to create developer engagement (and it shows), but it’s not what would drive the adoption of Servo - being used is what will drive adoption. Rust is at best neutral in this regard, and waving it as if it were some kind of strong benefit feels odd to me. In any case, better Rust than historical C++ for sure.
Are you saying that you don’t understand the bike lane argument? The classic explanation goes like this… say you have a river, and pedestrians aren’t crossing it, because the only way to cross is to swim the river, so like 2 weirdos do this each year. Naysayers argue “there’s no point in building a bridge across this river, because only 2 people cross it each year!” But surprise, if you let people walk across the river instead of swimming, you’ll get a lot more foot traffic on the other side.
If we bring this analogy to the browser, it seems possible that the situation is similar. Servo being usable would result in it being used. If Igalia can actually manifest a working browser engine, and it’s not too much of a pain to integrate into other programs (such as a full web browser), then it’ll get used a lot more than a browser engine that doesn’t render web pages properly (or can’t be easily embedded). It probably helps if you partner with someone who definitely wants to use your engine, such as the partnership they have with Tauri, so you can be sure at least one group will use it and demand isn’t completely imaginary.
Yeah bike lanes is the worst analogy to make, because it’s obvious that they have utility, and there is demand
I’ve lived in some of the most crowdest cities (SF and NYC), and you absolutely need bike lanes.
For one, there are A LOT more people than there were 20 or 30 years ago. And two, the status quo 20 or 30 years ago wasn’t sufficient either
A parked car is objectively a bad economic use of space, compared to a bike lane
Also, two new browsers are moving to Swift - the one by the Browser Company, and LadyBird
C++ isn’t good enough for a highly concurrent program, that’s more than 10M lines, with hundreds of engineers in it
And I say this as someone who’s worked with the Chrome team, sat with them, etc. The quality of the code varies immensely, as you would expect for anything with hundreds of engineers in it at a given time.
(not saying Swift is necessarily the best, I don’t know that much about it)
Isn’t The Browser Company’s Arc browser mostly a Swift shell around Chromium?
Yup, iirc the core is called “CDK” (Chromium Dev Kit?), written in Swift & cross-platform.
I don’t know much about it, never used it
It is based on Chrome, though they have hired some original Chrome contributors/architects, so I assume they are doing a pretty deep reworking
i.e. starting with the shell is the logical thing to do, but not being afraid to fork it and rework the internals
Chrome definitely grew a lot of cruft and bugs over the years. When it was launched, it was a lean and focused program
I should add that my preference is not to have these huge browsers that require hundreds of engineers to build, but if you take that as a constraint, then there are downsides to doing it in C++ …
A small team can definitely write good C++. Large teams have problems in any language, but with C++ the problems can have pretty bad consequences that are not easy to work your way out of … it’s sort of a “one-way door”
I personally would be thrilled to have a browser that wasn’t a pile of CVEs in a trenchcoat. Having one that isn’t developed by an advertising company would be great too!
Me too. And having an embeddable browser engine that can be used in browsers that cater to specific accessibility needs not served by Firefox would be great. The only realistic options currently, as far as I can tell, are Chromium and WebKit, both by advertising companies.
If in 99% of houses flushing a turd of a particular size gave someone else remote code execution, you’d be pretty proud if your plumbing wasn’t vulnerable.
The Servo project has been started to replace crufty non-thread-safe C++ in Gecko, and Rust has been created specifically for Servo.
Literally, the first presentation introducing Rust is called “Project Servo”: http://venge.net/graydon/talks/intro-talk-2.pdf
Rust/Servo did succeed in replacing selector matching and GPU rendering in Gecko where previous attempts in C++ have failed.
I don’t know if there’s demand for Servo specifically (web compat is hard and there’s more to engines than safety), but all major engines have issues with memory safety of C++, and are looking for a solution. Blink and Gecko are replacing parts with Rust. Apple is working on making a lower-level Swift to replace their C++.
I think it would be quite nice to have an alternative to Blink and WebKit for embedded / Electron-like use cases. Gecko isn’t embeddable, and even using it as an application framework isn’t exactly a well supported use anymore.
I hope you don’t mind, but a minor grammar nit: “was”, rather than “has been” in this case in English.
Yes, the difference in meaning is that “was” describes an event in the past, and “has been” describes something that was true for some period in the past.
I love having more diversity in the browser engine market - and maybe they can show what a CVE-less browser looks like. If Rust makes it easy to them, I’m not gonna complain. (Mozilla already showed that they got speedups from using rust by allowing them to multithread worry free.)
All I have to do is sit and watch.
Zero security bugs seems unrealistic. Rust protects you against a few categories of bugs, and that’s great, but it’s not a panacea.
That is why I said CVE-less, not CVE-free.
I and I imagine most English speakers of my acquaintance would assume both of these mean the same thing. “Smokeless” and “smoke free” both mean “without smoke” (though in different senses). Ditto “childless” and “child free” (with different valences). Etc.
Oh, shoot. I could have recognised it with ‘childless’ - thanks!
Ever stared wordlessly at someone while speaking?
I bet you can enlighten me on that - apart from being unkind.
“X-less” and “X-free” generally mean the same thing; without any X. There might be some exceptions but none are coming to mind, so your response looked a bit like pulling a weird technicality rather than a misunderstanding. Sorry for any rudeness!
A web engine is by nature a CVE-magnet, even if you don’t have any memory issue. But being free of most memory issues allows you to concentrate on everything else, and Rust has other correctness tricks up its sleeve that have nothing to do with memory or data races.
Performance-wise, beside Mozilla’s well-known “we failed to parallelize this in C++ but succeeded in Rust” return on experience, there’s Google’s “we isolate C++ libs in their own process but use Rust libs directly” to consider. Servo isn’t full-featured, fast, or battle-tested yet, but I’m hopeful.
Does Servo being a Rust project make it easier to embed in other applications?
I don’t speak from a whole lot of experience here, but my perception is C/C++ dependencies can be a pain to set up, and one of the benefits of the Rust ecosystem is the ease of installing dependencies. Need to render an HTML document in your app? Maybe someday the answer will be to import
servo-whatever, and you won’t have to spend mental effort on stuff like (I’m making this up) installing the correct versions of libjpeg and cairo.I’m not sure about rust per se but the post and additional content in linked posts highlights how their current development goals and partnership with Tauri has led them to make changes to make Servo specifically more ergonomic to embed in other applications.
Rust doesn’t make embedding easier (unless the host is in Rust), at best it makes compiling more straightforward. What matters for embedding is the architecture and intent of the project.
Servo is designed to be embeddable, and judging by how fast Tauri was able to integrate it, they do a good job. None of the other engines fare well in that regard: Gecko is bound to its browser, Blink is marginally better but has problematic leadership, the various webkits are lagging behind development, Ladybird is (I’m guessing) not interested in the outside world, Flow is proprietary… Servo is an enticing project, whether you care about Rust or not.
I think in theory Rust could be easier to embed because the contracts at interfaces are more explicit.
With C or C++ it can be unclear who is responsible for freeing an allocation or what preconditions need to hold about the environment and objects crossing boundaries. I guess this is true for any library though, not just embeddable things.
I suspect it depends a lot on the API. Most other languages allow more aliasing than Rust permits, so you’re likely to end up with a lot of things where the Rust type system prevents certain API misuse but a foreign API doesn’t. If I pass a borrowed Rust pointer to Lua, for example, ensuring that it isn’t captured is not trivial (I can probably wrap it in an object that is explicitly nulled at the end of the call, but then I have a thing that suddenly goes away from Lua at surprising times). Owning references are easier, but then borrows from them may be difficult.
You can almost certainly design an API that uses a narrow set of Rust that’s easy to bridge, but it requires some careful thought. From the sounds of it, the Igalia folks are doing that thinking, which is probably more important than the underlying language.
+1
Programming language was never a feature. But we see again and again people using it as an argument. Quite funny.
It’s always been a feature because it influences what runtime you need to depend on. This comes up all the time in managed languages, whether you need .NET installed, or JDK, or Python, etc.
It is rather a cost than a feature. Software has some benefits (functions-features, qualities…) and brings some costs (price, time to learn, dependencies to install, complexity to deal with…). Users starts with benefits (is software useful for me?) and then, only if significant benefits are present, they evaluate the costs (are they reasonable? lower then benefits?).
(of course, there are also users or customers that do not think this rational way)
P.S. I use the word „feature“ as some positive value, reason to buy or use. If you define it as an general characteristic that could be both positive or negative, then I agree that programming language is such a characteristic.
P.P.S. Similar discussion: Is price a selling point? If you offer just „cheap something“ will people buy it? Probably not. But if you offer some useful product for a reasonable price or cheaper than your competitors, than yes. However the main selling point is that usefulness, not the cheapness itself.