I honestly clicked the link in your comment hoping to read a compiled list of obscure inconveniences that have prevented you from using alternative browsers. Any hope we can learn some of these issues? ;P
- Keybinds are lost when page is loading or on special pages, which is a huge break in flow
- Some keys cannot be bound (eg, unbinding Ctrl-q, binding Ctrl-w)
- Lack of options when customizing the UI (I can't get my nyan fix, can't move tabs to the bottom/right of the screen)
- The omnibar (firefox, chrome, vimium) feels extremely slow, especially compared to lighter weight history searches.
- (sometimes) lack of an insert/passthrough mode, to send keys to js running on the page
- Inability to integrate cleanly with the rest of my system (:spawn mpv {url}, qb userscripts)
- Much harder to hack on the browser itselfCustomising browser interface is possible with userChrome.css on Firefox, and there's something similar for Vivaldi but it's actually supported. I'm not sure if anyone has bothered releasing a Vim add-on for it though.
`composite js document.location.href | !s mpv`
Should work. I think we might have a `currenturl` ex command that you could replace the js bit with but I can't remember.
I'm a big fan of surf for example, but it leaves it up to the users to implement features like history, which I never got around to doing. Sure, someone's probably already posted his implementation for that, but nonetheless the sad pragmatics of not investing the time into that eventually helped drive me towards the bloated, but featureful point and click browsers. To be clear, I'm completely in favor of this kind of modularity in systems, but at the same time the tinkering is a two edge sword, if I had found a good premade surf setup to fork, then I would have been left with only the positive aspects, I guess.
Another example, which is a bit more serious, is that these projects seemed to be chronically out-of-date, or not fully compatible with my systems, because I'd have some rendering or interaction problems from time to time.
Which kind of brings me to my next point. Web, the platform, sucks. It's complex and bloated. It suffers from the system within a system syndrome. That's why it keeps moving. By consequence, the browsers have to not only be complex as well, but also keep moving equally fast. The big browsers just have a large advantage in situations like this.
I've tried all of the previous lightweight vim-like incarnations of the webkit2-lib based browsers. Not being much of a browser customisations person beyond adblocking my issues were solely with the inadiquate browser engine "webkit2" which was ultimately abandoned, it was always slow to be updated, increadibly slow and insecure.
This is why I thought qutebrowser was worth a post on HN, because it's the first of these lightweight keyboard driven type browsers that I have found with a completely useable modern up-to-date engine behind it (QTWebEngine[1]):
Relationship to Chromium
Qt WebEngine uses code from the Chromium project. However, it is not containing
all of Chrome/Chromium:
- Binary files are stripped out
- Auxiliary services that talk to Google platforms are stripped out
- The codebase is modularized to allow use of system libraries like OpenSSL
We do update to the latest Chromium version in use before a Qt release. After a
release some bug fixes and security patches are backported. For LTS releases of
Qt we might also update Chromium in a patch level release.
I've not used qutebrowser extensively enough yet to comment much on the front-end, but the most important part is there, the nice engine without any nasty privacy violating services built in. But my first impressions with the front end are pretty good, and i'm not even a vim user.
However, QtWebEngine is probably still ahead of WebKit, both security- (sandboxing) and feature-wise.