Why are there no open source browsers using Webkit as the core engine?

Voltaire

Voltaire

Something I've always noticed is that Safari is really fast in JavaScript.
According to reliable data, the browsers using WebKit as the main engine are faster in JavaScript than the browsers based on Blink and Gecko.

Ew8jWHbUYAEOmNg.jpeg


Chromium is currently only 5.9% faster in Speedometer 2.0 than Firefox. Both Chromium and Firefox are pretty snappy on my hardware right now. I'm also not saying that JavaScript should be the most demanding component. But it is always argued that JS is the thing that should be the most significant bottleneck when modern browsers process the content/instructions. They say that JS has the most content, presence, and impact on general browser performance compared to HTML, CSS, and WASM.

WASM is expected to increase in use for the websites where computing power is important, but JS is not expected to disappear. They think it will stay dominant the next 10 years. Any browser let it be Brave, Chrome, Vivaldi, Opera, Edge, Falkon, Yandex, etc are just making another browser based on Chromium and/or Blink. The only open source browsers based on WebKit seem to be Otter browser and Qt Ultralight Browser. But both projects simply don't have enough developers to do anything. They simply don't have enough manpower to be able to present something decent.

My question probably has a super simple answer. But why hasn't a popular open source browser been developed using WebKit as its core engine?
 
There is qt5-webengine & qt5-webkit.

qutebrowser,otter-browser,falkon depend on qt5-webengine.
qutebrowser,otter-browser depend also on qt5-webkit.
 
Alexander88207 said:
Midori, Emphiphany, surf, vimb, badwolf
Click to expand...
As far as I know Midori is mostly a dead project, the last commits were done 6 months ago: https://gitlab.com/midori-web/midori-desktop

vimb seems to be possibly a fast browser, from what I read. But I can't see the positive of the vim navigation. The whole web is designed for point and click navigation. So you're basically linking the web to something it's not designed for, which simply can't be a nice experience for most websites.

badwolf also seems to be a dead project: https://gitlab.com/lanodan/badWolf

surf only seems to have seen 5 commits in 2022 and is therefore largely a dead project: https://git.suckless.org/surf/

Epiphany is a larger project and it could be a good browser. But it's a bit of a botched browser in my experience. The stability of this browser on FreeBSD is abysmal. The browser's layout and features are also really uncompetitive with the Brave browser, and Brave has far fewer developers than Epiphany.. I often see Linux users benchmarking Epiphany and it seems to be faster on Linux in JavaScript than any of the other browsers. But on FreeBSD I don't see this at all, so Epiphany has a performance problem on FreeBSD. Then there's the graphics performance in MotionMark and Epiphany isn't competitive there, at least on FreeBSD. I suspect it also has very low graphics performance on Linux.
 
Midori was taken over (bought?) by a company called Astian in 2019, which subsequently released Electron-based versions that have little in common with the original outside the name, and nothing to do with WebKit anymore. The version found in FreeBSD ports is I think the last one of the original WebKit-based Midori. Unless someone forks it it's a dead end, and current upstream Electron stuff is of little interest in my opinion.

There are quite a few others based on WebKitGTK, but most are rather basic browsers, their strength is in their lightness rather than in a rich feature set.

In FreeBSD ports:
www/luakit (also available as www/luakit-devel) which is keyboard-centric (somewhat like vimb, but I find luakit more comfortable than vimb)
www/eolie from GNOME which is an alternative to Epiphany a.k.a. GNOME Web

In the very minimalist but not vim-like style of the now abandoned BadWolf there is Lariza. It successfully built and ran on FreeBSD last time I tried.

Others are available for Linux and may, or not, compile on FreeBSD. I think (not sure anymore) I got Ephemeral working a few years ago.

Voltaire said:
is mostly a dead project, the last commits were done 6 months ago
Click to expand...
Voltaire said:
seems to have seen 5 commits in 2022 and is therefore largely a dead project
Click to expand...
When talking about such browsers, it doesn't matter much whether they move slowly, it doesn't make them dead or useless. What needs to keep up with the web is the underlying engine; once functional, the GUI doesn't require frequent updates nor changes for the sake of change.

On the other hand, any browser relying on qt5-webkit is to avoid: the Qt port of WebKit is abandonware full of unpatched vulnerabilities, and most Qt applications that used to rely on it have moved to qt5-webengine (which is basically Blink, the Chromium engine).
 
Because...

1. Webkit, while OSS, is corporate owned and driven by Apple - also the reason why Google created their own fork, Blink, to get free of Apple's influence,
2. Building Webkit takes forever, even on a quite powerful machine,
3. Webkit is a real quick moving target, so keeping up with development can be challenging/tough on your ressources,
4. there's Chromium, which basically is just that.
 
hardworkingnewbie said:
Building Webkit takes forever, even on a quite powerful machine,
Click to expand...
Blink and WebKit are both written in C++, so they're both going to be very slow during compilation.

It's also outdated that it takes a long time to build WebKit: https://techcrunch.com/2020/11/17/y...its-the-battery-life-that-will-blow-you-away/

I would rather call 19 minutes on cheap hardware from 2020 'fast'. People always talks about the many hours it takes to build Chromium, so I suspect Blink won't be compiled any faster.
 
bsduck said:
Midori was taken over (bought?) by a company called Astian in 2019, which subsequently released Electron-based versions that have little in common with the original outside the name, and nothing to do with WebKit anymore. The version found in FreeBSD ports is I think the last one of the original WebKit-based Midori. Unless someone forks it it's a dead end, and current upstream Electron stuff is of little interest in my opinion.

There are quite a few others based on WebKitGTK, but most are rather basic browsers, their strength is in their lightness rather than in a rich feature set.

In FreeBSD ports:
www/luakit (also available as www/luakit-devel) which is keyboard-centric (somewhat like vimb, but I find luakit more comfortable than vimb)
www/eolie from GNOME which is an alternative to Epiphany a.k.a. GNOME Web

In the very minimalist but not vim-like style of the now abandoned BadWolf there is Lariza. It successfully built and ran on FreeBSD last time I tried.

Others are availble for Linux and may, or not, compile on FreeBSD. I think (not sure anymore) I got Ephemeral working a few years ago.



When talking about such browsers, it doesn't matter much whether they move slowly, it doesn't make them dead or useless. What needs to keep up with the web is the underlying engine; once functional, the GUI doesn't require frequent updates nor changes for the sake of change.

On the other hand, any browser relying on qt5-webkit is to avoid: the Qt port of WebKit is abandonware full of unpatched vulnerabilities, and most Qt applications that use to rely on it have moved to qt5-webengine (which is basically Blink, the Chromium engine).
Click to expand...
qt5-webengine is eoled & not qt5-webkit ...
 
Voltaire said:
...

Epiphany is a larger project and it could be a good browser. But it's a bit of a botched browser in my experience. The stability of this browser on FreeBSD is abysmal. The browser's layout and features are also really uncompetitive with the Brave browser, and Brave has far fewer developers than Epiphany.. I often see Linux users benchmarking Epiphany and it seems to be faster on Linux in JavaScript than any of the other browsers. But on FreeBSD I don't see this at all, so Epiphany has a performance problem on FreeBSD. Then there's the graphics performance in MotionMark and Epiphany isn't competitive there, at least on FreeBSD. I suspect it also has very low graphics performance on Linux.
Click to expand...
BTW, does not Epiphany heavily depend on GNOME components? So much so that installing it pulls in most of the GNOME DE core?
 
On my pc i have the following dependencies:
On qt5-webkit : otter-browser, qutebrowser
On webkit2-gtk3 : badwolf,epiphany,midori,surf-browser
 
Voltaire said:
My question probably has a super simple answer. But why hasn't a popular open source browser been developed using WebKit as its core engine?
Click to expand...
Because WebKit is designed to compile on Macs and accommodating anything else isn't going to make it into mainline so why bother keeping up a fork.
 
Alain De Vos said:
qt5-webengine is eoled & not qt5-webkit ...
Click to expand...
It's marked EoL in FreeBSD ports because it requires Python 2 to build, just like Chromium not that long ago. QtWebEngine is used by lots of KDE software, it's not deprecated upstream and not going away any time soon, at least not before most applications using it were ported to Qt 6. Arch Linux patched it to build with Python 3, so it should be doable on FreeBSD too if wanted. Its successor www/qt6-webengine doesn't have that issue anyway.

free-and-bsd said:
BTW, does not Epiphany heavily depend on GNOME components? So much so that installing it pulls in most of the GNOME DE core?
Click to expand...
Yes and no. This is what would be pulled if I installed it on the machine I'm writing from (KDE Plasma desktop without GNOME applications installed):
Code: 
New packages to be INSTALLED:
        cantarell-fonts: 0.301
        enchant2: 2.2.15_2
        epiphany: 42.4_2
        gcr: 3.40.0
        geoclue: 2.5.7
        gjs: 1.72.2
        glade: 3.40.0
        glib-networking: 2.74.0
        gnome-desktop: 42.4
        gnome-icon-theme: 3.12.0_1
        gnome-icon-theme-symbolic: 3.12.0
        graphene: 1.10.8
        gstreamer1-plugins-gl: 1.20.5
        gtk4: 4.8.3
        json-glib: 1.6.6
        libXres: 1.2.2
        libdazzle: 3.44.0
        libhandy: 1.6.2
        libsecret: 0.20.5_1
        libsoup: 2.74.3
        libwnck3: 3.36.0
        libwpe: 1.12.0
        startup-notification: 0.12_4
        webkit2-gtk3: 2.34.6_4
        wpebackend-fdo: 1.12.0

Number of packages to be installed: 25

The process will require 212 MiB more space.
54 MiB to be downloaded.
As expected there are dependencies on GNOME components but that's far from the whole GNOME stack. These 25 packages altogether still use less disk space than the Firefox package alone (installed size: 253 MiB).
 
hardworkingnewbie said:
Are you nuts? Oh please... do you really think that the compile time on Apple Silicon matters to somebody here? I don't think so.
Click to expand...

There are (at least) three reasons why I think it might be very relevant to FreeBSD users.

1. You are going to have FreeBSD users who also own a laptop/desktop from Apple. There are FreeBSD users who are also fans of Apple, otherwise helloSystem and ravynOS wouldn't exist.
2. It seems that efforts are being made in the BSD community to support M1/M2 processors in the future:
https://twitter.com/i/web/status/1431575270436319235
View: https://twitter.com/jmcwhatever/status/1431575270436319235

www.theregister.com

OpenBSD 7.1 released, including Apple M1 support

26 years and only two external exploits is not to be (packet) sniffed at
www.theregister.com www.theregister.com
3. The M1/M2 processors are very similar to the rest of the ARM processors, so this performance is relevant to the many FreeBSD users currently or in the future switching to ARM:
www.digitaltrends.com

In just 3 years, 30% of PCs may be built on ARM architecture | Digital Trends

A new report suggests that ARM may appear in many more computers in the near future.
www.digitaltrends.com www.digitaltrends.com
A new report suggests that ARM-based systems might become more and more common in the future, ramping up at an unprecedented pace.
 
Alain De Vos said:
Heat production leads to need for lower power-consumption and this to lower voltage , and then we have arm.
Click to expand...

The miniaturization of nodes and wafers has hit more and more hard limits in recent years, there are a few last tricks one can do to make the node designs significantly more efficient, and after that the only option is to move away from silicon completely. As a result, there is now more pressure to use the current nodes and wafers with the most efficient designs possible, to be able to keep up with the rapid rise of AI, and to ensure that the demand for energy that rising AI adoption has created does not immediately destroy the earth.

ARM is closed source whereas RISC-V is open source. Companies that use the ARM ISA, however, are not allowed to modify the basic core itself. RISC-V International and companies that use RISC-V see this as a major limitation, and combined with the licensing fees makes using ARM undesirable. So what alternative does RISC-V provide? Companies are also allowed to do whatever they want with RISC-V cores. This definitely lowers the barrier to entry on making any CPU, custom or not. Companies that use RISC-V are not obligated to share their innovations with anyone, though they are free to license and sell their IP just like ARM can. Both ARM Ltd and RISC-V International want to advance the computing industry, but have different ideas on the best way to do it. Essentially, the difference between ARM and RISC-V comes down to how much a central authority gets to decide and limit.

But what most people don't know is another new power that has revealed itself. The Prodigy processor, which is announced as the chip that will destroy AMD, Intel, NVIDIA and ARM by bringing together CPU, GPU and TPU, with performance beyond anything we can imagine. I've talked about this with people on Phoronix. It concerns a design that was already known in the past, the VLIW architecture, which has major advantages in terms of efficiency. In the past, the disadvantages have not been solved. It could perfectly well be that someone managed to crack the nut. So there's a possibility that this isn't going to be vaporware. Only very smart people can understand this kind of tech.

We'll see how Tachyum's story develops in the future. This extremely brilliant chip will be able to execute x86, ARM and RISC-V instructions. Something nice for FreeBSD users to know is that Tachyum has announced that in addition to Linux they have managed to boot and run FreeBSD on their ISA.
 
Voltaire said:
But what most people don't know is another new power that has revealed itself. The Prodigy processor, which is announced as the chip that will destroy AMD, Intel, NVIDIA and ARM by bringing together CPU, GPU and TPU, with performance beyond anything we can imagine.
Click to expand...

What if you don't need GPU or TPU for your application? Let's say database or file servers. This sounds like dragging around silicon useless to many, just like the brand new Xeons with their additional processing units.
 
Voltaire said:
The ... processor, which is announced as the chip that will destroy AMD, Intel, NVIDIA and ARM by ...
Click to expand...
I've been in the serious computing business for about 35 or 40 years. My friend and neighbor goes back at least another decade; he was one of the heroes of processor architecture. If I had a beer for every time that a new thing announces that it will destroy all existing computing, we'd all be very drunk.

It concerns a design that was already known in the past, the VLIW architecture, which has major advantages in terms of efficiency. In the past, the disadvantages have not been solved. It could perfectly well be that someone managed to crack the nut.
Click to expand...
VLIW? Read this article: https://www.eejournal.com/article/news-flash-itanic-still-sinking/

The probability that anyone can make VLIW work today, after 40+ years of trying, is very low. Very smart people have worked on it. Not just Josh Fisher and his group, but also lots of folks in Silicon Valley and elsewhere. It has connections to many other interesting ideas in computer architecture, such as reconfigurable instruction sets (sort of the anti-microcode idea), and emulated microprocessors (remember Transmeta). But none of that has come to fruition. Ultimately, just lots of hard work and elbow grease end up winning over impractical ideas of a mad boy genius.
 
You must log in or register to reply here.
Back
Top