Qutebrowser: A keyboard-driven, Vim-like browser
github.com
github.com
I've used qutebrowser extensively in the past, and reported a few bugs, each of which has been met with interest and engagement. Some of them even uncovered bugs in the upstream software (e.g. QtWebEngine) which were reported there.
I eventually stopped using it when YouTube ads became too invasive, and went back to Firefox + Vimium + uBlockOrigin. I sometimes miss the programmibility of qutebrowser, but Vimium at least gives me the basic Vim-like browsing features.
I like Qutebrowser very much, though. Used it for a good spell and was very happy. I'd some bug I couldn't fix which was driving everything really bonkers, but I honestly did not investigate it that hard, I'd been using it for a while at that stage (over a year, I'd guess, anyway) and was ready to move on and try something different, so I solved that bug the old fashioned way.
Nyxt scratches the same itch now, but moreso, and it has Common Lisp behind it, which is much more interesting [to me personally!] than Python.
The convenience those shortcuts provide also makes it concerningly easy to press something on accident. Much more likely than accidentally clicking something. Having extra leader keys or some other approach to reduce accidental presses would detract from the convenience…
Curious if anyone else has run into this or configured their setup in a way that maintains the convenience but reduces the accident likeliness. Holding a modifier key or adding leader keys actually does seem like I’d go a long way in reducing accidents with minimal hit to effectiveness
It’s a shame that I often end up using more than 100GiB of RAM with a few dozen tabs, almost like it leaks memory. I’m aware of the inherent fragmentation of memory with python over time- so could be that.
There’s also been a few times where the limitations of using qtwebengine (chromium wrapper) underneath were frustrating - though I can barely remember what they are at this point.
The python config is great too, I use it to disable javascript conditionally. :)
Theres also some magic feeling when pressing “o” and having access to the world.
I wouldn’t say they do the same thing exactly. Vimium is similar to a vim-mode in something like VS Code, while qutebrowser is more like Vim itself. The Vim “spirit” is built-in and is the expectation rather than a layer added on top. The qutebrowser UI, already minimalistic, is also very configurable and scriptable.
The flip side to me is that some of the experience will be nicer with Chrome, the same way VS Code can be nicer and easier to manage.
Assuming you're on Linux, that's usually more of a problem with Linux distributions being behind on QtWebEngine. Though yeah, sometimes things are tight with QtWebEngine only updating their Chromium baseline once every 6 months. I try to ship workarounds (in the form of polyfills) with qutebrowser when I know about breakage, but usually for me things run smoothly.
Unfortunately, support for proprietary codecs like MP4 and such requires building Qt from sources, and would also require me to acquire licenses for them all (I believe they're free until a certain number of distributions, but also with all the indirect ways you can get qutebrowser, I can hardly even provide that information).
This isn't an issue on Linux, because those licenses have some sort of exception in the sense of "if shipped with an operating system or its packages".
Homebrew seems to build its Qt packages against system ffmpeg with proprietary codecs enabled, and there's an issue open which would at least allow you to build a custom build against that: https://github.com/qutebrowser/qutebrowser/issues/4127
Maybe I should look into whether I'd be allowed to redistribute such builds (or what kind of paperwork I'd need to do for it). Unfortunately there's a lot on my plate, and macOS/Windows are admittedly somewhat second-class citizens as I don't use those myself.
Vimium mainly gives you keyboard navigation, but QuteBrowser removes the address, tab and bookmark bars and instead gives you keyboard access to everything via the very Vim-like status bar at the bottom. Incidentally this also frees up quite a bit of vertical screen real estate, which is a big deal to me. Browser settings, scripts, etc. are also all accessible via the keyboard — Vim style.
Edit: The lack of a solid Bitwarden integration in QuteBrowser is kind of hurting though.
As an early lover of Firefox, I'm sorry to see its progression away from its ideals, and can't keep track of which part of the saga happened when. Was that when they removed XUL?
Of course you need to understand vi as a prerequisite, a few hours to configure it and maybe a few weeks to really get you use to it.
But damn the benefits after are enormous.
Congratulations to the developers !
2. I wonder... how good is its Right-to-Left support?
Then there is the issue of "stable" Linux distributions (mostly Debian/Ubuntu) which never get those updates to you unfortunately, and don't seem to care about those being security-relevant either. Not much either qutebrowser and Qt can do about that sadly, but you can install Qt from somewhere else, e.g. from the PyQt binary builds if you don't mind losing proprietary codec support: https://qutebrowser.org/doc/install.html#tox
As soon as a new Qt/PyQt is out, there is usually also a new qutebrowser release bundling it for Windows/macOS releases.
If you're running an up-to-date Qt and qutebrowser, that'll currently be based on Chromium 122 from April 2024 (with security patches up to Chromium 131).
Sadly, https://github.com/servo/servo/issues/27579 has been pretty dead for the past years.
(And before someone asks for Ladybird backend support: Same story there)
As for the Qt side, "ongoing effort" is quite a stretch for something that was made as a conference demo and not touched again since April: https://github.com/KDABLabs/cxx-qt-servo-webview/commits/mai...
Open source is far from being enough anymore, we (the humanity) need lean open source (including that bloody SDK, which excludes de-facto ultra-complex computer language like c++/rust/java/etc).
https://en.m.wikipedia.org/wiki/Lisp_machine
Also c23 is supposed to have better unicode support but I've never really bothered internalizing the "translation character set" and whatnot.
I did not look that much into it but I can bet that 'lisp' browser is actually just a 'lisp front-end' to big tech web engines... namely a scam, please prove me wrong.
I would write a browser in RISC-V assembly with a small macro pre-processor, but the issue with the web is its infinite scope killing any non big tech, real-life, alternative attempt, and not for the good reasons.
https://nyxt.atlas.engineer/article/technical-design.org
I think it's an elegant design that sidesteps many issues, and since bindings aren't involved you are designing purely in the language of choice. You can't expect every project to reimplement every library down to the stdlib.
And like it was exposed below: in this end, this is sort of not very honnest, because this is just another Big Tech engine front-end.
Signed,
someone that writes and distributes apps/tools written in “less simple” languages and apps/tools written in zero-dependency and even libc-free C.
I would be super pleased to be wrong...
I didn't understand your original point about needing "a modern web browser" with "a simple language" (I'm not sure it was clear, by itself...), but I read your other comments, and I understand your point better now, I think.
I agree that "open source" itself is absolutely not enough, and that another prerequisite to fighting for practical computing freedom is to have "human"-sized tools. Fully on board with that (I wonder if you've seen the malleable systems forum, actually...).
I think Nyxt would love to provide that, eventually, and are trying to fight that fight, on a stacked battleground, in an imperfect world.
For example, gopher and gemini are supported. And they're trying to support different renderers. They're trying to make the browser fully configurable and programmable as far as they can, in spite of the shortcomings of the web.
Tell me if this is completely beside your point, but in case it helps you in seeing what they're about, have a look at:
https://nyxt-browser.com/article/command-line-programs.org
Or, much more technical, too technical for me, and it's a bit dated so the exact design might have changed, but maybe you'll get something from the overview nonetheless:
https://nyxt-browser.com/article/technical-design.org
Maybe that's not enough, and you think the solution has to be more radical, but I don't know what it would be, other than a new set of networking protocols comes along and somehow supercedes the ones we have now. Which could happen, I don't know, I'm only still only learning about the ones we currently have :D
Also, have you seen surfraw? Or do you have examples of the kind of thing you'd like to see being attempted in the wild? I'd be curious to see them.
p.s. I responded to a point you made 8 days ago about email in a different thread [https://news.ycombinator.com/item?id=42287607] and thought I'd say to you here in case you'd be interested in elaborating over there!
And that is exactly the same issue with the c++ language syntax and its compilers (that would be the same issue with other complex computer languages like rust/java/etc).
Seriously, I would go for a modular implementation directly in 64bits RISC-V assembly with a very small macro-preprocessor (because, moving the complexity from the language syntax to the macro-preprocessor would be riduculous).
That's why, from this perspective, those small attempts are kind of pointless and even somewhat dishonnest since, in the end/'real-life', they are just font-ends of Big Tech...
The email people did see the DNS "barrier" coming: it has always supported literal IPv4 addresses (and a similar IPv6 literal has been in specs for ages).
Using the "excuse" of spam/phishing of script kiddies, they blocked IPv4 literal support and ignored the subsequent IPv6 literal support. If I recall well, IPv4 literal support was a thing on google mail a few years ago (even IPv6 if I recall properly), it means it was explicitely blocked.
Then to get SMTP interop with them: you MUST rent/pay for a domain name, and in the last few years, very slowly but surely (I did live it, horrible), the DNS registars did stop working without a Big Tech web engine (they were working fine with lynx or links or netsurf, namely noscript/basic (x)html, which is more than enough, actually even overkill).
Basically, they have big services, and they made sure that, slowly and in the end, you must use their software for their services, and they could not careless of the small alternatives even if the internet protocols did account for this. This is compuserve/AOL all over again. The remaining/surviving "small" did just cave in and is part of the problem now.
The only sane way out of this "dominance" is to restore interop with simple , but good enough to do the job, and really stable in time protocols. And restoring 'interop' won't happen asking nicely: only hardcore _technical_ regulation can do it now.
All is about technical interfaces: the very hard part is they must be simple and stable in time, _while doing a good enough job_. Ofc, things may significantly change, significant new usages can arise... then new simple and stable in time technical interfaces will have to be designed (but one or a small number of average devs should get it implemented in a reasonable amount of time), or new simple and stable in time "layers" added an an existing technical interface (the core of the dynamic web is noscript with basic (x)html forms, and I think it is already way too complicated). A set of layered and modular technical interfaces, but all simple and stable in time. Ofc, if there are billions of interfaces required to support a basic use case, there is something wrong somewhere...
I did reach a point where I would not be even surprised if they did shadow-pay hackers to bring down any simple and stable alternatives.
It far from easy to deal with all of this.
All browsers already support keyboard shortcuts for 90% of the common browser operations (next / previous page, focusing the address bar, etc.), and anything on the page itself seems like a massive chore (except scrolling, which browsers also support).
So their lizard brain thinks "mouse=stupid, keyboard=smart" and then they optimise for a sense of superiority.
- a user who prefers to minimize switching from mouse to keyboard, or vice versa
- a user who has some RSI issues related to the index finger when clicking a mouse
etc. etc.
But no, let's go with the deliberately antagonistic strawman.
What it turned out to be in the end was a poor desk setup. My desk wasn't deep enough so I wasn't resting my forearms on it very well, and I had a crap chair.
With a deep desk and a fancy mesh chair (HM Mira; expensive but worth it), I haven't had any issues since.
Maybe that's not the case for you but it's just a suggestion. Definitely made me suss of all the ergonomic keyboards and mouse - they made zero difference, and a better chair and desk completely solved the issue.
> What it turned out to be in the end
> Definitely made me suss of all the ergonomic keyboards and mouse
Personally, this is much easier on my RSI than mousing to each link. Especially on a laptop with a trackpad.
Additionally, the browser is fully configurable in Python, to a much greater degree than what you get from Firefox or Chrome.
One seemingly small thing that I find quite convenient is that I can use reader mode or open a PDF and still keep hjkl for scrolling. I also use Tridactyl in Firefox, but Firefox's reader mode and opening PDFs turns disable extensions in the tab, so you can't use these scrolling keys.
As for next and previous page, I think you're referring to history navigation forward and back. Qutebrowser includes built-in functionality to navigate in multi-page documents to the next page and previous page, e.g. documentation sites or html books. That shortcut is '[[' for previous and ']]' for next. So, for example, if I am on this section of SICP: https://sarabander.github.io/sicp/html/1_002e3.xhtml#g_t1_00... and I press ']]' I immediately go to https://sarabander.github.io/sicp/html/Chapter-2.xhtml#Chapt... . This happens regardless of browser history. "Back" and "Forward" are different from "Previous" and "Next". I do not know of a similar piece of functionality in other mainstream browsers.
This is all highly opinionated. I like vim-style shortcuts. I vastly prefer the experience of using qutebrowser (or a vim-like extension for another browser) over using a mouse exclusively or a mouse and keyboard mixed.
If you, or someone else, prefers a different style of interaction with the browser, that's fine. It's not about right or wrong or better and worse, at least not in the abstract. It's about a user interaction paradigm that works well for an individual.
Maybe there's a solution I've not thought of (CDN?).
[1] https://github.com/tridactyl/tridactyl/issues/541#issuecomme...
This has a mental speed bump that I really don't like, that tends to make these features annoying to use: you have to pause after hitting "f" to wait for those letters to appear, read them, then type them.
Vimperator (the one that died with Firefox Quantum) handled links where you'd hit "f" then type the text in the link itself, with numbers to disambiguate if the filtering didn't reduce it to one match. With no pause and the link text already in your mind by the time you hit "f" it was very fast and fluid to use, and I was very happy after learning Tridactyl could be configured the same way.
Does this have the same thing?
I don't remember if it's explained anywhere that once hinting is started you can filter based on link text, alt text, or a couple of other textual representations for clickable elements.