5 ms·

> As well as being independent of any browser vendor, it is designed to be embeddable, memory-safe, modular, and parallel. How does Gecko (the engine used in F

by AnonC 3y ago

> As well as being independent of any browser vendor, it is designed to be embeddable, memory-safe, modular, and parallel. How does Gecko (the engine used in Firefox) fare on being embedded? I thought it wasn't as easy or simple, and hence one of the reasons why Chromium dominated in things like Electron. I can't square these two statements in the article: > Servo has been around for about a decade, so as experimental software projects go, it's a mature one. > It still can't pass the Web Standards Project ACID tests, which way back in 2008 WebKit was the first browser to successfully handle, so there's clearly some way to go yet. I thought the goal of Servo, while it was incubated and paid for by Mozilla, was to absorb parts of it into Firefox over several years (or across decades) since this is a humongous undertaking. It's still painful to see Mozilla's revenues (mostly from Google) and how keeping Servo around could've helped in making a better browser, sooner (compared to current Firefox development).

dthul 3y ago
Quite a few parts of Servo were actually integrated into Firefox/Gecko (such as Stylo).
cmrdporcupine 3y ago
Do you really see a clear link from "better/safer/faster browsing rendering component" to "better revenues" or "better business situation" for Mozilla? Because I don't think I do, and I suspect Mozilla didn't either, really. As a Rust dev, and nerd generally, I love the idea of servo and if I were more excited about browsers and the web would even love to contribute to it. But unfortunately stuff like this isn't what makes or breaks project success in the short or even medium term. I use Firefox as my main browser everywhere now, but I didn't make the jump on any technical merits in rendering. Most days I barely notice which browser I'm on. I use Firefox because of the principles it represents and Google finally crossed the final lines with me, ethically. I don't know what the future holds for Firefox and Mozilla but I don't think it's fundamentally strongly altered by the success of servo. In any case, as a software engineering community we need to find ways to fund big picture projects like Servo etc. without having them tied to the fortunes and whims of various corporations. We lucked out with Linux filling a niche where it could explode in popularity and be securely funded for dev, but that hasn't been the case with lots of other things.
- chimeracoder 3y ago
  > Do you really see a clear link from "better/safer/faster browsing rendering component" to "better revenues" or "better business situation" for Mozilla? Because I don't think I do, and I suspect Mozilla didn't either, really. Most people don't choose a browser based on principles or mission. Even if Firefox captured 100% of the market that did, it would barely move the needle in browser share. Most people choose browsers based on fairly straightforward things, such as the default (many people never change this, which is why changing the default browser via bundled downloads has remained such an effective marketing strategy for decades), performance, the feeling of performance (which is different from actual performance), whether the websites they're visiting are supported, etc.
  - cmrdporcupine 3y ago
    Yeah, absolutely, which is why I think it's always going to be tricky for Firefox as long as there are corporate entities like Google and MS that have identified "having our own browser" as a competitive advantage. When Chrome came on the scene it was a huge improvement, and Google seemed mostly-benevolent then, and the core of it was open source. And I worked in that codebase and met some of the people involved, and they were all good very smart(er-than-me) people that I met. The core engineering project itself has good foundations. The problem is those folks gotta get paid. And so ultimately in the long run, Chrome has become the problem we always dreaded it would become. Which is why, yeah, "we" (for some definition of we) need to come up with a way that these kinds of projects can get paid for outside of places like Google etc. Mozilla almost feels like that, but from talking to the people I know who worked there... it's not.
    - bostik 3y ago
      > When Chrome came on the scene it was a huge improvement I don't think people in general realise how big a jump it was. Process isolation demonstrated that a browser with a single event loop is not a given, and the idea of completely separating page loads from page renders was, for want of a better term, a true paradigm shift. V8 showed that JavaScript didn't have to be disgustingly slow. I still remember the "Chrome Comic" booklet. Google made a big deal out of having hired some of the best compiler optimisation experts money could buy and pointed them towards a goal. V8 came out with two decades of hard-core, bleeding edge research behind it. It took Mozilla nearly a decade to catch up with multi-process Firefox (ironically, the project was called "Electron"). Chrome had the benefit of being a pure greenfield project. Firefox had to retrofit a completely different processing and rendering architecture that broke pretty much all previous assumptions. I recall writing a note to an internal Nokia-infused thread that "Chrome's process isolation is an idea too good not to steal". At the time I didn't know just how damn hard that would be to pull off without introducing multiple flag days. In the end Mozilla managed with one.
jcranmer 3y ago
> How does Gecko (the engine used in Firefox) fare on being embedded? I thought it wasn't as easy or simple, and hence one of the reasons why Chromium dominated in things like Electron. I haven't checked for a while, but it's pretty painful, especially because Mozilla kept changing their mind about how they wanted it to be embedded.
- hn_go_brrrrr 3y ago
  It's remarkable that Mozilla managed to be worse than Google in the "changing their mind" department.
kbrosnan 3y ago
As someone who worked at Mozilla the best way I heard it described is that Netscape designed the embedding to be monolithic. Something you built your app on top of. You best use all of Gecko, NSS, Spidermonkey, etc. Any path that meant your app needed to make changes to Gecko etc. was/is here be dragons territory. If there was some part that your app did not need disabling that part was unsupported and the effort was the the embedding app's responsibility. Where as Chromium was designed to be modular.
tuukkah 3y ago
Firefox had an Electron-like solution from 2006 to 2015 called XULRunner. Firefox and Thunderbird were built on top of the very same tech (XUL UI, XPCOM component object model, Sqlite databases, XPI extensions...) Then Electron came along around 2013. You get a backend using NodeJS (same V8!) and you don't need to learn XUL, XPCOM etc.

by AnonC 3y ago

dthul 3y ago

Quite a few parts of Servo were actually integrated into Firefox/Gecko (such as Stylo).

cmrdporcupine 3y ago

Do you really see a clear link from "better/safer/faster browsing rendering component" to "better revenues" or "better business situation" for Mozilla? Because I don't think I do, and I suspect Mozilla didn't either, really. As a Rust dev, and nerd generally, I love the idea of servo and if I were more excited about browsers and the web would even love to contribute to it. But unfortunately stuff like this isn't what makes or breaks project success in the short or even medium term. I use Firefox as my main browser everywhere now, but I didn't make the jump on any technical merits in rendering. Most days I barely notice which browser I'm on. I use Firefox because of the principles it represents and Google finally crossed the final lines with me, ethically. I don't know what the future holds for Firefox and Mozilla but I don't think it's fundamentally strongly altered by the success of servo. In any case, as a software engineering community we need to find ways to fund big picture projects like Servo etc. without having them tied to the fortunes and whims of various corporations. We lucked out with Linux filling a niche where it could explode in popularity and be securely funded for dev, but that hasn't been the case with lots of other things.

chimeracoder 3y ago
> Do you really see a clear link from "better/safer/faster browsing rendering component" to "better revenues" or "better business situation" for Mozilla? Because I don't think I do, and I suspect Mozilla didn't either, really. Most people don't choose a browser based on principles or mission. Even if Firefox captured 100% of the market that did, it would barely move the needle in browser share. Most people choose browsers based on fairly straightforward things, such as the default (many people never change this, which is why changing the default browser via bundled downloads has remained such an effective marketing strategy for decades), performance, the feeling of performance (which is different from actual performance), whether the websites they're visiting are supported, etc.
- cmrdporcupine 3y ago
  Yeah, absolutely, which is why I think it's always going to be tricky for Firefox as long as there are corporate entities like Google and MS that have identified "having our own browser" as a competitive advantage. When Chrome came on the scene it was a huge improvement, and Google seemed mostly-benevolent then, and the core of it was open source. And I worked in that codebase and met some of the people involved, and they were all good very smart(er-than-me) people that I met. The core engineering project itself has good foundations. The problem is those folks gotta get paid. And so ultimately in the long run, Chrome has become the problem we always dreaded it would become. Which is why, yeah, "we" (for some definition of we) need to come up with a way that these kinds of projects can get paid for outside of places like Google etc. Mozilla almost feels like that, but from talking to the people I know who worked there... it's not.
  - bostik 3y ago
    > When Chrome came on the scene it was a huge improvement I don't think people in general realise how big a jump it was. Process isolation demonstrated that a browser with a single event loop is not a given, and the idea of completely separating page loads from page renders was, for want of a better term, a true paradigm shift. V8 showed that JavaScript didn't have to be disgustingly slow. I still remember the "Chrome Comic" booklet. Google made a big deal out of having hired some of the best compiler optimisation experts money could buy and pointed them towards a goal. V8 came out with two decades of hard-core, bleeding edge research behind it. It took Mozilla nearly a decade to catch up with multi-process Firefox (ironically, the project was called "Electron"). Chrome had the benefit of being a pure greenfield project. Firefox had to retrofit a completely different processing and rendering architecture that broke pretty much all previous assumptions. I recall writing a note to an internal Nokia-infused thread that "Chrome's process isolation is an idea too good not to steal". At the time I didn't know just how damn hard that would be to pull off without introducing multiple flag days. In the end Mozilla managed with one.

jcranmer 3y ago

> How does Gecko (the engine used in Firefox) fare on being embedded? I thought it wasn't as easy or simple, and hence one of the reasons why Chromium dominated in things like Electron. I haven't checked for a while, but it's pretty painful, especially because Mozilla kept changing their mind about how they wanted it to be embedded.

hn_go_brrrrr 3y ago
It's remarkable that Mozilla managed to be worse than Google in the "changing their mind" department.

kbrosnan 3y ago

As someone who worked at Mozilla the best way I heard it described is that Netscape designed the embedding to be monolithic. Something you built your app on top of. You best use all of Gecko, NSS, Spidermonkey, etc. Any path that meant your app needed to make changes to Gecko etc. was/is here be dragons territory. If there was some part that your app did not need disabling that part was unsupported and the effort was the the embedding app's responsibility. Where as Chromium was designed to be modular.

tuukkah 3y ago

Firefox had an Electron-like solution from 2006 to 2015 called XULRunner. Firefox and Thunderbird were built on top of the very same tech (XUL UI, XPCOM component object model, Sqlite databases, XPI extensions...) Then Electron came along around 2013. You get a backend using NodeJS (same V8!) and you don't need to learn XUL, XPCOM etc.