Hacker News Reader

Comment by Y_Y | Hacker News Reader

> Falkon is a KDE web browser using QtWebEngine rendering engine, previously known as QupZilla. It aims to be a lightweight web browser available through all major platforms. This project has been originally started only for educational purposes. But from its start, Falkon has grown into a feature-rich browser.

While I applaud competition among browsers, I think that the renderer/webengine is such a big external component nowadays (especially if you lump in the JavaScript engine) that it might be more accurate to say that you're providing a skin, rather than a new browser.

Anyway I miss Konqueror and am happy to see any of its descendants carry on its legacy.

(QtWebEngine is derived from Chromium - https://doc.qt.io/qt-6/qtwebengine-overview.html )

View on HN

This is so funny.

So chromium came from WebKit, which in turn came from KHTML which was ... a KDE web engine :D

I’d really love to see a KDE-native browser based on Gecko instead of Chromium or WebKit.

I mean, WekKit started life as a fork of KDE's web engine so only makes sense they'd use it...

I’m not saying they shouldn’t use it, of course! I just want there to be an alternative, too :-)

(It could be a part of KDE – they do have multiple media players, why not multiple browsers as well? But it could also be an independent project. I might tinker with this idea sometime, although I don’t have a KDE setup right now as my main laptop broke down.)

Not likely unfortunately thanks to Mozilla, which in all its wisdom, dropped embedding support from Gecko. This means it effectively cannot be hosted outside of Firefox/Seamonkey and forks thereof. This is contrasted by WebKit, which is largely UI toolkit agnostic and can be dropped in just about anywhere.

Funny thing, Epiphany (now known as GNOME Web) was originally built around Gecko, but when Mozilla axed embedding, the project had no choice except to switch web engines and so it’s now built around WebKit instead.

I think that was a fine decision by Mozilla, even if I'm not happy with it. Firefox is already a web browser with barely enough market share to support it. Wasting resources on making even smaller special purpose web browsers integrate with the engine is not a move for a company that has been struggling with a lack of independent funding for years now.

Of course the decision was made back in the Firefox 5 days, but back then Chrome was rapidly growing, mostly at the cost of Firefox. Had Firefox remained embeddable, I think it would've only been held back in important performance areas like threading and rendering because of the API around the web view.

Interesting enough, with the Firefox for Android rewrite, Mozilla actually went back to making Gecko embeddable: https://wiki.mozilla.org/Mobile/GeckoView This design decision is also claimed to be the reason for them to disable about:config in production builds, because misconfiguring geckoview can disconnect it from the app and leave users with a broken browser (apparently).

So now there is an official way of embedding Gecko in your application, but it's limited to Android only.

>Wasting resources

talking about Mozilla wasting resources is quite funny. Do you think having a competitor to Electron would be worse than

+ Pocket

+ LLM

+ VPN

+ https://mozillalifeboat.com/

any proof that they are losing money on VPN or Pocket? That's my only concern, if they're profitable they should live, if they are cost centers, drop them (obviously they're outside core mission of the browser, internet standards, internet freedom)

Diversifying the business so they're not dependent on Google is a good thing. I disagree with most of their business choices, but if the American DoJ gets its way, Mozilla will lose 86% of its funding next year.

As for Electron, I don't really care. I open most Electron apps in pinned Firefox tabs already.

As for the ones that integrate natively and can't run in the browser, Firefox is slower than Chrome so I'd rather have these 3MiB of JS apps ship with another slightly outdated copy of Chrome than with a slightly outdated copy of Firefox.

I think embedded gecko would have been the way they could answer electron, and that would have helped them stay relevant.

Mozilla Positron, their attempt at an Electron-compatible runtime on top of Gecko, did not pick up any traction and was cancelled.

That was quite late in the game, though. Kind of like closing the barn doors after the horses have already bolted.

It was released in 2016, only two years after Atom and Slack and a year after VSCode. Not sure I'd call that late.

By that point Electron had gained too much momentum and public mindshare to compete with without a big marketing push and flagship project at least as significant as Atom and VSCode were. Positron never got either.

Electron apps were popular, not Electron itself. Even now there are only 4-5 dozen popular apps using it, while I probably run across that number of Qt/GTK apps a month. It's a sort of weird dichotomy it finds itself it.

Mozilla XULRunner, which was the thing that happened before Electron, wasn't too bad though. It had way more traction than Positron. It died because Mozilla didn't care about it.

Well, and XULRunner was based in XUL, something Mozilla was trying to get rid of for very good reasons.

It did work with HTML though IIRC. (Well, given Firefox UI is now mostly HTML with some XUL sprinkled on top.)

I still find the decision questionable. No embedding meant that Gecko missed out by default on the wave of embedded WebViews in the early smartphone era as well as the “desktop web stack” boom that Electron/CEF came to dominate.

Additionally, I believe that one of the reasons why Firefox has struggled to maintain market share is because it’s a bit of an acquired taste. Relative to Chrome, Safari, etc it’s kinda quirky and not to everybody’s liking. Alternative browsers wrapping Gecko could’ve helped a lot here.

Camino was a great example — Mozilla couldn’t justify building a Mac-specialized Firefox and that makes sense, so Camino filled that gap instead and became quite popular among Mac users. When Camino had to close up shop following the removal of embedding, most of those users didn’t switch to Firefox but instead to Chrome and Safari because those were better suited to their needs.

"Wasting resources on making even smaller special purpose web browsers integrate with the engine is not a move for a company that has been struggling with a lack of independent funding for years now."

So says the narrative. Mozilla has money, but prefer using it for C-Level salaries : Mitchell Baker raised her salary from 2.5M$ to 7M$ within 4 years, all the while laying-off developers and spending a shitload of money on seminaries and others BS expenses. Meanwhile, the market share of Firefox dropped.

And I assume you have noticed that privacy is not their main concern.

Such a pity because Phoenix/Firebird/Firefox brought a lot to the Web. But I guess this happens when Corporate people take over any organisation.

Yeah playing the whole corporate game really corrupted Mozilla. When you join them you start to think like them. And then it's game over.

It was US tax issues that forced them to go corporate but as a result of the Google deal. So they tricked them into going corporate.

>raised her salary from 2.5M$ to 7M$ within 4 years, all the while laying-off developers and spending a shitload of money on seminaries and others BS expenses.

Seminaries? Kagi turns up nothing. Could you explain?

Perhaps they meant seminars?

Who do you think writes the Book of Mozilla? Making a web browser requires a large supply of priests.

Except for Internet Explorer.

Embedlite is still maintained, even though it's not a Mozilla project nor very active. Since it's the base for the Sailfish browser, it even does have Qt bindings.

Relevant repos:

https://github.com/sailfishos/qtmozembed https://github.com/sailfishos/embedlite-components https://github.com/sailfishos/gecko-dev

What about using GeckoView?

https://mozilla.github.io/geckoview/

I don't know what I'm talking about though. I just found that and have no idea how useful it is

It’s geared towatds Android mostly, though it might be possble to adapt it for desktop.

> While I applaud competition among browsers, I think that the renderer/webengine is such a big external component nowadays (especially if you lump in the JavaScript engine) that it might be more accurate to say that you're providing a skin, rather than a new browser.

Makes me think of NeoPlanet. That was an online trend that ripped through my university[0]. NeoPlanet was billed as the "world's first skinnable browser", and Wikipedia attributes the coining of the term "skin" (in the UI sense) to NeoPlanet's developers[1]. But NeoPlanet itself was pretty much a skin over Internet Explorer's browser engine, embedding a COM component of the browser into itself. So to me at the time, it didn't count as a separate browser, just a UI for internet explorer.

[0] Alongside AllAdvantage, which inspired some of the first mouse-jiggling simulation software because it paid users for active internet time while displaying ads on their screen. There was a whole universe of 90s Windows crudware that I wasn't all that privy to.

[1] I think Winamp's use of "skin" preceded NeoPlanet's, by analogy with Quake "skins", textures that could be applied to your player character in the QuakeWorld online multiplayer service, which could be used to indicate clan affiliation, etc.

Qt doesn't upgrade WebEngine often enough. So it is possible to have lingering vulnerabilities in Falkon.

Reply on news.ycombinator.com