Hacker News Reader

That's a real missed opportunity. Firefox would have made a fantastic embedded webview, and could have plausibly become the core of Electron. Back when webviews were IE, with atrocious Javascript support and all the usual IE quirks, Firefox was a superior product and interconnecting with other software is very in line with the open source ethos.

That opportunity is still there.

Enough features to distinguish on, enough political/managerial reasons for choosing an independent FLOSS engine over one controlled by Google.

Sure, Edge/MS won't move to this engine anywhere soon. Nor will Brave switch over tomorrow, or electron rebuild around their tooling. But the world is full or "HTML-2-PDF renderers, headless testing toolkits, (embedded) webview-libraries or electron-alike toolkits, which are now almost all exclusively Chromium based.

I think that is a problem many open source programs have, and could improve.

A lot of GUI based programs should think of implementing parts of it as a library others can use. I remember early Git implementations in IDEs where they just ran git commands in the background and parsed the command line output. Imagine if the same had been done with SQLite, would it still be as popular today?

I don't have much experience with creating desktop software, but it seems to me that separating the GUI from the "engine" would bring other benefits too.

I have often looked at OSS and wanted to use parts of it myself. An email client might have a really good mail parser that handles encoding, attachments etc. But decoupling it from the rest of the program would take too much time.

> ... weird chromium only behaviors that websites rely on these days to do things (and egregiously so if they detect an agent remotely resembling chrome).

This sounds like the IE6 disaster all over again.

oh man. I need to find some time to write about how bad it is.

The gnarliness spans the whole stack. From weird java-applet like API escalation behavior if chrome is detected (e.g. Google properties feature gate a ton around this) to how there is not even a clear way to get a DRM license for a custom browser without waiting for Google indefinitely [1].

Here's a challenge: fire up a chromium fork and get it to run a relaxed DRM website like Netflix. If you get that far now try loading HBOMax with their fingerprinting/DRM protection on top. I'm not even sure it'd be possible in FF (at least without some DRM piggy backing if there isn't one).

[1] https://blog.samuelmaddock.com/posts/google-widevine-blocked...

Yup, as someone who worked on fixing issues with IE5/IE6/IE7 behaviours I definitely feel the slow burning fire of Chrome repeating that whole saga once again. And probably in a much more painful way given the explosive growth of the internet and browsers since the early 2000s (I started working with web dev around 2005).

Plenty of people said this would happen when chrome started dominating, but since people refused to switch browsers, here we are.

this guy said it best https://www.youtube.com/watch?v=aYT2se94eU0&t=1414s

> Firefox, while open source, doesn't provide footing for the community to build browser forks

Say hello to https://servo.org/.

Servo wasn't a fork, nor was it meaningfully a "community" project - sure there were community contributors (it was a fun project to hack on) but most of the meaty work was being done by Mozilla employees.

Wasn't Servo team disbanded?

I wonder how difficult would be an open source community project whose explicit aim would be to take the Firefox code base and make it more modular and embeddable, like Chromium? Would it be too much work for a community effort?

Electron, but based on Firefox instead of chrome.

Not the most appealing idea, but an interesting one. Might help move more people to essentially using Firefox.

Mozilla has been trying to build an Electron alternative based on Gecko, but it has been discontinued

https://github.com/mozilla/positron

They also had XULRunner… I was even lucky enough to have been using it in a professional context. Unfortunately it wasn't well supported; trying to submit patches was always painful, and framing issues as a Firefox bug was slightly more likely to get things merged. I imagine it's easier than landing changes in Chromium (because Electron is a completely separate project), at least.

Even if possible, such an initiative could only be successful if Mozilla supports it otherwise the “new” code will quickly go out of sync with the Firefox codebase.

> Firefox, while open source, doesn't provide footing for the community to build browser forks the way Chromium does.

This reminds that Wine uses Mozilla code for their Internet Explorer replacement (wine-gecko). I wonder how far behind Firefox's rendering engine that code is, and how much effort is involved for the Wine maintainers.

https://wiki.winehq.org/Gecko

As a Vivaldi user I would really like to see more growth in this area. There are some great ideas in browser forks and I would like to enable them.

They had that with XUL and threw it all away. I remember using a XUL music player called Songbird back in the day