The better part is that the UI is actually programmable. If you use vim plugins in other browsers, you'll notice that the UI doesn't always respond. This is because the UI is injected into the page as an iframe or something.
This is not the case with nyxt. It's like using the old Firefox plugins before they killed XUL.
Unfortunately, I couldn't get used to using Nyxt. The performance was too bad. I'll need to try V3 and see if it's any better. It's entirely possible the bad performance is my fault as well, but I'm too lazy to try and debug browser performance nowadays when alternatives just work.
I deeply want to adopt Nyxt, but it's hard to give up all the niceties of Firefox, mainly plugins (ublock, dark reader, cookie autodelete, multi-account containers, etc.).
It can never be the Emacs of web browsers because the browser engine is written in C/C++, not Lisp and therefore minimally extensible through a very restricted API that is not even controlled or influenced in any way by the Nyxt team. I guess they could fork an engine but good luck with that.
Last I checked, it didn't even support uBlock origin. That alone makes it a no-go for me and I imagine most folks who visit HN.
- The Emacs team is in full control of both the C parts and the Lisp parts of Emacs. Exposing a C bit to Lisp, or introducing changes to the C core to benefit the Lisp parts, is frequently taking place.
- What most people perceive as Emacs is implemented in Lisp and is extensible in Lisp. The C "core" is mostly the GC, low-level VM implementation and OS interface. Hardly bits and pieces that one would like to extend in Emacs Lisp.
Nyxt is designed to be engine agnostic, which means it had a defined api you could plug any engine into, even one you theoretically write yourself. Obviously this is impractical, but I’ve seen criticisms that emacs doesn’t have that exact ability — see the project mage docs for a detailed explanation of one of those criticisms.
