Hacker News new | ask | show | jobs
by alessivs 1810 days ago
> The web needs independent browsers...[websites] should work on any browser

Unfortunately, independence ends with the choice between WebKit (QtWebKit) or Blink (QtWebEngine), albeit with a faithful Opera 12-like interface that's less resource hungry than Vivaldi. Otter is still in development and it shows in some rough spots and occasional crashes.

4 comments

I'd love to go back to 1999 and see everyone's reaction when I tell them that almost everyone in the 2020s uses a browser derived from Konqueror, and that you have your choice of Konqueror derivatives from Apple, Google, or Microsoft. Whoever named it was more prescient than they realized.
There’s an old turn of phrase, first comes the Navigator, then comes the Explorer, then…
I guess we’ll all have the browser engines run on Kubernetes in a few years huh?
I think you were going with the “governor” definition of Kubernetes, but “pilot” is closer to the mark.
It is the same stem as "cybernetics", after all,
Never knew this! Thanks for sharing.
There’s also the Gecko engine, Firefox does still exist.
I was referring to a choice between WebKit and Chromium/Blink in Otter, not the web in general, though the sheer resources required to keep up with the Web(R) from other players may be leading us that way (hopefully not).

For example, after switching the preferred engine in about:config, it's even possible to leave Otter in a transitional state, having one tab load a web page in WebKit, and another in Blink, in the same running application.

And it's quite good. I switched over a little over a year ago, and I have no regrets.
QtWebkit has been deprecated for a long time, and removed from Qt6. If you use it, you'll run into 'not supported' messages on most Google websites.
Last time I used a QtWebKit browser, I could get around this easily by user agent spoofing. Not sure if the experience was totally perfect, but there were no glaring problems.

Doesn't change the fact that it's been deprecated/removed upstream, though, unfortunately.

It was used by KDE for some oauth workflows, where changing the user agent string was not possible, and auth consequently impossible. They've switched to the external browser instead.

Who outside of Apple is using WebKit at this point? And how often do the tarballs drop?

> Who outside of Apple is using WebKit at this point?

Gnome/GTK, at least. The one bundled with Gnome (previously called Epiphany) still uses it. I was going to say Midori, but apparently it's recently-ish switched to Electron, which is understandable, but a little disappointing.

There are other niche browsers using WebKitGTK, but with the loss of Midori (?) and Qt's WebKit interface its definitely got a really small presence now.

> And how often do the tarballs drop?

Unlike most open source projects inside Apple, WebKit is developed basically in the open, with a dedicated website at https://webkit.org/ and an SVN repo at https://svn.webkit.org/repository/webkit/. They also link directly to the WebKitGTK project, and provide instructions for building for/on Linux (and Windows).

It's kind of a shame it's not more widely used -- I understand why most people so inclined would prefer Gecko/Firefox, but there may come a time when the only valid choices are a rendering engine backed by Google's dollars, or one by Apple's dollars. And unlike Mozilla, which is still mostly relying on Google's dollars, Apple has a vested financial interest in keeping a separate and at least adequate web stack.

Edit: Worth mentioning one problem with WebKitGTK adoption in linux has been API deprecation. I haven't done any dev work with it, but I know a lot of projects just gave up after the WebKit -> WebKit2 port, and GTK itself can be a PITA. The tooling outside Darwin/OS X is more cumbersome, too.

JavaScriptCore is easier to embed/better documented than SpiderMonkey, though (IMO). And it can even run headless, although getting it to build headless can be, uh, finicky...

There was an effort to revive QtWebKit some time ago, despite its removal from Qt proper

https://www.phoronix.com/scan.php?page=news_item&px=QtWebKit...

it would be cool if just one of those smaller browser projects was based on firefox/gecko
There is SeaMonkey - https://www.seamonkey-project.org/

It's essentially a continuation of the Mozilla Suite (formerly Netscape). However they're falling behind on Gecko integration, with the latest version still on Gecko 60 (2018) with backports.

The reality is that Mozilla doesn't focus on embedded applications of Gecko besides Firefox (even Thunderbird is sidelined these days). Projects that are essentially third-party, like SeaMonkey, really have no visibility at all. This is the reason why the Chromium Blink engine has become so widespread, especially when it's been nicely packaged up by the commercially-backed Qt project.

I don't know why there aren't more browsers based on Gecko; especially since there are quite a few people who are not exactly thrilled with the general direction Firefox has been going.

There's PaleMoon, which is a fork, and there's SeaMonkey, although the latest version is based on Firefox 60.8 (May 2018), so I guess that's more of a fork than "using the Gecko engine" too? Also the UI is a bit too 1999-esque even for my tastes.

So I guess it's just hard to re-use Gecko? Using QtWebEngine (or QtWebKit before that) is very easy. No really, it's 20 minutes and you have a basic browser. I built a basic "vim-like" browser in the style of Qutebrowser in a day with PyQt (missing a lot of UI stuff and polish, obviously) and I'm not even very experienced in Qt/PyQt (or GUI programming in general).

Yes, Firefox/Gecko is much more one thing, Mozilla apparently even had some problems with that close integration and baked-in assumptions when building the Android variants.
Splitting this out a bit more seems like it would be a good strategic choice, not just for Mozilla, but for the web in general. There are undoubtedly all sorts of technical challenges involved, but betting on only Firefox is putting all eggs in one basket.

Say what you will about Blink/Google, but the easy with which you can build a browser on top of it has spawned a plethora of browsers, ranging from Edge and Vivaldi, to all sorts of more niche ones like Otter and Qutebrowser, and many more.

Half of Vietnam is using Cốc Cốc. Yandex Browser is fairly popular in Russia, UC Browser is popular in China (or rather was, since it was banned) and some other Asian countries.

There's no reason at least some of these couldn't have been a Gecko-based browser.

Hey, I remember that nickname!

Yeah, for smaller projects with only a handful of people behind them, WebKit (via WebKitGTK) or Chromium (via QtWebEngine, Electron, Chromium Embedded Framework) are pretty much the only choices there are. The only exception maybe being Pale Moon.

For browsers which are based directly on the Chromium codebase without being supported by Google, there are definitely many more resources needed - I don't see a particular reason why those couldn't be based on Firefox either. From what I see in QtWebEngine, keeping up with Chromium isn't exactly easy - IIRC they said they need about a person-month to catch up with a new Chromium release, usually with millions of changed lines.

I was hoping for Servo to fill that embedding usecase gap, but it looks like that's been mostly abandoned by Mozilla nowadays. My only other hope is GeckoView: https://mozilla.github.io/geckoview/ - I know at least the people behind Tridactyl would love to see it ported to x86_64: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64

I presume part of this is that for a long while the KDE/webkit/chrome engine was a separate, isolated thing, whereas the rendering in Firefox was not.

Not sure where Firefox/gecko is now, but pulling the rendering apart from the UI and improving it to be usable by other UIs, projects, would help get this done.

Or just a real browser not a repackaging of other browsers/engines.