I think this is the second or third time that I've seen this browser hit the front page. Each time I get a little more interested.
The concern that I have is that there's going to be a learning curve to picking this up. Normally, that's fine, but this is my browser. I live in the thing and there's no other piece of software outside of my IDEs that affects my productivity more. When I took the time to learn VIM a few years ago, retrospectively, I could have about spent half as much time learning it as I did and skipped a handful of things I don't use. The tone isn't meant to be negative -- that 50% is tremendously useful and it's rare that I don't over-learn something (I enjoy it).
I'm hoping someone who uses Nyxt as their "primary browser"[0] might be able to provide their thoughts on any of my questions --
I use VIM/VIM plug-ins, but Firefox; what's the experience of becoming proficient with Nyxt?
Is there any tool/first-timer/quick-start that works better/worse for acquiring the muscle-memory?
Outside of "keyboard" ... As a full stack web developer (various front-ends, mostly .NET web FWIW), what are the "big reasons" that I want this (killer app?)? Put other ways: Are there any interesting "one-liners"[0] that solved real problems developing web-sites? Is there any feature that is so amazing that you agonize over it not being available when you're not on your own hardware?
Basically, I'm trying to answer (for myself) whether or not it's worth the effort to explore integrating this into my work tooling, so I'd love any other input.
[0] I've not used the product; I'm referring to its programmability -- I can see its use (and do this, today, kludg-ily) -- but I'm wondering if there are any use cases that were surprisingly "magical".
If you think of this as an interactive API over your browser, there are a lot of possibilities, as it significantly lowers the barrier to entry for browser dev.
One thing I’ve always wanted is a way to sync cookies between my browser and curl, something like that would be relatively trivial in Nyxt, assuming it exposes APIs for managing cookies (and if it doesn’t, I’d imagine it would be easy to add).
I can easily imagine myself writing little functions like I do in Emacs to automate various things, like iterating over all my tabs and shoving their URLs into a text file, or searching through the content of all open tabs, or adding little menu shortcuts like “append this highlighted text to an email message text box in another tab”, or “take the highlighted text, construct a new URL based on it, and open it in a new tab”. I do these kinds of things all the time in Emacs and I love it, I would be excited to use a browser with the same ease of extensibility.
I can also imagine, if the community is large enough, that people smarter than me will come up with libraries for Nyxt that blow my mind. This always happens to me when a powerful tool is combined with a strong community.
I don't use Nyxt, but I use a similar browser called qutebrowser. It is keyboard-first, and there are even a few things for which mouse bindings haven't been added yet.
I had a similar experience as you describe, where I first heard about it a couple of times, but backed off from the learning curve.
Eventually, I was fed up with the second-class-citizen state of keyboard bindings in Firefox and Chrome via Vimium/VimFX. I think the XUL "deprecation" effort was the final straw for me. I remembered browsing with Opera years ago, around version 4.x or 5.x, when keyboard bindings were first-class in Opera. I decided to lean in and do it.
It took me about three days of retraining myself and looking into the cheatsheet on a regular basis before I became productive, and a bit longer to really feel an improvement over the previous ways. But now I would never go back, and I loathe having to open Chrome for slow heavy sites (it's still faster.)
I really feel like I'm in a whole new world of browsing, where the browser really works for me and helps me access the information as quickly as imaginably possible.
It's one of the most "futuristic" things I've experienced, just pressing the keys on the keyboard, a bunch of "gibberish" appearing in my screenkey feedback, and the browser dancing around the pages, doing exactly what I want (except when I accidentally start typing out of insert mode.)
I can give you example snippets I was able to write for Nyxt, that I find quite exciting, as premises of an integrated platform, bluring the lines between a web browser and other applications. I don't agonize in not having them in other browsers, yet, but I still find the Nyxt capacities they illustrate exciting.
- first, there's a simple file manager in Nyxt (Webkit's), the open file command is bound to C-x C-f, just as in emacs, so it's at easy reach. We can open a directory view, an HTML file, a video in Nyxt. I wrote a snippet to dispatch to the right application depending on the extension. There was no such thing buit-in, but I could add it. Similarly, I added a command (M-x open-home-directory) to open the home directory. It's easy to write such simple commands.
- there's a built-in git cloner (I contributed it, uh). M-x git-clone and it asks for a directory. I can open a file or directory with emacsclient.
- we can write hooks: I have one to open reddits links in old.reddit.
- I have M-x download-video (built-in maybe?) that fires youtube-dl.
- I have M-x fip-radio-save-current-playing-song, that scrapes the song data on the radio's website and saves it in a text file. I can view them in HTML, I can M-x listen-saved-song, that searches it on youtube (it could find on a directory if I already have it).
=> they are little things that I usually do in a terminal that I now do in a browser. Nyxt gives me a nice fuzzy completion prompt for any list of strings, it gives me the possibility to print rich text, etc.
There's something I didn't manage to do yet but am wanting very much, is to be able to react to Webkit web events. Last time I checked they were not exposed on Nyxt, only on the C side. I would react to button clicks, I would add new buttons on the page and react to them. That'd be awesome.
All this is written in Common Lisp, that is strange at first (rest assured, you're normal), but it's a great language with a long history of industry use, so it's solid and it's good to have it on my toolbet. I am now lauching new services in CL rather than in Python, that is so slow, unstable and error prone.
This is a cool project that I have tried a few times in the past. To me, the big draw is that it is written in Common Lisp. I was a patron contributor for a while, but when I had problems building from source, I stopped. Interfacing Common Lisp to things like WebKit, GTK, or Qt to build Nyxt was probably the reason I failed building from source, IIRC.
This is probably a bad analogy, but forty years ago Lisp Machine subsumed the operating system. In modern times, in some sense the web browser is like an operating system layer, or at least a portable application platform. So, my bad analogy is that Nyxt is like a Lisp Machine.
If I have time, I will try to build from source today. I just reread the dev source install instructions, and it does look straight forward. Hopefully being on a M1 MacBook won’t affect the build process.
This is the vision from my understanding. I think of it as Emacs for the web, instead of just text. Super compelling vision, I really hope they can pull it off.
I’ve tried Nyxt a few times but I find it quite difficult to hack on, at the time it required an elaborate Emacs + SLIME + Common Lisp setup…I don’t use CL very much so it was a lot of work and quite fragile. I hope they can get editing bootstrapped into Nyxt so that I can modify it in Nyxt itself instead of a bunch of complicated external tooling. As it stands, there’s too much friction for me to hack on it.
Regardless, tons of promise and I’m eagerly following its development!
> Nyxt is web engine agnostic. We utilize a minimal API to interface to any web engine. This makes us flexible and resilient to changes in the web landscape. Currently, we support WebKit and WebEngine (Blink).
Well, it depends how Nyxt works, if it wraps entire browsers or just web engines. Also, Gecko isn't a separate component/library to Firefox so they would have to do major surgery on Firefox to extract Gecko.
Congrats to the Atlas team on the release! Nyxt truly delivers on the Emacs experience in the browser, and the addition of data-profiles to give a Firefox-container-like experience lets me use it as my daily driver.
Yup, there are quirks from what I'm used to with Firefox + vimium but with Nyxt 1) I can actually understand and modify the code, and 2) it's delightful to have a browser I can use so keyboard-centrically
One of the last gaps for me is being able to use a yubikey from Nyxt, but there's an open issue in the repo which feels accessible :)
I can invoke the browser from the build directory.
3. Is there a way to clear things like history, cookies, form data, and saved passwords (either immediately or automatically when the browser is closed)? It's what I do with firefox. Also, is there a way to automatically clear the cached stuff in ~/.cache/nyxt?
One question I had, which is partly answered in the FAQ, is what rendering and JS engines are used.
The FAQ says it can run on either WebKit/WebEngine (Blink) – how does it decide? Which is the default, and are there tradeoffs to using one or the other with Nyxt specifically?
The FAQ entry talks of their being a basic interface: the point is that these two engines have code that realises this interface. Other engines could also provide implementations of this interface.
I'd be pleased if a Servo hacker stepped up and did this.
I hope someone rolls by and answers: I am at the stage of following enough to be interested in the concept of integrating all the parts of a DOM engine with a proper GPU-friendly compositor in a modular way, but not at the stage of understanding the interfaces of the modules.
Just tried it and my first impression is: "this was built for me! I love it!". One bit of friction: I'm in vi mode. I hit 'f' to follow links. Apparently I need to hit 'i' before it will accept input. It would be better if it started in insert mode. Example: 'f' followed by 'g' just prints 'pressed key g'.
The download page says I can install from guix but I don't see it listed as an installable package in "guix search" or on https://guix.gnu.org/en/packages/N/
I'm thinking of adding code to macroexpand any links that people post to previous HN threads into the same format that you see here: "Title - <url> - mm/yy - (number of comments)". I'm not typing that shit out manually :)
Rather than asking what features does Nyxt have now, I think it is more useful to ask what do they not have compared to something like Firefox or Chromium.
I will be very happy if someone can list down the most important features that are lacking in Nyxt.
Thanks for the question, we hint at in our FAQ “ Nyxt differs fundamentally in its philosophy- rather than exposing a set of parameters for customization, Nyxt allows you to customize all functionality. Every single class, method, and function is overwritable and reconfigurable. You'll find that you are able to engineer Nyxt's behavior to suit almost any workflow.”
https://nyxt.atlas.engineer/faq
Why are most open source browsers based chromium as opposed to gecko? I would think much of the OSS community would be opposed to using google owned software.
If I remember correctly, it is much harder to use Firefox's components outside of Firefox than it is to do with Chromium/Blink. There is a reason why there is no relevant Electron alternative based on Firefox/Gecko. On Android the situation is different but not on any other platform: https://mozac.org/
Historically, Firefox has been the only moneymaker for Mozilla. It is possible they didn't want to make it easy to embed so anyone can create second FF on top of their work and compete without paying dues. Electron and single applications built fully on top of browser engine alone is relatively new, and possibily out of Mozilla's field of vision back then.
But, that is speculation, and I have no proof whatsoever other than tangential conclusions from Mozilla's blunders in recent years.
A much more realistic explanation would be that any software that isn't specifically designed in a decoupled way will be coupled at a million points and impossible to separate.
The only upside for Mozilla is that making Gecko available is the right thing to do. Which, for a nonprofit, matters, and I'm sure that having an Electron-equivalent is the kind of thing that would be considered cool by staff.
But there is the downside that it makes it easier to build browsers which would compete with Firefox for the shrinking niche that is "doesn't run Chrome or Safari". I guess you could make a case that such browsers would take at least as much share from Chrome as Firefox, maybe more even; but you could make the other case as well.
When you add the additional downside that it's probably many man-decades of work to do it at all, well, then it doesn't happen. Although the existence of GeckoView implies that Firefox and Gecko aren't as tightly coupled as they could be.
Isn't that the point? Making the engine decoupled and embeddable just wasn't on Mozilla's radar, and it suffered as a consequence.
Chrome team was advcied very early in their development by none other than Android team to go for WebKit because it was easier to work with. Not Presto, not Gecko. So at least since back then, thud feature was at least somewhat on Apple's list of priorities. I'm not sure if it got carried over from KHTML, but if it did, they didn't break it intentionally.
Back in IE horror days I remember using Avant Browser. It used IE to provide fancier features like tabs. I never remember Gecko anywhere in discussion for being a platform to build on top of, except for other Mozilla projects (FFOS, Thunderbird) that Mozilla dropped sooner or later.
Mozilla making money? LOL. Google just sends them spare change, pretending to pay for placement, to have an alt browser to show to antitrust authorities. Third-party use of Gecko satisfies that too.
So if someone else makes a browser off Gecko, then that one can satisfy Google's requirements, minus the special agreements Mozilla makes for search data, and suddenly there is mo reason for Google to pay Mozilla any more..
If Google stop paying for Gecko to track Chrome, it will lose feature parity, become unusable and fall out of use, where they can again be accused of monopoly. It seem unlikely someone doing a wrapper UI on a browser engine can fund that sisyphean task.
I am sorry but you are wrong. I remember times when first company forked WebKit to make their WebKit based browser (it was apple creating safari, or if my memory is wrong it was Google and their chrome). Mozilla foundation was much upset they didn't choose Gecko. But the company (Apple?) said it was because easiness of own implementation. Gecko was too hard to adapt.
Conkeror (basically Nyxt on xulrunner…exactly what the upper comment is asking about) used to be my browser of choice. It was baffling to me when they deprecated xulrunner. Like, why?
There was supposed to be an alternate way to do it (running with ‘firefox -app’ or something), but it was poorly documented and constantly breaking in new versions, so I eventually gave up.
They have Geckoview on Android but from what I've heard there was no interest in making that available for other platforms, and this was before they fired a ton of their technical staff. A shame really!
Yes. There was an experimental project called Positron [0]: "a experimental, Electron-compatible runtime on top of Gecko". It was discontinued in 2017 [1].
AFAIK the only thing around nowadays is GeckoView [2] for Android.
I think that Mozilla has a project for decoupling the browser components but I'm not sure if it will result in further projects. The name was something like project Stylus, but I can't find it now and I might be wrong about the name.
I was working on replacing QtWebEngine(chromium) for Qutebrowser with Servo. It is very far from ready, most websites do not render correctly and JavaScript is very hit/miss with regards to updating the rendered view.
Simply put: Servo is not possible to use as a daily driver.
Unfortunately since it was a non-starter I didn’t package the work nicely. Can probably package it up if you really want it. But like I said: the rendering engine was not usable. The overwhelming majority of websites did not function.
Servo is not yet ready for everyday use. Moreover, Mozilla fired most of its team working on it, so notable progress is not to be expected in the short term :(
Imo, browsers need to have a standard specification and one that includes an open source versioned controlled reference implementation of the core parts. It seems chromium has become that standard (chromium is open source afaik, not owned by google).
I often argue against purely natural language specifications in favor code based specs. I just don't think human language is nearly precise enough to write an adequate specification. Natural language words are incredibly polysemic and contextual. Look, for example, at how many meanings the word "break" has: https://www.merriam-webster.com/dictionary/break
The ideal language for a pure specification might be a mix of natural language and pseudo code with a pseudo test suit. However, if you are writing that, you might as well go one step further and write working testable code.
I like the concept of Literate Programming (https://en.wikipedia.org/wiki/Literate_programming) and its descendants of having code with extractable inline comments that auto generate documentation. I would argue that modern pull request based workflows that tie discussions to version controlled code changes are also the progression of this line of thought. A cleaned up version of these might make sense for a specification.
And I get some of the concerns. While natural language under specifies, reference implementations over specify. This is more of a problem with low level languages however. Modern high level languages are getting fairly close to a form of pseudo code. I fully agree that the reference implementations shouldn't contain or should hide, low level optimizations. I also understand that reference implementations can unduly tie specs to specific hardware, OSs and platforms.
But to me, over-specification is less of a problem than under-specification and it can be mitigated by labeling particular functions or blocks of code as implementation specific and not part of the spec.
Without spec written in code, the different implementations always have subtle incompatibilities. I see egregious versions of under-specification in government where horrendously vague specs are created in order to issue RFPs for getting software built. They usually end up with non working software at mind blowing cost.
People have this weird misconception that you are contracting out to build software. You are not. Building software is really easy. You press the build button or type the compile command. Building software has been fully automated for a while now. What is difficult is designing software and specifying what it must do. This is because there is a vast jungle of protocols, business flows, hardware and software platforms that need to be interacted in different ways for different needs. This is what needs to be specified and only computer code can do it adequately.
I wish that Mozilla adopted the chromium core. We really need a well funded non-profit managed release of the reference browser.
My only concern is that one ends up with something like TeX, written in a long-obsolete dialect of Pascal, requiring a translation layer to convert the source into a more relevant language (C).
I suspect the answer is because of compatibility. Chromium has become the industry standard, everyone tests only on Chrome (and Safari for mobile) so you can expect fewer issues if you're based on chromium.
But I think it's a valid question. Because for a niche browser (which most of these alternate projects are), mainstream compatibility for all websites doesn't seem like it would be the most important thing. I think the idea of using Gecko[0] is a solid one. :P ;) xx
I agree it's a valid question and it seems my suspicion is not the main reason. Based on the other replies to the parent it seems that choosing Gecko requires more work.
There are many good ideas, it look like. Many ideas are ones I had wanted, so, it is good. But, not quite everything.
Does it support customizing the interpretation of HTML and CSS? Is the web developer console implemented (it is useful for end users too, not only web developers)? Is there a split-screen mode? Can it auto-generate a table of contents? Is the jar: URI scheme supported (I used this to view EPUB files)? Form data saving to local files? Footnotes? Relative URL entry? JavaScript Date spoofing? ARIA view? Regular expression search? Better file selection? Can HSTS be disabled? Animation control? SQL (another way of sorting/filtering tables, copying them to external files, etc)? Adding or changing MIME type handlers? Does it pretty print JSON files? Disabling sounds is implemented, but can you adjust the volume or divert the sound to an external program (that will receive the audio on stdin)? Disabling scripts is implemented, but can you "partially disable" scripts (so that some APIs work and some don't or have a different behaviour)? Can you define your own character encodings? Is there any way to use extensions written in C?
Some of the things I listed might already be implemented, and some can probably be implemented easily enough in Lisp, but some might be more difficult to do.
There are a lot more things I would have it done differently, requiring probably modifying the engine significantly from common web browsers, I would guess.
Cool project … tried it in an early version and will play with it again.
Was just wondering. From the FAQ there are no links or indications on how to configure it in Vi mode.
Also the FAQ mentions the manual/tutorials for „here‘s how you configure it“.
maybe I missed sth. Being on a small screen (phone). Yet I was just interested in how the configure / change to vi worked and could not find that on the website.
Recommend to add links to the FAQ. Is there somewhere a quick how-to/setup for the vi mode and maybe a walkthough of cool features? (Found qutebrowser way more accessible and stayed with it so far)
I really like the way Nyxt generates keyboard combos for clickable links (like this image [0]). Does anyone know if there's a program that creates something similar for Windows? Where every clickable element in the focused programs would have one of these tags generated for it.
You’ll find many pantomimes of this in other projects. As far as I know Nyxt’s style (showing the URL, title, type of element, and being able to select based on those) is unique.
First, I want to programmatically control what I see on some websites. For example, facebook, linkedIn, or more websites are too distracting, so I'd like to directly fetch some information from them with my signed-in accounts.
I use vimium and I love it, but I actually still use the mouse for navigating page links.
Many of the websites we use these days are so link-heavy (or just not designed with keyboards in mind?) that pressing f, parsing the characters of the link I want, and then typing them, is still slower are at least more mental effort than using the mouse.
True, this was my problem with vimium as well. The characters of the link would change even for relatively stable UI functionality like going fullscreen on Youtube. So, there was no muscle memory. Ironically, the only time i would remember i had vimium installed was when i would try to press f and then press a couple more characters while wondering why i installed the plugin in the first place.
Really? That was my favourite part of using qutebrowser.
I'm already looking at a link when I want to 'click' it, so bringing up the shortcuts puts the relevant one right in the center of my vision. I don't know if it was faster (I have the same question about vim!) but it was fast enough, and more satisfying.
Then again, the point of my i3/qutebrowser/etc box was to be keyboard-centric, and I would use it with a "the mouse is lava" philosophy. I should really stand that box up again; too much macOS is bad for the soul...
For a long time I have been willing to write a personalized bookmark manager with a custom way to store and recall them. Nyxt looks like ideal platform to get started.
A major thing that puts me off using it is that it does not have a dark mode. I hope that will come with ability to use some chromium or firefox extensions.
Our bookmark facilities are quite advanced. You can query by tag, date, name, any combination of things really. I would give it a short investigation. :-)
It has a nice dark mode feature for web pages that is built in, but it doesn't apply to every page by default, or affect the prompt-buffer (minibuffer).
Also the code for that theming article doesn't really work, but if you fiddle with it you can get it going somewhat.
Pretty cool, definitely going to look more deep into this. Been using vi which is supported just not sure till what extend, will be messing around with it for a bit.
It look like interesting, although I would think to really make a better web browser, would require heavily modifying the engine or writing a new one (so that the handling of HTML and CSS can be customized too), rather than using the existing one. Also, I would want to support extensions written in C.
Flow sounds really cool, a multi threaded browser engine. Most modern ones are forked from KHTML, an engine designed in the 90's before multi threading was possible for consumer computers.
They only have 8 developers on the team. I wish them well, but what do they have to offer that vendors and consumers really need? Do people really complain about Chromium being too slow? I wouldn't imagine, if most of the users on the web are using it. Then again I don't know about the niche mysterious world of elite internet browsing.
So I don't like the GP's attitude at all, and I am stunned at how dismissive an unkind they've been on multiple posts about Nyxt.
But I think I'm beginning to realize more concretely what they mean about potential security issues with Nyxt and the way it reuses engines from other browsers.
I think it's something like this: some functions in engines written for other browsers may assume that they will only be called from other parts of the browsers they're designed for, or similar browsers. They may assume some inputs are safe, or that they'll only be invoked in the context of a sandbox or whatever. That assumption may hold in their original uses, but Nyxt could expose them to novel uses where those assumptions are untrue, and that could have security implications.
I think maybe this is the reason that GP assumes Google might go out of their way to break compatibility or discourage the use of their engine with Nyxt.
I guess what I'm left wondering is: is it obvious that this would be a negative for Google or Apple or whomever? Why would we expect the security fixes needed for calling some functions in unexpected contexts to get in the way of the engine developers?
How could you see that relationship playing out, if Nyxt exposes vulnerabilities in these engines that aren't reachable from the browsers they're designed for?
The concern that I have is that there's going to be a learning curve to picking this up. Normally, that's fine, but this is my browser. I live in the thing and there's no other piece of software outside of my IDEs that affects my productivity more. When I took the time to learn VIM a few years ago, retrospectively, I could have about spent half as much time learning it as I did and skipped a handful of things I don't use. The tone isn't meant to be negative -- that 50% is tremendously useful and it's rare that I don't over-learn something (I enjoy it).
I'm hoping someone who uses Nyxt as their "primary browser"[0] might be able to provide their thoughts on any of my questions --
I use VIM/VIM plug-ins, but Firefox; what's the experience of becoming proficient with Nyxt?
Is there any tool/first-timer/quick-start that works better/worse for acquiring the muscle-memory?
Outside of "keyboard" ... As a full stack web developer (various front-ends, mostly .NET web FWIW), what are the "big reasons" that I want this (killer app?)? Put other ways: Are there any interesting "one-liners"[0] that solved real problems developing web-sites? Is there any feature that is so amazing that you agonize over it not being available when you're not on your own hardware?
Basically, I'm trying to answer (for myself) whether or not it's worth the effort to explore integrating this into my work tooling, so I'd love any other input.
[0] I've not used the product; I'm referring to its programmability -- I can see its use (and do this, today, kludg-ily) -- but I'm wondering if there are any use cases that were surprisingly "magical".