18 ms·

Ask HN: Why do new browsers use Chromium instead of Firefox as their base?

301 points by josemando 5y ago

Every time there is a post here related to Firefox, I see a lot of people complaining about the state of browsers and the utterly dominance of Chrome and Chromium based browsers. I’m wondering if that are technical reasons why the newish browsers (such as Brave or Edge) are choosing Chromium instead of Firefox as their starting point. If so, shouldn’t this be a priority for Mozilla to change that?

thrower123 5y ago
Chrome is easy to fork, Firefox is not. It's pretty much that simple.
- josemando 5y ago
  Could you care to elaborate a little more? What does it make it easy or hard to fork?
- gfosco 5y ago
  This was true, imo, ~2 years ago. Does not appear to be the case now, I recently went through the process with Firefox and the developer environment was very very friendly, would be straightforward to fork. (I shipped a Chromium fork in the past)
new_guy 5y ago
- USA-RedDragon 5y ago
  And you're saying Google's isn't the same? Mozilla and Google are both businesses whose primary goals are obtaining money. If you think that there are engineers specifically on the Chrome/Chromium team who ARE interested in the technology, what's the chances that there are engineers on the Firefox team who feel the same? My point being companies will always have to be monetarily-biased, and the hope is that the team working on the product itself still believe in it because they don't get much kickback from management's decisions about the technology.
  - cosmotic 5y ago
    Technically Mozilla is non-profit and thus technically not in the business of obtaining money.
    - readthenotes1 5y ago
      I'm pretty sure all non-profits are in the business of obtaining money.
      - cosmotic 5y ago
        Many non-profits will obtain money, but they purpose of the business is mainly things other than obtaining money. There definitely do exist non-profits that obtain more money than you would hope for a non-profit. Mozilla doesn't smell like such an organization to me.
        eloisant 5y ago
        Mozilla clearly exists to make as much money as possible for their employees (and in particular the leadership). I know, they claim their goal is to promote the Open Web and so on... But that ideal from the 2000's is long gone at Mozilla, when you see how the leadership is acting.
    - kevin_thibedeau 5y ago
      But the people controlling them are. Charity vultures find a way to divert the revenue stream into their pockets.
      - Melatonic 5y ago
        The big difference though is that they are not beholden to shareholder demands. Other peoples demands, sure
    - jonathankoren 5y ago
      Actually, the Mozilla Corporation, the entity that makes Firefox, is a for profit corporation that is wholly owned by the nonprofit Mozilla Foundation. It has this weird structure because the search deal makes too much money relative to donations according to IRS nonprofit rules. If B corps existed back when this structure was created, then they would have incorporated as that, but B corps didn’t exist then, and there’s no benefit to reincorporating as a B corp now.
stefantalpalaru 5y ago
BlackLotus89 5y ago
Gecko and servo are both not easily embeddable. Servo isn't a finished rendering engine yet and the browser I saw that could exclusively use servo was not compliant enough and since mozilla fired the servo team there is no certain future for it anymore. Projects that tried to make servo embeddable are all dead and gone (see https://github.com/paulrouget/servo-embedding-example https://github.com/paulrouget/servo-embedding-example for example) So yeah last time I tried to use gecko I failed and didn't try again (years ago) nobody is willing to do the work and mozilla seems to focus more on other stuff...
- ramesh31 5y ago
  >since mozilla fired the servo team there is no certain future for it anymore. When did that happen? It seems the managerial class has completed their takeover of Mozilla in the last few years. A real shame, since it basically cedes the entire web to Google.
gbraad 5y ago
The Mozilla rendering engine (gecko) was never meant to be embedded in the same way webkit is. It changed a little with Fennec and firefox. The engine became leaner... Yet still it isn't easy to reuse. Even spidermonkey, the javascript engine, is never reused as v8. Different design priciples
- josemando 5y ago
  But aren’t Brave, Edge and Opera based on Chromium instead of only Blink? Am I missing something?
  - mirashii 5y ago
    Blink is a part of Chromium, but not really a decoupled part. Having blink without the rest of Chromium isn't really possible at this time. Some details at https://www.chromium.org/blink https://www.chromium.org/blink https://www.chromium.org/developers/content-module https://www.chromium.org/developers/content-module
    - dundarious 5y ago
      I think the point is gecko is to blink, as firefox is to chromium. Sure, there are various browsers based on chromium out there, but they're not embedding blink. They're reskins of chromium with additional changes. How much more difficult is that compared to what goes into making iceweasel from firefox, I couldn't tell you. But the "embedding gecko is hard, embedding chromium is easy" explanation certainly seems to be wrong, in terminology at least.
- dralley 5y ago
  >Even spidermonkey, the javascript engine, is never reused as v8. GNOME and Cinnamon desktops use it, MongoDB uses it, polkit, etc. It's obviously not embedded nearly as much as V8 but it does have a few.
pipeline_peak 5y ago
I think Chromium’s performance contributed a lot to its dominance. Browser distributions have to build off of it to be relevant. Other than Ekioh’s Flow, I don’t know any other competitive attempts from companies building browser components from scratch.
- tata71 5y ago
  Performance & security, easy choice.
- olliej 5y ago
  The aggressive advertising on many of the most popular sites on the web also helped a lot, the occasional accidental breakage of other browsers on those same google properties also worked out in their favor.
loganmarchione 5y ago
At this point, more people are using Chromium, so more devs target it, so more browsers are based on it. However, in the beginning, Firefox’s engine (Gecko) was harder to embed than Chromium’s engine (Blink). https://www.reddit.com/r/firefox/comments/m8cwdu/why_arent_there_many_firefoxbased_alternatives/ https://www.reddit.com/r/firefox/comments/m8cwdu/why_arent_t...
pvg 5y ago
One reason is that Firefox is an older browser design (compared to Chrome), in parts retrofitted. That's a difficult, laborious rut to get out of, especially if your competition has more resources and a big head start. If you're starting a new browser variant, it doesn't make much sense to also start with Mozilla's disadvantage.
- shadowgovt 5y ago
  Chrome was architected specifically to overcome the shortfalls of the IE and Firefox engines at the time. Firefox has not only been playing catch-up, it's been playing catch-up against specifically its greatest weaknesses.
f0xtrot 5y ago
It seems that it's mostly the people building those browsers and their personal preferences. With google building a track record of shady tactics, I would agree. firefox seems the better choice. It seems no more difficult to fork than chromium (though I've never tried). My 2 cents, there's nothing to stop anyone from refusing to support updates on old frameworks and I'd suspect google to pull the rug out from beneath everyone before firefox anyday.
- olliej 5y ago
  Making a fork of a repository is super easy, but you need to have a reason. The core problem is that Gecko is not easily embedded. It does not strongly separate the renderer from the application, and that means that it is very difficult to simply use in the middle of another app. You can compare it to WebKit and the old mshtml controls: the entire engine is designed, specifically with the intention of being a content view in an application. Chromium inherited the core webkit design, so it is also much easier to embed than gecko. It requires much more work than a webkit webview, but that's largely down to exactly where they felt their API boundaries should be (e.g. a conscious design decision vs happenstance). The end result is that forking Gecko is useful if what you want to do is make a fork of Firefox. Using gecko for anything else is challenging - there used to be a Mac browser built on gecko, and it required a huge amount of work to keep going, and would routinely fall behind due to changes that broke embedding. Just a browser, so it still had the same basic UI structure, and it was still hard to make in the first place, and hard to maintain.
  - f0xtrot 5y ago
    What do you mean by "strongly seperate the renderer from the application"? is there a vs's? arent they protocols? implementations of a protocol should not change. my big gripe, chromium seems to make more analytics calls than gecko. are they grouping calls? probably. gecko/firefox doesnt seem to have this agenda. Doh along with super-cookie controls seem to out-perform chromium in every way. The end result seems to be privacy. embedded?? are you using ChromiumOs?
TAForObvReasons 5y ago
The answer is actually in the original Scott McCloud comic http://www.google.com/googlebooks/chrome/ http://www.google.com/googlebooks/chrome/ . A few highlights are on page 17 (about V8 JS engine) and 36-37 (about Chrome in general) Chrome/Chromium and its stack was designed to be easy to reuse and build upon. This may have been an explicit design goal because of the difficulties with reusing parts of Firefox and other software.
pcwalton 5y ago
As an engine, Chromium has overwhelming market share, so it decreases risk to build on top of it. Choosing an alternative browser engine increases risk. Embeddability has little to do with it; Chromium (as opposed to WebKit) isn't actually that embeddable. Rather, market share is king. With a high market share, the community will step up with projects like Electron and Chromium Embedded Framework that add embeddability.
- dfabulich 5y ago
  > Embeddability has little to do with it; Chromium (as opposed to WebKit) isn't actually that embeddable. No way. I remember the bad old days of XULRunner. In 2010, pre-Electron, it was literally easier to implement my own WebKit-based app from scratch in C++ than it was to follow the documentation and use XULRunner. Firefox's embeddability was bad. Really bad.
  - pcwalton 5y ago
    And Chromium's embeddability is just as bad. Notice you're talking about WebKit, not Chromium. Chromium doesn't even have a XULRunner.
    - dfabulich 5y ago
      Chromium Embedded Framework is Chromium's XULRunner. It was much easier to use and maintain than XULRunner, which is why it's still maintained to this day, and XULRunner is in the trash.
      - pcwalton 5y ago
        CEF is a third-party project that isn't officially supported by Google, unlike XULRunner. Which gets back to my point about market share: when you're popular enough, then people will step in to provide embeddability (in this case, CEF) on top of your non-embeddable product (Chromium). You could easily imagine an alternate universe where Firefox was the #1 browser and someone stepped in to write a Gecko Embedded Framework. The reason why Chromium Embedded Framework exists and Gecko Embedded Framework doesn't is market share.
junon 5y ago
Chromium is somewhat packaged as a library. Firefox and its internals are not.
dikei 5y ago
Firefox used to be extremely extensible: there were some software based on Gecko and Xulrunner. However, they all died out after Chromium and Electron took over.
- CmdrKrool 5y ago
  Xulrunner specifically, died or at least is not easily revived, because Mozilla killed XUL and XPCOM.
  - eb0la 5y ago
    There was even an Oreilly book about it: https://learning.oreilly.com/library/view/programming-firefox/0596102437/ https://learning.oreilly.com/library/view/programming-firefo...
jeffparsons 5y ago
It seems like everyone has reached much the same conclusion: there may be many factors, but the real killer and root cause is that Chromium is well suited to being embedded, and Gecko is not. So hey, any companies out there interested in bringing back a little diversity in browser engines? Or just making a tiny dent in Google's dominance for the greater good? Consider funding work to make Gecko better suited to embedding.
- pvg 5y ago
  real killer and root cause is that Chromium is well suited to being embedded, and Gecko is not. I don't think that's really the key problem since you don't have to build a new browser out of FF by embedding Gecko. FF itself is a browser that was made out of another browser, much of the old core Mozilla technology is basically a cross-platform app-building framework with one of the 'apps' being a browser. Somewhat unobviously, this turned out not to be a great way to build a browser in the long run.
  - toyg 5y ago
    > Somewhat unobviously, this turned out not to be a great way to build a browser It's actually great in the amount of flexibility and access it gives to 3rd-party developers to customize the browser itself. Unfortunately, the price seems to be complexity and rigidity in some critical areas (performance, embeddability).
- tyingq 5y ago
  >Consider funding work to make Gecko better suited to embedding Mozilla seems to choose what to do with donations though. I don't think there's any way to target funding for Gecko, Rust, etc.
  - ameliaquining 5y ago
    I think the suggestion being made here is that if somebody else did that work, they might be willing to merge it into their tree.
contingencies 5y ago
Out of the blue yesterday my phone asked me to rate Firefox. I think Google is trying to create a facade of competition where there is none by stuffing the Play Store review stats.
- andai 5y ago
  I've heard Firefox described as Google's "antitrust insurance".
- Melatonic 5y ago
  They funded Mozilla as far as I know for many years for exactly this reason
- gruez 5y ago
  Have you never been asked to rate apps before? I heard about google "randomly" asking people to rate restaurants they recently visited, so "randomly" asking people to rate apps they installed doesn't seem too out of the ordinary. It's definitely not enough to think "Google is trying to create a facade of competition where there is none by stuffing the Play Store review stats".
  - contingencies 5y ago
    No, I have never been asked to rate apps before. Perhaps because I am in China.
olliej 5y ago
The problem with gecko is that it is fundamentally challenging to embed as a standalone UI element. Too much of the "I am a browser" mentality gets into the rest of the engine. Chrome adopted the webkit model of being primarily an embeddable engine, that happened to have a browser as its primary use case. The WebKit framework is used extensively throughout macOS and iOS, across a variety of applications, precisely because the framework is designed as a content view, not as a browser.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
andrewmcwatters 5y ago
I had a conversation here with people about Servo and it was immediately clear that it was a collection of people who wanted to play around with Rust and not actually solve a problem that people have while saying that they did. They were way more concerned with bullshit like governance than meat and potatoes like writing a getting started article. > Servo’s mission is to provide an independent, modular, embeddable web engine, which allows developers to deliver content and applications using web standards. This is servo's mission, on their website, and the last time I checked, they provide absolutely no documentation on how to actually do it. If you need embedded, just use CEF like everyone else. If you need a browser base, just use Chromium. Everyone else is dicking around. I would have written a WebKit port[1] for my own purposes, because CEF has significant technical limitations, but WebKit has no documentation on how to do it either. They have documentation on what a WebKit port is, and what ones exist, but not actual documentation on how to create your own callbacks for view abstraction and blitting etc. It's a much more significant effort compared to just using CEF. [1]: https://trac.webkit.org/wiki/SuccessfulPortHowTo https://trac.webkit.org/wiki/SuccessfulPortHowTo
- tylerchilds 5y ago
  The documentation on how to run it is in the readme. They've only got pre-release builds available on their website, since the tech isn't production ready yet. I've been compiling it locally and playing with it. I run it like: $ servo https://news.ycombinator.com https://news.ycombinator.com To do that, I've got an alias set up to point to my dev build. alias servo='f() { /home/tychi/SourceCode/servo/mach run --release $1 };f'
  - edoceo 5y ago
    The question was how to Embed servo, not how to Run servo
victorbstan 5y ago
Wasn’t chromium based in WebKit? Same as Safari. Basically Apple forket webkit to make safari and Google forked WebKit to make chromium. I really don’t see what the hubbub is about trying so hard to have gecko, webkit, etc. rendering engines out there. If the end goal is standards compliance, the outcome should be the same. The fact that Google did such a good job on early chrome compared to everyone else is really why it’s so popular. Ultimately it’s open source. I think chromium could become more popular than it is, if they upped their marketing and made access to up to date binaries as frictionless as possible for as many platforms as possible.
- robertoandred 5y ago
  Apple forked KHTML to make WebKit, which it used to make Safari. Google originally used WebKit to make Chrome, but then forked WebKit to make Blink, which it uses for Chrome now.
- dikei 5y ago
  > If the end goal is standards compliance, the outcome should be the same. The problem is Google is using Chromium dominant market share to push some questionable "features" into standards. > The fact that Google did such a good job on early chrome compared to everyone else is really why it’s so popular. Chrome is good, but Google being the largest advertising machine in the world also helps.
pkaler 5y ago
Chromium embeds the Blink browser engine which is a fork of WebKit which is a fork of KHTML. You can read Creative Selection by Ken Kocienda to get the backstory on why they chose KHTML over Gecko. You can also Google for podcasts that Don Melton has been on.
- Someone 5y ago
  > on why they chose KHTML For those who don’t know: “they” is Apple here. Apple forked KHTML to create WebKit. Google contributed to WebKit and later forked it into Blink.
pilingual 5y ago
Security. The world class team that is responsible for protecting the iPhone protects Chromium.
- sofixa 5y ago
  What does that mean? Google and Apple are different companies with different security teams. Are you talking about Google's Project Zero? If so, you can include lots of software with that logic, and it would make even less sense to say that "the world class team that is responsible for protecting Intel processors protects Chromium".
pentagrama 5y ago
I'm wondering, Tor [1] is a Firefox based browser in the same sense as Edge/Brave/+ are based on Chromium? [1] https://www.torproject.org https://www.torproject.org
- LeoPanthera 5y ago
  The difference is that Tor Browser is Firefox, it's not Gecko embedded into a new one. TB is just FF with a bunch of minor (compared to the whole codebase) changes.
csdreamer7 5y ago
As others have said; Gecko and Servo are not easily embeddable. That was Apple's reported reason for using KHTML and making WebKit which Google used for Chrome and forked eventually. They wanted something light and embeddable. Don't blame them. Also, that software was LGPL. I was always hoping that Microsoft or Apple would fund the Mozilla Foundation to keep a competitive web engine afloat and prevent Google Chrome engineers from dominating the web. They can take the Firefox code for their closed source software under the MPL. Really doubt MS is going to do that these days. Kinda hoping Apple does since Safari is often the last to support new web standards. It would take very little of their profit and yet keep a big competitor from dominating a critical function of their most profitable products. This is regardless if they actually use Gecko or Servo.
- starik36 5y ago
  > Gecko and Servo are not easily embeddable. That's right. And the Safari team chose KHTML despite the presence of Dave Hyatt - a key Firefox developer and creator of Camino browser (which did embed Gecko). That's probably everything one needs to know about how easily embeddable Gecko is.
- tannhaeuser 5y ago
  > Safari is often the last to support new web standards Where "web standards" are "whatever Chrome does", and written by Chrome devs. There you've also got the reason nobody starts from the FF/Gecko/Servo codebase.
  - getcrunk 5y ago
    Yea there's no reason other than greed to not fully implement pwas, local storage over 500mb, and native share intents to pwa
novok 5y ago
I only use firefox because of it's multi-account container capabilities and some other better privacy features, which is more to do with it's wrapper vs. it's actual engine. Someone could make multi-account containers or better with chromium, and if they did I would just use that instead. Otherwise firefox is a slower, less secure browser and an older more crufty codebase and less webdevs test it thoroughly. Why would I choose it as a new browser wrapper developer ever?
- ipaddr 5y ago
  Using those containers might be making your firefox experience slower. The very reason you use it might make you think you shouldn't use it for anything else. If you used it without containers I wonder if you would think it's faster. Each container has it's own resources. How can it be less secure and the browser you choose for privacy reasons only?
  - bryanrasmussen 5y ago
    I would say it means that obviously Google wants to track all your personal info but they work really hard and expend a lot resources to be sure it's safe from everyone else, also some attacks are done to not get your info but just to wreck stuff.
  - novok 5y ago
    Multi-account containers are separated cookie/state jars that auto spawn on tabs based on URL rules , they don't need a lot of resources other than maybe kilobytes or a few MB of extra memory per account container. CPU wise and overall memory wise it isn't much.
- unethical_ban 5y ago
  >Otherwise firefox is a slower, less secure browser I'd like to see citations on that - AFAIK (my opinion is as baseless as yours) FF is plenty fast on desktop, and there is nothing inherently less secure about it than Chrome. I do use Vivaldi (based on Chromium) on Android, but I consider Firefox Mobile and Desktop to be separate products.
commoner 5y ago
While embedding Gecko in desktop applications is not as straightforward as embedding Chromium, Mozilla's GeckoView project makes it easier to do this on Android: https://mozilla.github.io/geckoview/ https://mozilla.github.io/geckoview/ GeckoView is the foundation of Firefox for Android and Firefox Focus. The SmartCookieWeb-Preview browser, which supports sideloading Firefox extensions on Android, is also based on GeckoView: https://github.com/CookieJarApps/SmartCookieWeb-Preview https://github.com/CookieJarApps/SmartCookieWeb-Preview
- iggldiggl 5y ago
  But then again on Android the OS already provides a Webview implementation for usage by apps, so while on Android Gecko might be more easily emebeddable than on Desktop, it's then hobbled by the fact that on Android the choice for app developers is either using the default Chrome/Blink-based Webview provided by the OS at absolutely no size-penalty, or else thinking about shipping a full browser engine with your app at a size penalty of dozens of MB, at which point you might then consider possibly using GeckoView instead of shipping your own specific version of Blink.
  - toastal 5y ago
    Can this be offered as a library that many apps could share?
    - iggldiggl 5y ago
      No idea. With flash this certainly used to work (i.e. Adobe distributed an APK with the Flash plugin, and other browsers including Firefox were able to use the library contained therein), but of course Flash has been discontinued for quite a while now and I don't know whether a similar approach might still work with the most recent versions of Android. In any case though this would raise the backwards compatibility constraints on Mozilla quite a bit, and I'm not sure whether they'd be willing to take on that burden. Of course even now they can't go around breaking GeckoView-APIs all willy-nilly, but when it does happen, it "only" affects app developers the next time they want to recompile their app with a newer GeckoView version. If GeckoView was being distributed as an independently, user-installable library instead, any breakage at all becomes a big no-go, because users naturally expect their existing GeckoView-using apps to keep working regardless of which updated version of GeckoView they might happen to install.
baq 5y ago
Servo should be developed for taxpayers money just to keep Google honest.
shp0ngle 5y ago
That's simple. Gecko is awful to embed and use independently of Firefox. Now my question would be why not WebKit, as that is also easy to embed. There are browsers that use WebKit, just not that many.
- dragonwriter 5y ago
  > Now my question would be why not WebKit, as that is also easy to embed. There are browsers that use WebKit, just not that many. Wasn’t part of the WebKit/Blink split that Google cared about supporting non-Apple platforms and Apple didn’t want to anymore, (and the reverse on a number of Apple-priority features), and both sides purged their post-split engine codebases of the stuff they weren’t supporting, making post-split WebKit very much not suited to non-Apple platforms.
  - sanxiyn 5y ago
    This is incorrect. Conflict was over multiprocess architecture, where Google added it as a WebKit port and Apple did a proper redesign and produced WebKit2. WebKit is still extremely portable and non-Apple platforms are first class.
    - dragonwriter 5y ago
      I thought platform support was part of it, too, but I must have been mixing up the abandonment of non-Apple-platform Safari with the Blink/WebKit fork.
  - shp0ngle 5y ago
    Ah, that might be it. Quick googling (not any in-depth knowledge) tells me that WebKit is for Linux too, I cannot find out anything about Windows.
Donckele 5y ago
I’m calling bullshit to most of the comments here and to Mozilla. First, why cannot we have a multi-platform single click, no chrome/ui with fullscreen capabilities, firefox launcher that has prepackaged web app that is self contained? You think Major Tech Dudes can’t implement this? Second, it’s all probably to do with bureaucracy and politics. For all we know FAANG blocks such ad ventures otherwise its bully time.
- stonogo 5y ago
  We had it. It was called Prism: https://wiki.mozilla.org/Prism https://wiki.mozilla.org/Prism It died when XulRunner died, and none of the followon attempts survived.
luka-birsa 5y ago
We had to choose between Webkit and Gecko. For us it was primarily the license, which was GPL vs MIT. Gecko was a non starter.
- ptman 5y ago
  I thought mozilla projects, including firefox and gecko are GPL/MPL dual licensed? Where MPL is close to LGPL https://tldrlegal.com/license/mozilla-public-license-2.0-(mpl-2) https://tldrlegal.com/license/mozilla-public-license-2.0-(mp...
- anhner 5y ago
  Why was GPL better than MIT?
  - conradludgate 5y ago
    From what I can see its actually LGPL vs MPL which are similar in end goal, of being viral when modifying and distributing the project as is, but integrating the library into an application can allow for a licence change
    - dralley 5y ago
      > of being viral when modifying and distributing the project as is That's not what "viral" means. MPLv2 cannot "infect" your own code like the GPL can just by virtue of using the library. The only condition is if you want to make modifications to MPLv2 licensed code files, you do have to retain the license on all contributions.
- deleted 5y ago
  [deleted]
frizlab 5y ago
Interestingly, both the new browser Orion and the one DuckDuckGo is developing are WebKit-based, not chromium-based.
- benbristow 5y ago
  Orion seems to be Apple (MacOS/iOS) only - makes sense.
NetOpWibby 5y ago
Mozilla’s priorities are questionable, I’m not sure anyone outside the company knows. I’ve long resisted using a Chromium browser but Firefox has languished for far too long. I’ve been using Arc for maybe half a year now and I don’t plan on going back. Without a team working on Servo, Mozilla is lost IMO.
- throw8932894 5y ago
  Recently Mozilla decided it does not want donations :) Great for woke bs, not so great for actually funding and developing browser.
  - throwaway946513 5y ago
    Where was this headline?
    - NetOpWibby 5y ago
      https://twitter.com/mozilla/status/1479143340159422468 https://twitter.com/mozilla/status/1479143340159422468
    - olennolla 5y ago
      https://www.theverge.com/2022/1/6/22870787/mozilla-pauses-crypto-donations-backlash-jwz https://www.theverge.com/2022/1/6/22870787/mozilla-pauses-cr...
aero-glide2 5y ago
Chromium works better on more websites (especially ones with 3d models)
causi 5y ago
On June 21st, 2011 Mozilla decided that Chrome would lead and Firefox would follow. Almost every single change to Firefox since then made it more similar to Chrome, not less. If you're making a browser, you follow the leader, not the first follower.
- edoceo 5y ago
  What happened on that day? Is there more historical details?
  - bacchusracine 5y ago
    >What happened on that day? Is there more historical details? Not the guy but a quick search pulls up a press release for that day which was the release of Firefox v4.0 and mentions the 'new' rapid release cycle. I'm assuming it was this last that they were referring to. Link: https://blog.mozilla.org/press-uk/2011/06/21/mozilla-delivers-new-version-of-firefox-first-web-browser-to-support-do-not-track-on-multiple-platforms/ https://blog.mozilla.org/press-uk/2011/06/21/mozilla-deliver...
kiwidrew 5y ago
Mozilla (the org) never supported any of the "make Gecko embeddable" initiatives.
daoismyname 5y ago
It's what happens when you fire you engineer CEO for his personal opinions (that I disagree with) and replace him with a "company culture" that has nothing to do with engineering, but has the "right" opinions.
- Barrin92 5y ago
  Firefox became competitive again on a technical level after the overhaul with 57 long after Eich was gone, and under Eich the browser was already in a steady state of decline for a long time both technologically and in terms of usershare. Trying to ride old stereotypes about engineers and management that has nothing to do with facts is pretty cringeworthy.
  - daoismyname 5y ago
    Guess which one is better in 2022, Firefox or Brave? (except maybe containers) Firefox was born in 2002 (under Eich management) as Phoenix, it's kinda obvious that 16 years later (57 is from 2018, Eich left in 2014) it needed a technological upgrade. In ~2009-2010 Firefox was used by 33% of the web users. Today it's at ~6%. I blame management, the alternative is believing Firefox just had bad luck or that developers at Firefox suck (which they do not)
    - mschuster91 5y ago
      > I blame management, the alternative is believing Firefox just had bad luck or that developers at Firefox suck (which they do not) There are other factors at play than managerial incompetence: - the entire iOS part of "all web users" uses WebKit because Apple doesn't allow other engines. For Android, most devices ship either Chrome or a WebKit wrapper (the default Android WebView), and many users don't bother switching browsers from the default. As ever more Web usage moves towards mobile, the disadvantage towards Firefox only accelerates - which is part of the reason why Mozilla tried to build a competitor. - Many users also don't bother very much to switch their desktop browser. Apple users, especially on mobile, tend to stay with Safari as not even Chrome can keep up with the battery life optimizations Apple did, much less Firefox (not to mention Apple probably doesn't even grant non-Apple apps access to entitlements, but that's just guesswork). - Netflix and other DRM content. A lot of people went to Chrome back in ye olde days when getting Netflix to run in HD resolutions (or at all) was a nightmare on everything sans Chrome (and Internet Explorer), and thanks to inertia (see above) they stayed on Chrome. And I'm not even wishing to fault Mozilla's management for resisting DRM for as long as they did, but in the end customers voted with their download buttons for convenience. - The desktop users that do switch their desktop browser switch mostly to Chrome because Google blasts out tons of ads to switch to Chrome, not to mention website developers suggesting their users to move to Chrome or outright announcing that bugs involving browsers other than Chrome won't get addressed. The last thing is undoubtedly the biggest issue - it is impossible to counteract the advertising and other financial firepower of Google. In ye olde times, regulatory agencies should have stepped in long ago to ban the cross-promotion that Google did (similar to the MS judgements), but they didn't and now we're living in a browser duopoly that is rapidly devolving into WebKit monopoly.
GoblinSlayer 5y ago
Because Chrome has bigger market share, webdevs test their stuff only in Chrome, as a consequence their stuff works only in Chrome. Browsers have to be based on Chrome or suffer incompatibility problems, and sometimes even that doesn't help as some sites block browsers based on user agent strings if they detect it's not true Chrome.
vorticalbox 5y ago
sometimes I feel like it would be better for everyone if we had one engine that all browser makers contributed to. This would mean that there is only one engine that needs to keep up to date with the html/JavaScript spec and then browsers would then be competing on features rather than if a web site will render correctly.
egberts1 5y ago
As one who inserted numerous test instrumention points through out SpiderMonkey JS executable, I can vouch for the extreme nastiness build procedure made by and of Modzilla Firefox build team, not only code-wise but interaction-wise. It’s a bit easier nowadays but still in no way portable for suitable embedded use.
moonchrome 5y ago
>If so, shouldn’t this be a priority for Mozilla to change that? I would flip that and say Mozilla would be better off if they just adopted Chromium and made sure they provided builds without the controversial stuff. They gave up on having a competitive rendering engine implementation when they abandoned Servo so why bother ? Who is using FF for the rendering engine ? If anything it just breaks compatibility because few test for it anyway. They even fired the devtools team so developing for FF is worse than Chrome. If they created a Chromium distro that was cleaned up for privacy it would probably be a better product than what they have right now.
BrendanEich 5y ago
Brave started in 2015 on Gecko, using Graphene (FirefoxOS multiprocess/sandboxed app framework). We switched by end of year due to too many gaps (HTML5 DRM was a big one) and incompatibilities (mobile, mostly). Big spreadsheet, most rows netted out negative for Gecko. No way to change now, and a worse bet now based on Mozilla fundamentals.
davebailey 5y ago
The Firefox engine sucks. It's resource intensive, buggy, and doesn't play nice with other technologies... think Flash. Even the former CEO of Mozilla who left and created the Brave browser decided to go with Chromium. Right now- the only browser engines seeing a lot of action are Chromium and WebKit. Every browser is being built on one of these two engines. I suspect even Firefox will switch over to gain the benefits of one of those engines and the number of people working on them.

Dylan16807 5y ago
In 2013 Mozilla spent $197M on software development and $30M on general/administrative. In 2020 it was $242M and $137M. The future-focused servo team was not the place to cut a couple million.
- dotancohen 5y ago
  > In 2013 Mozilla spent $197M on software development and $30M on general/administrative. > In 2020 it was $242M and $137M. > The future-focused servo team was not the place to cut a couple million. Wasn't it just after 2013 when the replacement politically-correct CEO got quadruple the pay of the not-politically-correct engineer CEO?
  - smcl 5y ago
    That's a bit of an oversimplification, it's not like they had a choice between adequately funding R&D projects or Doing Political Correctness and chose the latter. Besides, remember that Eich was appointed in 2014 and had only a short stint at CEO, so I don't think you can attribute the 2013 figures to him I think all of us on HN are a bit saddened about Mozilla cutting back on the Rust and Servo teams, but political-correctness isn't the reason behind that. Let's not turn this into one of those discussions.
    - leeroyjenkins11 5y ago
      They did give like a 10k grant for people to remove master/slave terminology from docs, so who knows what other PC work they were funding.
      - ramesh31 5y ago
        >They did give like a 10k grant for people to remove master/slave terminology from docs, so who knows what other PC work they were funding. As a black person in tech, I can't tell you how much that whole debacle drives me insane. I never once in my life ever made the association between "master branch" and "slave master". But now every single time I pull a repo with a "main" branch instead of "master", I have to think about it and play along to assuage someone's white guilt. I absolutely refuse to ever make the switch.
        acdha 5y ago
        I think changing the default in Git was fine — it's such a small amount of work and doesn't affect existing projects — but what I really wish was that more people had taken this as the cue to ask what “master” even meant for their project. I've tried to switch my projects to names which actually describe what we use them for — e.g. tracking branches like development, staging, production representing what is currently being deployed to those environments — and that's been far more worthwhile because it brings clarity to discussions and simplifies things like CI/CD scripting.
        dotancohen 5y ago
        As someone whose grandfather was an actual slave, I agree with this 100%. If I pull a repo and find "main" I have to WTF and be reminded again that somebody somewhere has a guilty conscience. I would have preferred that they keep their guilty conscience to themselves and let us work without constant reminders of the chip on their shoulder.
        smcl 5y ago
        I think I can set your mind at ease on this one. If you see "main" instead of "master" then I can almost guarantee that it's not someone with a guilty conscience believing that naming their branch differently absolves them of something they or their ancestors did. But rather it's someone trying to follow a broader movement whose aim is to try to avoid terms they think are rooted in hatred or oppression. If you're getting harrassed by someone because you've got some repos with a "master" branch then I sympathise with you - the people giving you shit are likely engaging in a bit of performative outrage and don't really understand what this is all about. However if you're really getting upset when you clone a repo and see that someone's named it "main" then I have to say that might be on you.
        Dylan16807 5y ago
        > I can almost guarantee that it's not someone with a guilty conscience believing that naming their branch differently absolves them of something they or their ancestors did. "white guilt" doesn't necessarily care if their ancestors did it. > But rather it's someone trying to follow a broader movement whose aim is to try to avoid terms they think are rooted in hatred or oppression. It's annoying and sigh-inducing to be reminded that such a movement is full of people that don't understand how words work, that "master" has plenty of perfectly good contexts that don't imply "master/slave". > However if you're really getting upset [...] that might be on you. Nobody is "really getting upset" and that entire part of your post is needlessly insulting.
      - acdha 5y ago
        This is a silly conspiracy theory if you think about it even a little bit. The grant you're referring to was $15K grant to Buildbot, which Mozilla has used heavily for years, and that was both to update terminology and “also to make improvements so Buildbot works better in the Amazon EC2 cloud” — guess which one is more work? — and $15K is a big amount to an open source maintainer but tiny when you're talking about budgets measured in hundreds of millions of dollars. You don't solve major budgetary issues by going after tiny fractions of one percent when there are individual people making orders of magnitude more money. Mozilla is also one of the most open companies in our field — given how often we read about far less significant events there, it seems incredibly unlikely that there's some sort of substantial but well-concealed dark funding of “PC work” which has remained secret even after, say, lots of people being laid off or leaving especially when such work would by necessity have visible impacts.
- lifthrasiir 5y ago
  I wouldn't be this cynical if everyone said the same thing to the Firefox OS back then. It turned out that Firefox OS did have much potential to countries with less mobile penetration, as observed from KaiOS's success in India. Was the Firefox OS less future-focused than Servo? I don't think so, and given that Servo actually did survive long enough to give back to the mainline Gecko (in the form of WebRender and so on). It might or might not make actual sense to conclude that as the ROI shrinks, but it is always easier to claim the decision was wrong after that decision.
  - toyg 5y ago
    Well, many claimed that back when decisions were being taken. They could have scrapped FFOS much sooner than they did. > Firefox OS did have much potential to countries with less mobile penetration, as observed from KaiOS's success in India. Such "success" is inevitably fleeting. Eventually a "developing" market develops to demand more established and desirable products. Nokia had those markets under lock and key for a long time, back when EU/US had already moved on to iPhone-like products; but then consumers inevitably gravitated towards the fashionable.
    - thematrixturtle 5y ago
      Not if the platform can leverage its position to move upmarket, as Japanese, Korean and now Chinese manufacturers have.
    - acdha 5y ago
      > Nokia had those markets under lock and key for a long time, back when EU/US had already moved on to iPhone-like products; but then consumers inevitably gravitated towards the fashionable. “fashionable” is the wrong word: it should be “functional”. Those old Nokia phones were very good at being phones but that's it — maybe a minimal messaging app, but anyone who used one knows just how limited those old mobile OSes were. I think FirefoxOS was an interesting idea but there are really important thresholds you need to be able to hit and that was the critical error they made. There was no plausible way to grow the low-end feature phone market into a large enough business to get there when competing with cheap knock-off Android devices. If they'd started years earlier or gotten a major vendor on-board, maybe, but at their funding levels there was no way to make the numbers work and it was pretty clear at the time that this was a low-probability gamble.
- elb2020 5y ago
  It seems to me, that once a company reaches a tipping point of more than 50% non-engineers in upper management, it's the demise of the company as an engineering company, and it will slowly drift in the direction of being a technology holding company only.
- iamdanieljohns 5y ago
  where can I find this statistics?
  - Dylan16807 5y ago
    https://foundation.mozilla.org/en/who-we-are/public-records/ https://foundation.mozilla.org/en/who-we-are/public-records/ https://www.mozilla.org/en-US/foundation/annualreport/2020/ https://www.mozilla.org/en-US/foundation/annualreport/2020/ All the "audited financial statements". It should be the second full-page chart.

thayne 5y ago

That non embeddability is probably also a major reason why there isn't a significant node competitor based on spidermonkey. I get wanting to focus on Firefox as a whole, and that making components more independent can add quite a bit of work. But at the same time, if it was easier to use gecko in other browsers, and spidermonkey as JS environment outside the browser, I wonder if that would increase usage of and interest in the underlying technology.

nyanpasu64 5y ago
Interestingly there was a (never finished) Node fork based off SpiderMonkey (https://github.com/mozilla/spidernode https://github.com/mozilla/spidernode had to write a V8 shim on top of SpiderMonkey), and GNOME Shell and some GNOME apps are written on gjs which uses SpiderMonkey. I don't know if it's bad at embedding compared to V8, but it's definitely been done.
sanxiyn 5y ago
MongoDB embeds SpiderMonkey. Embeddability of SpiderMonkey is fine. It is Gecko that is the problem.
- frankjr 5y ago
  Interestingly, MongoDB switched from SpiderMonkey to V8 only to switch back a few releases later. https://engineering.mongodb.com/post/code-generating-away-the-boilerplate-in-our-migration-back-to-spidermonkey https://engineering.mongodb.com/post/code-generating-away-th...
mijoharas 5y ago
We embedded spidermonkey as the JavaScript engine for the prime video application on games consoles and smart TVs when I was at Amazon (5 years ago+ not sure if they still use it). I've not embedded any other JS engines, but it wasn't too bad to embed.
- mijoharas 5y ago
  Actually, I just realised what I said above was slightly inaccurate, we also built an application that embedded CEF, so I technically have embedded another js engine (that was 7+ years ago though, and my memory is spotty). CEF was also relatively straightforward to use. Both times we were embedding them in C++ applications.
CrzyLngPwd 5y ago
I embedded it in https://digiguide.tv/products/windows.asp https://digiguide.tv/products/windows.asp around 20 years ago. Aside from thread-wrangling I thought it was trvial to embed.
- motiejus 5y ago
  > 32mb RAM and 8mb Disk Space. I miss such numbers so much.
toyg 5y ago
This was the biggest fumble of the Mozilla strategy in the last 20 years. Instead of focusing on the developer market, particularly after the appearance of WebKit, they bet (half) the farm on a quixotic quest to build a mobile OS from scratch. By attempting to gain a level of control that was always unlikely, they endangered their own survival.
- toastal 5y ago
  KaiOS though has had success. If anything FxOS was ahead of its time and targeting a market too small.
- elevaet 5y ago
  I would have made that same mistake if I was making decisions for Mozilla at the time. It's such an elegant, logical and tempting ideal to turn the browser into the OS. Too bad it didn't work out.
  - zdkl 5y ago
    Well, now we have PWAs. I'd be more than a bit bitter if I was a mozilla dev tasked with making those work on android/ios instead of on firefoxOs.
    - toastal 5y ago
      Good luck getting Apple to allow basic features like storage without weird limits, notifications, and the rest of the list. They killed Flash in favor of HTML5+JS and then decided for the walled garden.
kunagi7 5y ago
Spidermonkey is quite embeddable by itself [1]. On Linux things like polkit, couchdb, mongodb use it. Still, the compilation process seems to download the whole firefox tarball and only compiles the JS related parts [2, 3]. [1] https://spidermonkey.dev https://spidermonkey.dev [2] https://archlinux.org/packages/extra/x86_64/js78/ https://archlinux.org/packages/extra/x86_64/js78/ [3] https://www.linuxfromscratch.org/blfs/view/svn/general/js78.html https://www.linuxfromscratch.org/blfs/view/svn/general/js78....
- donatj 5y ago
  Another helpful link for your stack https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples https://github.com/mozilla-spidermonkey/spidermonkey-embeddi...
- thayne 5y ago
  And the fact that polkit uses it is why debian and ubuntu use an ancient version of polkit. And fwiw, there is an effort to replace spidermonkey in polkit with something else, like duktape. Also js78 uses the version of spidermoneky from Firefox 78. The current Firefox ESR is 91 (released in august), but I don't see any js91 package, and https://github.com/mozilla-spidermonkey/spidermonkey-embedding-examples/blob/esr78/docs/Building%20SpiderMonkey.md https://github.com/mozilla-spidermonkey/spidermonkey-embeddi... still says to use the 78 ESR. Note that ESR78 is end of life and no longer receives security updates. And from what I understand, there is no attempt at backwards compatibility in the spidermonkey interface, so each upgrade requires a lot of changes to the embedding program. Yes, it is possible to embed spidermonkey, but there are a lot of challenges.

bostik 5y ago

> root cause is that Chromium is well suited to being embedded Bingo. Let's not forget, Chromium itself is built off a fork of kHTML, the rendering-engine-as-a-library originally developed and used by KDE project. Apple forked kHTML and released WebKit. That gave the world Safari. Not long after, WebKit became the engine powering Chromium/Chrome, but with process isolation and high-octane JavaScript interpreter (V8). Then quite some time later, frustrated by Apple's control over the engine, Google forked WebKit and came out with Blink. Sometimes the only difference between provenance and history is the written narrative.

toyg 5y ago
Yeah, WebKit really tilted the scale. KHTML had been built to be easily embeddable already (since it was supposed to be used across the whole KDE desktop, following what MS had done with "Active Desktop" in Windows 2000/XP), and Apple gave it the polish and popularity to make it the obvious choice. Any org or ecosystem who needed a rendering engine rushed to wrap WebKit, and that included Google.
darklion 5y ago
> Then quite some time later, frustrated by Apple's control over the engine, Google forked WebKit and came out with Blink. I see you've bought into Google's historical revisionism. When Google introduced multi-process rendering into Chrome, it was a massive technical innovation, but it was built at such a low level that it was effectively proprietary to Chrome. No one else could use it without pretty much adopting all of Chrome. Apple (along with the rest of the technical world) recognized the benefits of multi-process, but Apple wanted to ensure that literally anyone building a WebKit-based browser could gain the benefit of multi-process rendering. So they created WebKit 2 [1]: "WebKit2 is designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process. This model is similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients to use it." In other words, Google's main technical advantage would be baked into the browser engine itself and made available for everybody. As you can imagine, Google was less than thrilled, and the differing natures of the multi-process implementation led to duplication and complexity. So, when Google decided that supporting multiple architectures was too much work, it had a choice. Google could do the hard work of switching Chrome's multi-process rendering to WebKit 2, which would mean a significant browser rework, but it would mean that any and all browsers derived from WebKit would have all of the same basic capabilities, and at the same level, as Chrome itself. Or, Google could use it as an excuse to proprietize its work by forking, thus ensuring that any future stream of enhancements made to the browser would only benefit Google and Chrome instead of everybody. In the end, Google decided that the only thing it cared about was itself: "However, Chromium uses a different multi-process architecture than other WebKit-based browsers, and supporting multiple architectures over the years has led to increasing complexity for both the WebKit and Chromium projects. This has slowed down the collective pace of innovation - so today, we are introducing Blink, a new open source rendering engine based on WebKit." So remember, when Google made a proprietary technical leap in an otherwise open source project, it was Apple, not Google, who made sure that everyone could benefit from the same technical leap. And when it became too difficult to maintain two versions, it was Google, not Apple, who forked the engine and the community in order to proprietize improvements for their own gain. -- [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012235.html https://lists.webkit.org/pipermail/webkit-dev/2010-April/012... [2] https://blog.chromium.org/2013/04/blink-rendering-engine-for-chromium.html https://blog.chromium.org/2013/04/blink-rendering-engine-for...
- magicalist 5y ago
  > In other words, Google's main technical advantage would be baked into the browser engine itself and made available for everybody. This is a bit of a silly narrative built on what's basically different architectural decisions. Chrome embedding was intended to be through CEF (which was fully multi-process), while WebKit through WebCore. You could just as easily say that Apple decided not to do the hard work of migrating Chrome's multi-process architecture into WebKit and instead made a hard break and just started landing incompatible changes. From the thread you posted, you can even see a WebKit embedder at KDE blindsided by the news[1]. But in reality, browsers are hard, and in a way WebKit and Chrome were always forks but with shared components. The Blink fork was just a fork of one of the biggest of those components and a formalization of what was pretty much always the case by moving to separate source control, code review, etc. [1] https://lists.webkit.org/pipermail/webkit-dev/2010-April/012248.html https://lists.webkit.org/pipermail/webkit-dev/2010-April/012...

smcl 5y ago
> "white guilt" doesn't necessarily care if their ancestors did it. Honestly don't know what you're getting at here. You're going to have to spell this one out to me. > It's annoying and sigh-inducing to be reminded that such a movement is full of people that don't understand ... that "master" has plenty of perfectly good contexts I don't disagree. See my comment about people engaging in performative outrage, it does exist. But in this case you're annoyed at the very sight of the word "main". Like ... c'mon > Nobody is "really getting upset" and that entire part of your post is needlessly insulting. Are you misunderstanding that "However if you're really getting upset ..." means "However you're truly getting upset ..." and not "You're getting really upset ..."? Additionally if you read my comment, I provide two interpretations: 1. they exclaim "WTF" when attacked for having named a branch "master" (IMO understandable) 2. they exclaim "WTF" at the very sight of a branch named "main" (IMO a bit silly) I honestly don't know which is the right one. It is up to the commenter if they want to tell us which it is. Update: and just like that this part of the thread has become the farce I feared it would, we are debating whether the words "main" and "really" are offensive. This is a very important thing to consider when answering the question "Why do new browsers use Chromium instead of Firefox as their base?"
- Dylan16807 5y ago
  > Honestly don't know what you're getting at here. You're going to have to spell this one out to me. You said "I can almost guarantee that it's not someone with a guilty conscience believing that naming their branch differently absolves them of something they or their ancestors did." but the accusation of doing it out of "white guilt" isn't really saying they were trying to absolve themselves of something their ancestors did. > I don't disagree. See my comment about people engaging in performative outrage, it does exist. But in this case you're annoyed at the very sight of the word "main". Like ... c'mon Annoyance is pretty mild. If seeing it reminds me of it, what do you expect to happen? I don't think that's unreasonable. > Are you misunderstanding that "However if you're really getting upset ..." means "However you're truly getting upset ..." and not "You're getting really upset ..."? I understand that. By even bringing it up you're implying it's necessary to worry about people "truly getting upset" which is not saying great things about your opinion of your conversation partners. I mean look above where you said "c'mon", you're implying that it's unreasonable for me to be "annoyed". > Additionally if you read my comment, I provide two interpretations: And I was talking about interpretation 2 specifically. I interpret "I have to WTF" as something akin to a double take, not "truly getting upset". > This is a very important thing to consider when answering the question "Why do new browsers use Chromium instead of Firefox as their base?" Shrug.