Is there any plan at Mozilla to eventually use Servo for Firefox or did them basically stopping working on it end any hope of that? Is the Servo team’s plan to build a new browser around it?
It definitely could get interesting soon, I’ve been keenly watching the development of the Ladybird browser (which is also a from-scratch engine) so if there were potentially two viable new browser engines over the next few years that could really shake things up!
Mozilla have already integrated a few key servo components into Firefox. Notably webrender, the rendering backend, and stylo, the style system. But they’ve effectively dropped all servo development at this point, and are not working on it further.
Basically, Mozilla gave Servo employees the foot and the project was taken over by the linux foundation.
Servo dev has been restarted (mostly) during 2023 and the changed Firefox made to their servo implemementation is now being added to servo in batches (ongoing).
So Servo team is aiming to become a full featured (standalone) web platform (browser).
De facto? Google's puppet company to keep regulators happy.
If you think that's the case, then Google is clearly failing at that goal, since they've aggressively taken browser share directly from Firefox users to the point where Firefox may no longer be supported by government services.
Their role is mostly being a fiscal host to receive donations. Servo moved to the Linux Foundation Europe recently (https://servo.org/slides/2023-04-25-servo-and-linux-foundati...), which should make it easier to receive grants from EU programs - this is a good thing!
The undue focus and almost wistful romanticization/fetishization of Servo is frankly weird, especially when it comes from people with only a tenuous grasp of (let alone hands-on relationship with) browser engine internals. I'm talking about tech news writers and kind-of-but-not-really technical commenters on e.g. Reddit who confabulate their own lore in the spirit of those press accounts, etc.
Firefox uses Gecko as its browser engine. The worthwhile parts of Servo are already in Firefox by way of Gecko. Servo is not The Answer to all of life's problems.
Or, to answer your question more bluntly: "No. Stop asking."
On its face, it's a tough sustainability position for an org of Mozilla's size b/c browser revenue - today - is from controlling the search bar (and maybe now payments APIs?). By making Firefox embeddable, Mozilla gives that revenue to whoever is doing the embedding. Ex: Brave <> Chrome engine.
Building for embedding developers can be super distracting if no sustainability, which isn't a problem for Google: They still make money from embedding by owning the embedding environments like Android. AFAICT, Mozilla failed to land in sizeable markets there. They tried to own & partner in the embedding envs -- e.g., FirefoxOS -- so maybe the trick is to get a more generous rev share for phone vendors wanting to break free of Google? Historically didn't seem to really work out, but maybe genAI w/ consumer/prosumer-grade UIs is reopening that door.
Evolutions like that in turn may take quite an engineering & culture rethink as well, not easy to turn such a big & decentralized ship. I'll keep rooting for them!
I’m not well-versed on the internals of FirefoxOS, but I’m not sure it really counts as embedding because to my understanding, the entirety of the user-facing UI was built with Gecko. Embedding entails usage of the engine with unrelated toolkits, e.g. AppKit/UIKit or GTK.
If that’s true, then Mozilla wouldn’t have been making money from Gecko’s ability to embed with FirefoxOS unless the project took a sharp corner and changed UI toolkits.
The FirefoxOS scenario would be Gecko embedding in FirefoxOS, so Mozilla is their own customer, and makes $ by being the controller of FirefoxOS - OS search, and configuration of browser search
It's less likely the handset manufacturer would be able to change search bar defaults in those scenarios, at least without a stronger profit sharing negotiation, as they'd probably be already negotiating a more careful licensing & teaming agreement
I'm struggling to see the logical throughline that connects your comment to mine, or even how it relates to itself.
Gecko was originally conceived to be embeddable by design. TPTB decided this was a handicap. It's not an accident that it's hard to work with outside the context that is its modern raison d'être; it is now unembeddable, if not "by design" then certainly by choice.
Servo is not a product, and there is no product for which Servo is an integral component. Servo was an R&D project. It succeeded. Mozilla laid off a bunch of Servo developers, partly because of COVID, and partly because it was (past) done; it doesn't make sense to keep paying for R&D at Servo's stage. It's debatable whether it's even R&D at that point—more like wankery/noodling (i.e. what most programmers want to do, but that the world already has enough of).
"There was never a proper embeddable gecko" is both (a) a strong claim which with some difficulty we might be able adjudicate, but not especially important whether we do or not because, crucially, it is (b) not the same thing as saying/proving that "Gecko was not originally conceived to be embeddable" (or proving that its negation is untrue).
Gecko was not, at the time that Servo was conceived, supposed to be easy to embed. Gecko had, by the time that Servo was conceived, undergone refactoring that knowingly made it more difficult to embed. It would be accurate to say that, at the time that Servo was conceived, embeddability of Gecko was an explicit non-goal.
This is exactly why I raised the issue of the logical throughline of the other comment—what is the point of mentioning Gecko's embeddability in this discussion? All right, Gecko is "notoriously unembeddable". So what? It's a complete nonsequitur, and it risks catching anyone off guard if they're not playing close enough attention and they mistake it for a salient retort of... something not actually stated or argued here
K-Meleon used the Gecko rendering engine but with a native chrome and no SpiderMonkey. It also powers Thunderbird and the SeaMonkey browser. I'm sure it turned up elsewhere before it was too 'baked in' to Firefox.
In the case of Thunderbird and seamonkey, Gecko was not embedded, but was the "embedder".
For a short time, there was some attempts (native cocoa and gtk widget) to embed gecko, but it was really not meant to be, it was really hacky and never matured.
Throughline is unwanted fetishization/romantizadion of Servo.
I'd argue Servo's promise was never realized - embedding.
Another part of it is losing people in the purge. People fired weren't hired to work on Servo exclusively, some were long time developers of FF, including the MDN docs team.
So it's not like they started Servo, hired bunch of people to work on it, then fired them after R&D was done.
Is there any plan at Mozilla to eventually use Servo for Firefox or did them basically stopping working on it end any hope of that?
Initially, I think Servo was never meant to be integrated wholesale into anything. It was a experiment playground to evaluate ideas without having them coupled to mainline Firefox, and be able to iterate on things quickly.
Once the ideas were validated, they were integrated into Firefox without pulling in their entirety of Servo.
The "Quantum Render project" is one example of this, where the WebRender compositor was first created in Servo, and eventually integrated into Firefox mainline.
In a decade that many people feared would become the nadir of browser engine diversity, we hope we can help change that with Servo.
I sure hope so! It might be a good thing that Servo is now independent from Mozilla. We can't rely on Mozilla anymore, and should move on. Maybe someday Servo can become the new Firefox (as in "modern and freedom-respecting browser")?
From testing the current version of Servo, it still has a long long way to go though, until it becomes a usable browser.
Safe memory management without GC is the feature that gets Rust the most headlines, but it's not the only raison d'etre. It also has a great type system, that combined with the focus of the standard library and the library ecosystem makes it a lot easier to avoid bugs and makes refactoring a lot safer and easier. It's also very fast, and scrapers are surprisingly often CPU bound
Did you use servo in the context of the scaper? In general I'd be happy to hear more about how you use servo, which you could discuss in our zulip: https://servo.zulipchat.com/
It is for now, but as both Ladybird and Jakt are SerenityOS projects, eventually parts of Ladybird might get written in Jakt. Jakt compiles to C++ and plans to have features like "inline C++" to allow easy interop between the two, so I assume they are thinking about this.
Which, despite being much younger and 80% made by one guy, is somehow way farther along than Servo. Ladybird doesn't have any pre-built images, but it's downright usable.
It's not further along when you consider the vulnerabilities that are present. C++ is unfit for long term use because it is intentionally introducing severe tech debt that we mistakenly imagine doesn't have to be repaid.
I rely on Mozilla just fine. Have used Firefox for a decade and will continue to do so. I am not about to accept Google as the sole provider of the web like you are so eager to do.
With Firefox being in single digit marketshare, the fight is already over. It's hard to justify developing for or testing against Firefox unless you want to appeal to the similarly small Linux desktop crowd.
Google needs to have their arms tied for a bit. Their fingers are in every single pie, taxing the entire tech sector.
Likewise, Safari shouldn't be the default iPhone browser, Edge shouldn't be the default on Windows, and no company should be able to scare users or force their solution as a default.
But looking at alternative browsers like Brave, Vivaldi, Opera or Arc they are also Chromium based. Brave is even by Mozilla's former CTO and they still don't use the Mozilla stack. Many apps will either bundle in CEF or are entirely written in Electron.
Mozilla just made technology that nobody else wants to use.
Mozilla just made technology that nobody else wants to use.
It's not that nobody WANT to use it, but more like nobody CAN use it. Are you mentioned yourself, most developer only test against chrome/chromium so using servo would be commercial suicide. It not really a statement on servo vs chromium on technical level, but of google vs Mozilla market dominance.
For me it seems we are past peak "works only in IE^h^hChrome".
There was a time 5 years ago or so when several interesting websites only worked in Chromebut I haven't seen that problem in a while and the last website I had to deal with that only supported Chrome was a product that a company I work for used but threw out earlier this year.
Yes, some things still mysteriously work slower in Firefox or have some features disabled for no good reason which is why consumer protection agencies still have work to do but I haven't opened Chrome for weeks now I think and last time I did I think the thing I tried to access was just as broken there.
From testing the current version of Servo, it still has a long long way to go though, until it becomes a usable browser.
In reality, I think you're waiting for a different project. Servo is like Gecko/Webkit, it's the browser engine. As far as I know, they're not aiming to build a browser, just the engine part.
What you're waiting for is someone to start using Servo as an engine and provide the browser chrome :)
Of course it is written in C++ and you'd probably want a pure Rust browser. But it is sad seeing that fairly complete open source JIT JavaScript engine sit and rot.
Correct, but for the Tauri/Servo combination, you need Servo which is unlikely to be already available. Stripped release builds of servo are currently 106M which is quite large. Hopefully some size reduction will be achieved.
Can anyone tell me whether Servo is "ready enough" to use for small noncommercial projects? For example, I really like writing personal projects in Typescript using Deno, but there really isn't a very good UI library for Deno outside of running an HTTP server. Other attempts at UI libraries, last I checked, were experimental or half-assed. Would be cool to somehow integrate directly with Servo from Deno so that I don't have to resort to Electron.
Can anyone tell me whether Servo is "ready enough" to use for small noncommercial projects?
I don't think it is, yet. But why not play around with it and see if it's enough for your use case? Hard to know exactly without knowing what you need to be able to do.
Personally, Tauri currently hits the sweetspot of being way lighter than Electron, but still provide (mostly) the same benefits.
Could you tell me more about what you mean with "integrate directly with Servo from Deno" You're welcome to the chat to discuss in more details if you want: https://servo.zulipchat.com/
The budget to make a browser today (including a browser engine) is estimated to be around 400 million yearly (FF cost, estimates for Safari in the same range). They may be bloated, but even by being 10x more efficient it’s still 40 million a year of equivalent engineering work. How is servo intending to pull that work without the leverage of a big corp?
I might be wrong but I don't think servo is intending to be feature or standard complete ever. Most of the cost of firefox or safari likely comes from new features.
Also it is a web rendering engine, not a full fleshed browser.
How much of that cost is the browser vs the cost of the browser engine?
Servo currently describes itself as a "web rendering engine", so I don't think they are aiming to become a full-featured browser, and I'm not sure if there is an important distinction between "browser engine" vs "web rendering engine". It makes it sound like they only want to focus on the rendering part itself.
There's something wackadoo going on in software where in one environment it'll take 200 workers six years to have something that's still not good, and in another it'll take 1-5 workers a couple years to do at least as well.
It's not even a corporate vs. small shop thing. Look at the team sizes on "giant" programs from big companies in the 90s and consider how enormous an undertaking they'd be considered by most software orgs today.
Like, I get all the Mythical Man-Month, Brooks' Law stuff and that that observation predates the period I'm talking about, but there's definitely been some kind of shift that has other factors causing this (with Brooks' Law compounding the problem). Not sure what it is, I just know that it sure looks like we're far less efficient at building software than we used to be (where "we" is the industry overall). It's like every single organization larger than a dozen people got way worse at building software, pretty suddenly, some time between about 2005 and 2010.
I think you're missing the factor that expanding the API surface area, however attractive/productive/cool each individual expansion/feature might be, in aggregate becomes a moat maintaining the incumbent's dominant position.
So as far as Google is concerned, the implied manpower requirements are a feature, not a bug.
Chrome's surface area is now huge (and still expanding at a fair clip), but matching Chrome's featureset has become table-stakes for being considered a viable desktop browser, and independently implementing (and maintaining) that entire set of features requires a correspondingly large developer team, even if you were somehow more labor-efficient.
Yes it sounds interesting and I wonder what it would take as well, you're welcome to join the chat to discuss in more details: https://servo.zulipchat.com/
Is there any plan at Mozilla to eventually use Servo for Firefox or did them basically stopping working on it end any hope of that? Is the Servo team’s plan to build a new browser around it?
It definitely could get interesting soon, I’ve been keenly watching the development of the Ladybird browser (which is also a from-scratch engine) so if there were potentially two viable new browser engines over the next few years that could really shake things up!
Mozilla have already integrated a few key servo components into Firefox. Notably webrender, the rendering backend, and stylo, the style system. But they’ve effectively dropped all servo development at this point, and are not working on it further.
Huh? Why would they drop development of key components to their main product?
What is Mozilla without Firefox?
Update:
https://www.youtube.com/watch?v=9lkIX5ryZZ4
Basically, Mozilla gave Servo employees the foot and the project was taken over by the linux foundation.
Servo dev has been restarted (mostly) during 2023 and the changed Firefox made to their servo implemementation is now being added to servo in batches (ongoing).
So Servo team is aiming to become a full featured (standalone) web platform (browser).
They integrated what they felt was worthwhile, and continue to develop and support those pieces internally to Firefox.
Servo is not Firefox. It was always a testbed research platform. Stopping development of Servo does not mean stopping development of Firefox.
De facto? Google's puppet company to keep regulators happy.
If you think that's the case, then Google is clearly failing at that goal, since they've aggressively taken browser share directly from Firefox users to the point where Firefox may no longer be supported by government services.
Why? What is role of Linux Foundation anyway?
(Beside spending members tons of spam and completely ignore GDPR?)
Their role is mostly being a fiscal host to receive donations. Servo moved to the Linux Foundation Europe recently (https://servo.org/slides/2023-04-25-servo-and-linux-foundati...), which should make it easier to receive grants from EU programs - this is a good thing!
The undue focus and almost wistful romanticization/fetishization of Servo is frankly weird, especially when it comes from people with only a tenuous grasp of (let alone hands-on relationship with) browser engine internals. I'm talking about tech news writers and kind-of-but-not-really technical commenters on e.g. Reddit who confabulate their own lore in the spirit of those press accounts, etc.
Firefox uses Gecko as its browser engine. The worthwhile parts of Servo are already in Firefox by way of Gecko. Servo is not The Answer to all of life's problems.
Or, to answer your question more bluntly: "No. Stop asking."
And Gecko has been notoriously unembeddable. Which kinda helped the whole CEF spread.
Not to mention Mozilla basically kneecapped Servo and Firefox by firing most of its devs in a purge.
Mozilla needs to hear this more often.
There is only one browser, because browsers need to be embeddable, and Firefox isn't.
Interesting to work through that
On its face, it's a tough sustainability position for an org of Mozilla's size b/c browser revenue - today - is from controlling the search bar (and maybe now payments APIs?). By making Firefox embeddable, Mozilla gives that revenue to whoever is doing the embedding. Ex: Brave <> Chrome engine.
Building for embedding developers can be super distracting if no sustainability, which isn't a problem for Google: They still make money from embedding by owning the embedding environments like Android. AFAICT, Mozilla failed to land in sizeable markets there. They tried to own & partner in the embedding envs -- e.g., FirefoxOS -- so maybe the trick is to get a more generous rev share for phone vendors wanting to break free of Google? Historically didn't seem to really work out, but maybe genAI w/ consumer/prosumer-grade UIs is reopening that door.
Evolutions like that in turn may take quite an engineering & culture rethink as well, not easy to turn such a big & decentralized ship. I'll keep rooting for them!
I’m not well-versed on the internals of FirefoxOS, but I’m not sure it really counts as embedding because to my understanding, the entirety of the user-facing UI was built with Gecko. Embedding entails usage of the engine with unrelated toolkits, e.g. AppKit/UIKit or GTK.
If that’s true, then Mozilla wouldn’t have been making money from Gecko’s ability to embed with FirefoxOS unless the project took a sharp corner and changed UI toolkits.
The FirefoxOS scenario would be Gecko embedding in FirefoxOS, so Mozilla is their own customer, and makes $ by being the controller of FirefoxOS - OS search, and configuration of browser search
It's less likely the handset manufacturer would be able to change search bar defaults in those scenarios, at least without a stronger profit sharing negotiation, as they'd probably be already negotiating a more careful licensing & teaming agreement
I was part of Mozilla back then. I think we were already talking about making Gecko embeddable in __2003__.
But then… looot of things happened, other priorities, competition, bad decisions, etc etc.
Arguably neither is Chrome. Electron, CEF and WebView2 are all forks of it. Google has no interest in a supported official embedding API.
I'm struggling to see the logical throughline that connects your comment to mine, or even how it relates to itself.
Gecko was originally conceived to be embeddable by design. TPTB decided this was a handicap. It's not an accident that it's hard to work with outside the context that is its modern raison d'être; it is now unembeddable, if not "by design" then certainly by choice.
Servo is not a product, and there is no product for which Servo is an integral component. Servo was an R&D project. It succeeded. Mozilla laid off a bunch of Servo developers, partly because of COVID, and partly because it was (past) done; it doesn't make sense to keep paying for R&D at Servo's stage. It's debatable whether it's even R&D at that point—more like wankery/noodling (i.e. what most programmers want to do, but that the world already has enough of).
Which part? And… what do you mean by embeddable in that context?
XULRunner?
XULRunner was not Gecko embed. It was Gecko embedding stuff.
There was never a proper embeddable gecko.
There has been an attempt for a gtk widget, but it never matured.
"There was never a proper embeddable gecko" is both (a) a strong claim which with some difficulty we might be able adjudicate, but not especially important whether we do or not because, crucially, it is (b) not the same thing as saying/proving that "Gecko was not originally conceived to be embeddable" (or proving that its negation is untrue).
Gecko was not, at the time that Servo was conceived, supposed to be easy to embed. Gecko had, by the time that Servo was conceived, undergone refactoring that knowingly made it more difficult to embed. It would be accurate to say that, at the time that Servo was conceived, embeddability of Gecko was an explicit non-goal.
This is exactly why I raised the issue of the logical throughline of the other comment—what is the point of mentioning Gecko's embeddability in this discussion? All right, Gecko is "notoriously unembeddable". So what? It's a complete nonsequitur, and it risks catching anyone off guard if they're not playing close enough attention and they mistake it for a salient retort of... something not actually stated or argued here
K-Meleon used the Gecko rendering engine but with a native chrome and no SpiderMonkey. It also powers Thunderbird and the SeaMonkey browser. I'm sure it turned up elsewhere before it was too 'baked in' to Firefox.
In the case of Thunderbird and seamonkey, Gecko was not embedded, but was the "embedder".
For a short time, there was some attempts (native cocoa and gtk widget) to embed gecko, but it was really not meant to be, it was really hacky and never matured.
Gecko was never designed to be embedded. Really.
Throughline is unwanted fetishization/romantizadion of Servo.
I'd argue Servo's promise was never realized - embedding.
Another part of it is losing people in the purge. People fired weren't hired to work on Servo exclusively, some were long time developers of FF, including the MDN docs team.
So it's not like they started Servo, hired bunch of people to work on it, then fired them after R&D was done.
I remember Mozilla Prism as a "site specific browser"or what one calls it back in the days.
If only one could Boot2Gecko
Initially, I think Servo was never meant to be integrated wholesale into anything. It was a experiment playground to evaluate ideas without having them coupled to mainline Firefox, and be able to iterate on things quickly.
Once the ideas were validated, they were integrated into Firefox without pulling in their entirety of Servo.
The "Quantum Render project" is one example of this, where the WebRender compositor was first created in Servo, and eventually integrated into Firefox mainline.
I remember the Quantum hype. Time flies.
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Rel...
Hype? I guess
It made Firefox competitive again
Hype can be deserved, not always dismissive
Yeah, incredible that there was a brief period of time where Mozilla almost made Firefox exciting again.
Quote from the post:
I sure hope so! It might be a good thing that Servo is now independent from Mozilla. We can't rely on Mozilla anymore, and should move on. Maybe someday Servo can become the new Firefox (as in "modern and freedom-respecting browser")?
From testing the current version of Servo, it still has a long long way to go though, until it becomes a usable browser.
When I initially read the headline what I remember thinking before reading the article was 'I hope it has some use outside of Firefox'.
I build scrapers with rust, and use servo
is there a chance to see it? any links for someone interested?
I would have thought it overkill to memory manage scrapers by hand. Do you need such succinct memory usage?
Safe memory management without GC is the feature that gets Rust the most headlines, but it's not the only raison d'etre. It also has a great type system, that combined with the focus of the standard library and the library ecosystem makes it a lot easier to avoid bugs and makes refactoring a lot safer and easier. It's also very fast, and scrapers are surprisingly often CPU bound
Did you use servo in the context of the scaper? In general I'd be happy to hear more about how you use servo, which you could discuss in our zulip: https://servo.zulipchat.com/
There's also the Ladybird browser by the SerenityOS folks, that's however not written in a memory-safe language.
I thought Jakt was supposed to be memory safe (but it was very wip last I looked at Jakt)
Ladybird is written in C++
It is for now, but as both Ladybird and Jakt are SerenityOS projects, eventually parts of Ladybird might get written in Jakt. Jakt compiles to C++ and plans to have features like "inline C++" to allow easy interop between the two, so I assume they are thinking about this.
Which, despite being much younger and 80% made by one guy, is somehow way farther along than Servo. Ladybird doesn't have any pre-built images, but it's downright usable.
Andreas is incredible but that's an overstatement.
Still a monumental feat but don't downplay the community that's rallied behind him.
It's not further along when you consider the vulnerabilities that are present. C++ is unfit for long term use because it is intentionally introducing severe tech debt that we mistakenly imagine doesn't have to be repaid.
I rely on Mozilla just fine. Have used Firefox for a decade and will continue to do so. I am not about to accept Google as the sole provider of the web like you are so eager to do.
I think you misunderstood:
I think GP just like me wants neither Google nor Mozilla.
With Firefox being in single digit marketshare, the fight is already over. It's hard to justify developing for or testing against Firefox unless you want to appeal to the similarly small Linux desktop crowd.
This is why antitrust matters.
Google needs to have their arms tied for a bit. Their fingers are in every single pie, taxing the entire tech sector.
Likewise, Safari shouldn't be the default iPhone browser, Edge shouldn't be the default on Windows, and no company should be able to scare users or force their solution as a default.
The browser space would be fine without Google.
But looking at alternative browsers like Brave, Vivaldi, Opera or Arc they are also Chromium based. Brave is even by Mozilla's former CTO and they still don't use the Mozilla stack. Many apps will either bundle in CEF or are entirely written in Electron.
Mozilla just made technology that nobody else wants to use.
It's not that nobody WANT to use it, but more like nobody CAN use it. Are you mentioned yourself, most developer only test against chrome/chromium so using servo would be commercial suicide. It not really a statement on servo vs chromium on technical level, but of google vs Mozilla market dominance.
I have some good news:
For me it seems we are past peak "works only in IE^h^hChrome".
There was a time 5 years ago or so when several interesting websites only worked in Chromebut I haven't seen that problem in a while and the last website I had to deal with that only supported Chrome was a product that a company I work for used but threw out earlier this year.
Yes, some things still mysteriously work slower in Firefox or have some features disabled for no good reason which is why consumer protection agencies still have work to do but I haven't opened Chrome for weeks now I think and last time I did I think the thing I tried to access was just as broken there.
As a developer, nothing screams incompetence more than a site being completely unusable in FF though.
It is hard to justify testing for Mozilla when Internet Explorer has 95% market share.
What could possibly go wrong?
In reality, I think you're waiting for a different project. Servo is like Gecko/Webkit, it's the browser engine. As far as I know, they're not aiming to build a browser, just the engine part.
What you're waiting for is someone to start using Servo as an engine and provide the browser chrome :)
I thought it would be a fun weird project to make Servo work with MS' abandoned JavaScript engine:
https://github.com/chakra-core/ChakraCore
Of course it is written in C++ and you'd probably want a pure Rust browser. But it is sad seeing that fairly complete open source JIT JavaScript engine sit and rot.
I was specifically talking about Servo as a rendering engine. Just open their own website in Servo, and look for all the rendering problems present :)
This is really exciting! Hopefully can lead to tiny packages (compared to Electron) but still a consistent rendering story across platforms.
If it has enough features to match Electron, I think it's likely to end up the same size (100 MB on disk)
No, because Electron embeds Chromium/Chrome, Tauri uses whatever the platform already has.
Correct, but for the Tauri/Servo combination, you need Servo which is unlikely to be already available. Stripped release builds of servo are currently 106M which is quite large. Hopefully some size reduction will be achieved.
Why not a PWA? Does your app need more permissions to mess with people's system that a PWA would allow?
For lightweight alternatives to Electron.js (apart from Tauri), have a look at:
- Sciter (https://sciter.com)
- Yue (https://libyue.com)
- Wails (https://wails.io)
- Muon (https://github.com/ImVexed/muon) and Ultralight (https://ultralig.ht)
- Gluon (https://gluonjs.org)
- NeutralinoJS (https://neutralino.js.org)
- Proton Native (https://proton-native.js.org)
- NodeGUI (https://nodegui.org)
- DeskGap (https://deskgap.com)
- Graffiti (http://tomsik.cz/graffiti/)
Can anyone tell me whether Servo is "ready enough" to use for small noncommercial projects? For example, I really like writing personal projects in Typescript using Deno, but there really isn't a very good UI library for Deno outside of running an HTTP server. Other attempts at UI libraries, last I checked, were experimental or half-assed. Would be cool to somehow integrate directly with Servo from Deno so that I don't have to resort to Electron.
I don't think it is, yet. But why not play around with it and see if it's enough for your use case? Hard to know exactly without knowing what you need to be able to do.
Personally, Tauri currently hits the sweetspot of being way lighter than Electron, but still provide (mostly) the same benefits.
There's always https://neutralino.js.org/ which uses native WebView components to keep itself rather smaller than Electron.
Could you tell me more about what you mean with "integrate directly with Servo from Deno" You're welcome to the chat to discuss in more details if you want: https://servo.zulipchat.com/
The budget to make a browser today (including a browser engine) is estimated to be around 400 million yearly (FF cost, estimates for Safari in the same range). They may be bloated, but even by being 10x more efficient it’s still 40 million a year of equivalent engineering work. How is servo intending to pull that work without the leverage of a big corp?
I might be wrong but I don't think servo is intending to be feature or standard complete ever. Most of the cost of firefox or safari likely comes from new features.
Also it is a web rendering engine, not a full fleshed browser.
How much of that cost is the browser vs the cost of the browser engine?
Servo currently describes itself as a "web rendering engine", so I don't think they are aiming to become a full-featured browser, and I'm not sure if there is an important distinction between "browser engine" vs "web rendering engine". It makes it sound like they only want to focus on the rendering part itself.
Ladybird has mostly been made by one guy in a few years and has somehow become a usable browser. Where did you get that estimation?
useable and complete are very different things.
There's something wackadoo going on in software where in one environment it'll take 200 workers six years to have something that's still not good, and in another it'll take 1-5 workers a couple years to do at least as well.
It's not even a corporate vs. small shop thing. Look at the team sizes on "giant" programs from big companies in the 90s and consider how enormous an undertaking they'd be considered by most software orgs today.
Like, I get all the Mythical Man-Month, Brooks' Law stuff and that that observation predates the period I'm talking about, but there's definitely been some kind of shift that has other factors causing this (with Brooks' Law compounding the problem). Not sure what it is, I just know that it sure looks like we're far less efficient at building software than we used to be (where "we" is the industry overall). It's like every single organization larger than a dozen people got way worse at building software, pretty suddenly, some time between about 2005 and 2010.
I think you're missing the factor that expanding the API surface area, however attractive/productive/cool each individual expansion/feature might be, in aggregate becomes a moat maintaining the incumbent's dominant position.
So as far as Google is concerned, the implied manpower requirements are a feature, not a bug.
Chrome's surface area is now huge (and still expanding at a fair clip), but matching Chrome's featureset has become table-stakes for being considered a viable desktop browser, and independently implementing (and maintaining) that entire set of features requires a correspondingly large developer team, even if you were somehow more labor-efficient.
Usable is carrying the weight of the world in that sentence.
The Playwright browser automation framework already has backends for Chromium, WebKit and Firefox.
I wonder what it would take to build a Servo backend?
Could be a really fun way to experiment with its capabilities.
Yes it sounds interesting and I wonder what it would take as well, you're welcome to join the chat to discuss in more details: https://servo.zulipchat.com/