Florian Bruhin (AKA the-compiler, the author of qutebrowser) is one of the kindest and most dedicated open-source maintainers I've ever had the pleasure to interact with.
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.
Someone was triggered by the Nyxt post getting so much attention... =D
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.
I tried an extension once that provided these navigation shortcuts for all the links on a page. It was really convenient but then I was on an admin page for our team and accidentally hit a couple keys that pressed some random button. The page was full of buttons that had irreversible effects which were executed without confirmation. Of course that’s an issue itself for the page but that’s kept me from trying this again.
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
Yes, I find it easier to press single quote in vanilla Firefox, start typing the most unique looking part of the link text, see it become green, press Enter to confirm. The link search feature in Firefox is one of the reasons that keep me using it.
I tried really hard with QB, and still use it for some tasks, but the lack of Ublock Origin makes browsing random sites horrible. People say the builtin ad blockers are good enough; for me, they are not even remotely good enough :(
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.
Was it 100GiB of RAM, or 100GiB of forked processes sharing lots of memory pages? Python reference counting destroys forked process sharing, but only for the the Python parts.
Qutebrowser fixes the main issue I have with Vimium: you cannot control the browser itself well. Vimium does not work in certain places due to limitations imposed by web extensions and this is incredibly frustrating for me.
Been using Vimium for years too and it's great, but it's really not the same. The late, great Vimperator extension was more comparable to QuteBrowser but it stopped functioning (on Firefox) when they switched from XUL to web extensions.
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.
I’ve used both for many years. I’ve stopped using qutebrowser because it has some limitations due to be a bit behind on the web engine, which leads to problems with some sites. I still think it’s brilliant.
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.
> I’ve stopped using qutebrowser because it has some limitations due to be a bit behind on the web engine, which leads to problems with some sites.
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.
No, I’m on macOS. I think my main issue was with videos that didn’t always play correctly. Can’t remember exactly but I think either on Reddit or Twitter, it was just not reliable.
Ah, I see. That's not due to the Chromium version though, it's because the Chromium that comes with Qt releases (which is what's shipped in qutebrowser releases) is built without proprietary codec support.
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.
Configuring the qutebrowser UI is a major reason I used qutebrowser for some years. I love ricing my system and saving screen real estate with a minimal UI bloat is nice.
It is a real pity that the major browsers don’t support better keyboard navigation out of the box. Due to work restrictions, I can only really use firefox, chrome or edge and no addons/extensions. There’s a 14 year old ticket for firefox (still open), but the reaction back then was that it is a niche feature better suited for an addon.
Oh! This takes me back. I used it as my primary browser during the Firefox 57 saga, and continues to use it for over an year. The developer was very responsive to bug reports, and fixed the issues right away. Unfortunately, I moved away from the Linux ecosystem as my primary computing environment, but I would still recommend this if someone wants to try a Vim-based browsing experience and is willing to try out a new browser.
> I used it as my primary browser during the Firefox 57 saga
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?
RTL support should be as good as Chromium's for web contents (as QtWebEngine is based on Chromium), and as good as Qt's for the UI. Admittedly I never tested, but if you notice something in the UI that doesn't look right, I'd be happy to have a look and see if there's something that can be improved there.
I'd love to use this but a key problem seems to be that they don't get updated as soon as a security fix is released, which for browser engines is quite often...
Note that on Linux, the browser engine (QtWebEngine) is installed/updated separately from qutebrowser. They have a new feature release (updating to a new Chromium baseline) every 6 months, with patch releases backporting security fixes every 1-2 months. Not optimal, but some Linux distributions also backport security fixes as soon as they happen, which is much more often: https://codereview.qt-project.org/q/project:qt/qtwebengine-c...
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.
Huh‽ While running with QtWebKit still happens to work, qutebrowser has supported QtWebEngine (based on Chromium) since 2016 or so, and it's been the default since v1.0.0 in 2017. If you're still using it with QtWebKit despite the warning being displayed about it, or using a heavily outdated qutebrowser version, that's on you and not qutebrowser...
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).
Ah, Verso looks nice and active, that wasn't on my radar. I kind of lost hope after a lot of embedding tracking issues and meta-issues over the years (the ones you linked is the third one I've subscribed to I think).
See https://github.com/qutebrowser/qutebrowser/issues/8389 - unfortunately there's a lot of stupid false-positives especially with PyInstaller (packaging a Python application into an .exe). Happens a few times a year, unfortunately there isn't much I can do other than submitting a report to Microsoft and hoping they'll react ¯\_(ツ)_/¯
Please, tackle the _real_ issue: we need an implementation of a modern 'web browsers' using a 'simple computer language' (for instance C99+, namle C99 with few bits of c11 for modern architecture programming).
Come on, this was about the language syntax, not some external massive util library. Ofc, this web engine would implement mostly its own utils, since dependency on external kludge like unistring or ICU or even worse harfbuzz(c++!)... would nullify the advantage to depend on a simple computer language.
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.
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.
You always cherry-pick the code you want, and in the worse case scenario you port it or the part you want from it (open source powa). Often, performance critical code paths of significant size are assembly anyway or when small, they are built-in to maximize inlining to avoid a function call.
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.
Nyxt is basically a front-end to the Big Tech web engines, yes, but one that (I think sincerely, from my not-overly-technical standpoint) attempts to re-empower the user.
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:
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:
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!
This was a ironic comment: the grotesque and absurd complexity and size of a Big Tech engine (google blink/geeko | apple webkit) with their SDK (c++ compilers, gcc/clang) kill any "real-life" attempt at interop. You would need many, MANY good devs, for a significant amount of time to maybe acheive 'real-life' compatibility in, pheeew, some significant amount of time... if ever... And even when you get something "working", don't forget they control also the online services requiring their pieces of software... namely those guys will have to play cat and mouse about interop: permanent little changes on Big Tech services (more or less justified) and Big Tech web engines, breaking any other alternatives... I think you get the picture.
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.
big tech is evily smart: since everything is open source, they are still doing vendor lock-in via grotesque and absurd complexity and size, breaking little things here and there, or using unspecified part which is "implementation defined" etc. Not seeing that is borderline blindless than a lack of perspective.
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).
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).
If you are looking at a link you want to follow, you press a single hotkey (default 'f'), and just type the two letters that appear directly where you're looking. If you want to open a lot of links in the background, e.g. if you're looking at the front page of HN, you can use the rapid follow action (default ';r') and just type a couple letters for each link you'd like to follow.
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.
FWIW I got some of the way through embedding a PDF viewer in Tridactyl [1] so that the keys would still work there, but I backed off because I was a bit scared by how frequently pdf.js gets updated. In Tridactyl it'd get updated about twice a year so we might end up with unresolved security issues.
Maybe there's a solution I've not thought of (CDN?).
> press a single hotkey (default 'f'), and just type the two letters that appear directly where you're looking
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.
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.
My theory is that some people see use of a mouse as a sign of noobery - which is true in some cases! Who do you think is more pro - the person who clicks Edit->Copy, or the person who clicks Ctrl-C?
So their lizard brain thinks "mouse=stupid, keyboard=smart" and then they optimise for a sense of superiority.
I prefer the keyboard due to severe tendonitis in my wrist and arthritis in my hands. I can use a keyboard all day with no problem. A few hours with a mouse leaves me all swollen and in pain.
I used to get what I thought was RSI. I mean it was RSI. I tried all sorts of weird keyboards and mice (don't bother with vertical mice, they suck).
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.
I wonder why you'd imagine that ergonomic input devices would solve a problem with your seating arrangement? I think generally they solve issues that are left after posture has been fixed.
Switching back and forth between keyboard and mouse is a pain. I used QB a lot at my last job but current one has too many things which need passwords entered frequently so I am reduced to vimium and chrome.
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.
reply