Hmm, not sure it's for me (a bit too much hacker) but I'd definitely like a highly customizable, module based browser with a pure shell by default. Something like Visual Studio Code but with less cruft from the get go.
I've never thought about it until I saw this! Now I'm really irked about there not being a solid, mature browser based on extensibility. Where the base is basically an address bar and history awareness (i.e. back/forward) and even bookmarks is a module, so that you don't even need an integrated solution but can instead rely on e.g. Raindrop.io as your bookmarks manager. Tab management another one, so for example you could have _only_ a powerful vertical tabs mode if that's all you need.
You know what, it feels like this should have happened 20 years ago and it would be as popular as Vim or Emacs now, but somehow never actually did. It would be the ultimate response to Chrome, Edge, even Firefox feature creep, forcing its developer to commit fully to web renderer excellence (speed, RAM, web standards) and maybe some optional official modules if you want them.
There are always going to be limitations to extension-based approaches but Firefox with tridactyl is most of the way there capability-wise IMO (https://github.com/tridactyl/tridactyl). I use that plus tree-style tabs and find it excellent. There's always some extensibility limitations that break the integration though, like extensions getting disabled on mozilla domains.
I love projects like nyxt and respect their priorities, but without big-player extension support it's usually a no-go for me. Still, I'll be interested to see the ideas they develop trickle out into the rest of the power-browser ecosystem. I especially like that lossless tree history – history management is a very under-explored UX area IMO
Oh thank you so much! Some of these exclusions make some sense to me but having my ctrl+n mashing interrupted by support.mozilla.com was fairly frustrating. Also security wise if I install a malicious extension with permissions to abuse these domains I'm already a goner haha
I use to build my own like this with the VB web browser control. I had tons of automation built in for a lot of tasks but it becomes too much to keep up with. I've looked into headless chrome but it's not as cool as working in the Visual Studio and being able to pause and just develop on the fly.
Honestly it was incredibly cool but websites just get more and more complicated. From like 2004 to maybe 2014-2016 it was great. Somewhere after that, I'm not sure, something changed, maybe me, but it just became too much.
The web standard really has exploded since that time range you mentioned. Nowdays there's a native browser API for text-to-speech. It's easier to generate speech for an article you wrote than it is to style an option in a native <select> element
uzbl (https://www.uzbl.org/) used to do that but it seems it was too heavy in practice.
Today I'm more interestea in turning the web into a more textual format to integrate it in acme (http://acme.cat-v.org/) which is already built around modularity. Making the web a content provider and letting me interact withit the way I want
We basically had this with old Firefox, didn't work out. We kinda have and had this with all the small custom browsers, like Qutebrowser or Nyxt here, doesn't work either. Customizability is a liability, it's work. It comes with many problems, responsibility, work for the users, and not many are willing to take this. Chrome, Firefox and the others are more or less the best we can get regarding balancing customizing, stability, security and user-friendliness.
I mean even in Editor/IDE-Space the popular tools are not the ones who give you the most customizability, but those who give you enough customizing, while not bothering you with the rest, and instead focusing on stable powerful features. Maybe if Coding AI becomes stronger, we can reach this utopia of perfect customizability without all the problems.
I commented here [0] and am extremely interested in discussing BrowserBox with you. This is something I've brought up over and over, I'm an experienced web dev and generalist but simply couldn't tackle on my own.
Curious about your roadmap with dosyago and BrowserBox, where our goals converge and diverge and how we can help each other. Feel free to reach out via email, it's in my bio.
While it may not be as technically elegant as using lisp, it greatly increases the count of folks who can contribute and simplifies the code with a single language for both front and back.
Secondly, while, in general terms, JavaScript is not as performant as Java or C++, for asynchronous real time operations, such as mostly used by this application, the event loop in node, a layer over io_uring, is a highly highly efficient method to perform these.
In other words, we get to trade simplicity for raw performance to ease maintainability, and less complex code means less security risk and bugs. In fact, the bottleneck in this application for performance is not JavaScript but network link latency, and the browser and the hardware that runs on.
Contemplating my navel, I propose that it didn’t happen because the purpose of an editor and browser are so different. (Realistically the driving factor is that an editor is much more useful for making money.)
> I've never thought about it until I saw this! Now I'm really irked about there not being a solid, mature browser based on extensibility. Where the base is basically an address bar and history awareness (i.e. back/forward) and even bookmarks is a module
If you guys are really into the idea of an extendable virtualized browser API, an extendable browser that you can hack on, and customize programmatically fully (including all the browser UI, the so-called “chrome”), then my BrowserBox project might be for you.^0^1^2
That open extendable browser is actually my vision of BrowserBox and I think it’s a really powerful thing. For example: I imagine being able to create an "extension store" using the more powerful set of APIs enabled by this (compared to the more limited APIs available to regular browser extensions). Similar to the idea you related where bookmarks is a module--which is something we've wanted to do for a long time--but not sure about the API contours!
The other ideas you talk about are all great, too: a UI that can be fully customized (vertical tabs!) or even tree tabs / history. Or all kinds of crazy things. Browser UIs are pretty uninnovative mostly, but a fully customizable UI could really open that up.
Modules ideas (that in some sense we've been exploring at Dosyago over the last few years, through DiskerNet, client projects, GraderJS and so on):
- web scraping / automation script builder
- vim shell
- vertical tabs UI
- bookmarks
- public / shared bookmarks
- full text searchable bookmarks (DiskerNet)
- NodeJS shell (GraderJS)
And I think BrowserBox may have the right model for that extensibility (maybe not totally right but the idea of: instead of using a WebView tag you’re using the much more extensible and powerful set of APIs for browser instrumentation and automation in other words, the "remote debugging protocol" APIs) to create the surface of extensibility. And our company has already built the the application with the browser UI at the front, and the instrumented browser engine at back to enable that building out an API. Our system is already a fully functional browser: with multiple tabs, back/forward history, but no other modules!
The main modules we have built so far have been: web scraping / automation script building for clients. We've experimented with other modules, but the majority of the work we need to do is around carving out the contours of that API. What surface do we provide in order to make modules really great? That's the key question and one we are looking for help answering.
Having that API for the browser to allow like a modules type thing is something that’s been on our plans for a long amount of time we always thought it was a good idea, but we’ve never been sure if there was much demand for it. Like you say here this Nyxt project really highlights the fact that this is something that really is a good idea or at least it seems like it and definitely people seem like they want it. There's still a lot of problems with this approach, but I believe they all have achievable solutions!
While our project may not be as technically elegant as using lisp, but I think it has the prosaic advantage of: having a simple client/server architecture (browser UI at the front, instrumented engine at the back); using a highly extensible set of powerful API‘s that are on essentially standard track with the WebDriver specifications (making, at least in theory, the future ability to swap out the browser engine between Chrome, Firefox, Safari, or whatever else that supports WebDriver); and I think most importantly--it’s written in JavaScript, Node.JS, HTML, CSS--greatly widening the field of potential contributors
I’m encouraged today by this project and the thread you have started to push our BrowserBox project more in this direction and I would like to encourage people to come on and check it out and because of that we are opening up our projects today to contributions. I think there's a lot of work to do and we can't do it alone!
Looks like Nyxt, a browser "inspired by Vim", inherits Vim's showstopper bug: Being unusable on many non-US keyboards, at least with the default bindings. The 'switch-buffer-previous' command is bound to C-[, which cannot be pressed e.g. on QWERTZ layouts because the [ character requires AltGr. This is like sending around text files encoded in Windows-1252 and expecting things to just work.
Sorry folks, but it turns out that the creators of Vi(m) didn't actually invent the ultimate UI paradigm half a century ago. It's bad enough that a text editor that ignores the past few decades of UX research is still in widespread use, but please, for the love of God, stop incorporating that broken paradigm into new products.
What a pity, because Nyxt looks like a well-designed piece of software otherwise.
Imagine if those precious keystrokes wasted on setting a keyboard layout could instead be utilized usefully. Say, to post some cloying, whiny critique of someone else's work, wherein one might go so far as invoking their diety in the hopes it might stem the tide of what, I guess, must be a massive recent influx of vi(m)-keybinding-based projects.
Having settings is nice, but I'm not gonna spend a lot of time configuring something that I'm not yet sure will even be useful to me. Power users of / users already invested in your product will use settings to great effect, sure. But defaults matter, if you target anyone else.
Actually, you probably understand that on a deeper level. Since we are not talking about a product where "you can configure vim bindings in the settings". Its just that you personally appear to like this default and seem offended by others preferring sth else.
The problem with defaults is, someone won't like them anyway, so trying to make them likeable to everyone, isn't going to happen, no matter how hard we try.
Using ViM as an example, using the keys that are prevalent on a US keyboard, was a sensible approach when it was developed, and since remapping the keys is probably one of the easiest things to do, it's also not an issue. In fact, writing a simple remap into a text file is easier than remapping keys in most "modern" editors, where the option to do so usually lives behind 2 sub-menus hidden behind a hamburger-button, and forcing me to scroll down an endless list that may or may not have a search function. And good luck if I want to export/import my config, or, god forbid, check it into a repo.
> But defaults matter, if you target anyone else.
Products have to target an audience and cater to them. That's how we ended up with alot of the modern webapps sharing the same usability problems, because "being like everyone else because that's what the audience is familiar with" encourages stagnancy, not evolution.
FOSS Tools on the other hand, have the freedom to explore ideas. If people don't like these ideas, they don't have to use the tools.
if Vim had the very same problem for US keyboard layouts it would have never become the standard choice for "hackers" (e.g. in a parallel universe where Vim was created by a Japanese for Japanese keyboards), so yeah, in general hackers hate when their tools don't work out of the box, hackers expect the very basics of any tool to work out of the box, changing settings should be a step to accommodate it to your liking, not to fix basic functionality.
> Not necessarily, since it’d just be a matter of popularizing Vim + the community’s preferred shortcuts as a starter instead.
There isn't that many software dev tools were a small variation in key bindings (or some similar small change) became ubiquious and propelled the popularity by adapting it to the local needs of American developers/IT (keyboard layout in this case), it's a chicken and egg problem because if Vim wasn't that popular there wouldn't be much interest in creation preferred shortcuts, so I conclude that what you suggested is not what would have happened.
Yes and calculators have the same issue. I mean, what about Indian numerals, Ethiopian and how does one perform a proper Coptic calculation using these awful devices with showstopping UX flaws?
It’s time we pander to each and every culture’s random conception of symbol manipulation and end this era of universal, gate-keeping, commonality. The time of personalized input devices is upon us.
Vim and thus this browser is unusable on my custom 20% HIQPK layout numpad.
Remember that most European keyboards don't have [ and ] accessible on the first/second level. That's already half of the western civilization, not some random's custom layout.
I switch between keyboard layouts all the time, depending on which input language I need to use.
I simply cycle between the langugaes I write in(Swedish, German and English) by pressing alt and caps lock.
I accept that U.S. English is the computer lingua franca.
I live in Europe and buy my Chinese-made keyboards from Amazon, US. In the company I work for, I have not seen a single keyboard with "European" layout. People who buy those keyboards aren't people who need to be good at using their editor, while on the other hand, people who want to be good at using their editor will buy a keyboard that works well with it.
Keyboard is a one-time investment of 20-200 Euro, but learning to use your editor efficiently is an investment of years of your life... amplified by the fact that there aren't that many good editors. So, any person who needs to work with the editor on a daily basis will have to make a choice between buying a keyboard that works well with that editor or a keyboard that allows them to type Euro / Pound sign more easily... And nobody in this situation is going to choose the keyboard that doesn't work well with the editor.
Yet nobody here has thought of just localizing the shortcuts like Microsoft Office and macOS have been doing for ages. Solves this problem very elegantly. Ironically, Word is the “professional” editor of most professions outside of coding, and people do learn the shortcuts to use it effectively.
This obviously varies by country, but at the places I’ve worked at, most people used the local layout instead of the US one. They couldn’t bother relearning it and then switching every time they wanted to enter some text in the local (Slavic) language.
Has the US keys on the first/second levels and most/all special symbols for European languages easily accessible w/ modifier keys. Entirely removed the need to switch keyboard layouts for me.
I'm from South America, and have lived in Europe for over 20 years, and I use a US layout, with compose key. It gives trivial access to accents and more, without the annoyance of different layouts (I used AZERTY for years while living in France, and it's just atrocious). I know many people here in Finland who code with a nordic layout, and for the life of me, I don't understand how they remain sane.
Yes, mine for example. Swedish keyboard layouts are horrible for coding. The [ and lots of other symbols require super weird hand movements to input. That is why when I code I usually use an American layout keyboard instead.
However, even if I wouldn't switch - wouldn't it just be to remap the keys in my config?
European here. I don't care, I don't use the Spanish layout, it sucks for programming. No one uses that at professional level for programming, US-Intl it's much better with the menu/super_r key as the 'compose' one.
Honestly, as a fellow QWERTZ-native, QWERTZ is generally a terrible layout for doing any programming in languages that go beyond round brackets. Instead have all these umlauts you rarely need, even in normal writing, right there - just a bad tradeoff.
One might even argue that it's terrible for some other keyboard shortcuts, as they stop making sense: E.g., when Ctrl+Z is undo and Ctrl+X is redo, that makes perfect sense on QWERTY, but is hard to grasp on QWERTZ. Yet this is seemingly never customized/"translated", even in software that customizes other shortcuts (e.g., in word processing).
So, long story short, do yourselves a favor and don't use QWERTZ for serious computer use ;-)
Spanish keyboards, while QWERTY, are terrible for this too. All the special characters are in a weird place and many require modifiers.
While I live in Spain now I still use the US layout I'm used to from the Netherlands. It means I can't type the Spanish accents which are kinda important but anyway...
The problem with this is that it works differently on each OS. Every day I use Windows, Mac, Linux and FreeBSD. I need an input method that is unified in every OS or I'll constantly mistype. Apple's different shortcuts for copy paste are difficult enough already.
Same here with Portuguese keyboards! I gave up on them 30 years ago and adopted UK or US layouts. For a long time I wrote a kind of pidgin Portuguese due to this but eventually learned the Portuguese layout by heart using both US and UK layouts.
Talking of rarely need, most 105-key boards have numeric pads that are dust covered. TKL layouts are the future and they have an additional fn modifier, maybe there's room here to add another purpose to it.
Not sure what language you speak, but in German umlauts can always be replaced with an ‚e‘ suffix.
Having written codebases in German, I’ve never seen anybody actually use special chars in a var names! (probably a carryover from the pre-UTF-8 dark ages)
This sounds like a lot of gatekeeping. QWERTZ types need not apply for serious computer use. Even worse are those ones who would prefer to write a proper e-mail using umlauts.
Now, you can complain about gatekeeping, or you can set up more than one keyboard layout (I have yet to run into a reasonable OS or DE that does not allow for this), and switch around when it's appropriate.
Other ways to accomplish this would be coming up with macros or custom shortcuts (e.g., with one or more modifiers), to type the characters you don't have on an UK layout.
All of this is way easier to do than to fix all the 'bugs' in well established programs that have shortcuts that don't work or don't make sense on QWERTZ (or, to take it further, in the native language attached to that language - :wq should be :sb in German. ;-) )
My intention here was not to gatekeep, but to make the case/share my experience that when I first forced myself to use a different (UK [1]) keyboard layout and set my computer to English, many things that previously were cumbersome and hard to remember and did not really make sense, suddenly were easy to memorize and made perfect sense. It was almost life-changing!
Now: Should (1) it be this way, or should (2) internationalization/translation be way better? Certainly (2), but I just don't see it happen, neither in commercial (cost), nor in free (lack of contributors) software.
I'm curious about what "decades of UX research" improvements you are talking about, to me everything about the UI for text editors or browsers hasn't improved much in decades. If you have a laptop with just a touchpad, chances are you'll never get better than vim keybindings. Moreover, the keyboard layouts themselves are centuries old.
> I'm curious about what "decades of UX research" improvements you are talking about
Here's the most important one of them: Don't surprise me. Blend in. Look and behave like other programs.
There are 50 applications on my system. Yours is one of them. If all other applications use 'Ctrl+C' for copying text, but your application uses 'y', then your application is the problem.
What are you talking about? I suspect you haven't used vim recently.
In the context of the command line Ctrl+C sends SIGINT, which usually interrupts/terminates a program. When I press Ctrl+C, vim shows "Type :qa and press <Enter> to exit Vim". All my command line programs handle it as SIGINT. Imposing Ctrl+C as copy would be inconsistent and surprising.
If I'm using Visual Studio with vim keybindings Ctrl+C/Ctrl+V are still copy/paste (I suspect this is because VS provides this and the keybindings don't override it). I think every other editor with vim keybindings I've used preserves this behavior. Ctrl-C as copy is consistent with every other windowed program I'm running. Where have you encountered vim keybindings that don't permit this?
But Nyxt (which is modeled on Emacs, not Vim) would blend in for me. I spend most of my time in Emacs and Firefox; I would prefer a browser that blends in.
I don’t know about 50 applications. The rest of the applications I use are more specialized, and have their own shortcut madness. Browsers ate most of the small stuff.
Thats a basic principle. But when you say decades of UX research you imply actual new ways of doing things
And something innovative and effective would be both self explanatory and actually useful, so it ultimately gets adopted by others instead of simply surprising and confusing people
That would be a problem if vim was installed front and centre on everybody’s computer and they were all expected to use it. That is not the case. You choose to use it, so you either accept, or better yet, embrace that y=copy, or you choose to use something else.
Trying to objectively describe vim as a problem by invoking UX research is very funny.
The end result of that logic is to rule out modal editors altogether.
Vi is several years older than the Ctrl+C shortcut for copy. How could it possibly have know that Ctrl+C would become a more popular choice for copying?
> Sorry folks, but it turns out that the creators of Vi(m) didn't actually invent the ultimate UI paradigm half a century ago
I have been thinking the same for years. Some guys at work used to add Vim bindings to their IDE and I just didn’t understand it.
I used VI back in the day when the choice was vi or ed. It worked well given the constraints of a Wyse60 or VT100. But I was happy to leave it behind for X windows, a mouse, and modeless editing.
So today, 25 years after I learned VI because I had no choice, the idea that having Vi bindings makes a tool for “hackers” is just not something that resonates with me. I’m happy to discover I’m not the only one.
What's key about vi is modal editing. Modal editing is very powerful. It also means not having to use the mouse for everything and also not having to type too many modifier key sequences. For some of us that's absolutely essential to avoid deviations that lead to injury.
I don’t really understand. Many of the common bindings in Vim use modifiers. How do you navigate back a word without a modifier? Do you just exit editing mode like in the old days? Do you just forgo this and arrow back?
In case it’s not clear from my tone, I’m totally sympathetic to relieving injury, and whatever works, works. I just don’t understand how Vim bindings help, and am genuinely curious.
Can you provide a concrete example, like a piece of text with the current cursor position, the outcome you want to achieve and the sequence of shortcuts you're using to achieve that with your favorite text editor?
> Navigating by word is my primary means of moving through a line.
So how does your new editor do that more efficiently than pressing <Esc> once, followed by pressing <w> or <b> once for each word?
Navigating by word is a matter of holding the Option key and pressing left or right arrow. Same number of keys, but works pretty much everywhere. The box used to enter this comment, for example.
Just to be super clear, I don’t care what other people do. Go nuts with vi bindings. I was just agreeing with what someone else said, that vi bindings aren’t peak UI and that “hacker” != “vi”
No, you suggested that leaving insert mode to navigate by words is somehow less efficient (since navigating by word is your primary way to navigate in lines) and that maybe that's why you're happy you stopped using vi.
Now we found out that leaving insert mode to navigate by words requires the "same number of keys", so @gsinclair was right and it is unnecessary to stay in insert mode for navigation.
> Same number of keys, but works pretty much everywhere. The box used to enter this comment, for example.
If efficient word navigation was the only thing vim key bindings had to offer I wouldn't be using them. But they do offer many things the current text box does not offer and since (as a programmer) I'm spending 95% of my time in an IDE and not some browser text box, I'll gladly accept some inconsistencies if that means editing and navigating in my IDE becomes more pleasant.
So you know what I find super weird is that - despite my other comment to you earlier about using vi since the early 90s - I can’t actually name the key bindings for vi with much certainty.
I’ve been using it for so long that apparently the muscle memory is the only memory I have.
I mean thinks like yy and p and ZZ sure, but for navigation I know where on the keyboard it is - but not the keys. (At least not while I’m using an iPhone keyboard)
Ah, I forgot some context: I use sticky keys, so for me shift is not a problem, but I still have bad habits from before discovering sticky keys so control and other modifiers -and especially multi-modifier combinations- are still a problem for me, and vi doesn't use that many of those.
Thanks for the context. It’s great that vi bindings help you. Is it fair to think of it as a assistive technology in your case? Do you know others in your situation who use vi bindings?
I was definitely on team vi in the Great Emacs Wars, but it’s not my preferred way of editing any more. Nevertheless it’s something that I know quite well, and this conversation has really opened my eyes to the idea that this sort of thing can help people.
> Is it fair to think of it as a assistive technology in your case?
I started with vi eons ago because it was easier to use it remotely to do my school work than it was to walk into the labs and use a graphical editor. The habit stuck -- vi has a steep learning curve, but it's also habit forming, so to a large degree I use vi because of the habits I developed.
However, when pain from ulnar deviations began to set in I had to experiment and research to find something that worked, and that was sticky keys, and I've not been in pain since. The fact that I didn't have to give up vi certainly says something, namely: that vi wasn't the cause of the injury. But also now that I understand what caused the pain (ulnar deviation), I shudder to think of using emacs.
> Do you know others in your situation who use vi bindings?
I do not, though I do very much recommend using sticky keys.
I have taught my son how to use vi and he loves it. Like I said, vi is habit forming, but good habit forming :)
> Some guys at work used to add Vim bindings to their IDE and I just didn’t understand it.
I‘m one of these guys.
I’m used to its text editing hotkeys from years of using it, but when jumping between a bunch of languages/environments it’s a lot easier to leverage the ‚integrated‘ nature of a lot IDEs (in my case Jetbrains).
Having to find, configure and remember how to use a bunch of different debuggers, linters, codegen tools and other tools manually is a pain
If you have trouble hitting [ how do you ever program anything?
I use multi-language keyboard layouts and switch all the time... when coding (or using "hacker" software like this, which is completely based on emacs [and as far as I know is written in Common Lisp], not vim), just use a layout that makes it easier (in my case, en-AU).
Entering [ works just fine on QWERTZ: You simply press AltGr+8.
But this doesn't work in shortcuts, e.g. when combined with Ctrl. That is, AltGr+8 generates the character '[', but Ctrl+AltGr+8 is not the same as pressing Ctrl+[ on keyboards that have a dedicated [ key.
This bug is decades old, and every Vim derivative suffers from it.
I use Cmd+[ on MacOS to "go back" on multiple software like IntelliJ, emacs (I probably configured it) and Firefox, so I would say this is a pretty common combo. It's easy to remember, specially given that the mirror, "go forward", is Cmd+]. As I said, even though my first language is not English, I only write code in an English keyboard layout so I've never even considered that [ is "hard to press".
EDIT: the Dr Racket editor even lets you write Lisp using '[' and ']' because they don't require pressing shift like '(' and ')' so are easier to press.
Using [ and ] is completely normal in so many applications. QWERTZ just is a bad design, and applications shouldn’t have to work around that by making keybindings more difficult. My team has ~100 engineers in QWERTZ countries and I don’t know a single one of them that actually uses it. QWERTY is the standard order for all new laptops. Nobody complains.
All the time while reading this thread I could not remember an issue like that from the time I used Vim/NeoVim. Perhaps it somehow did not affect me? At least in Emacs that works exactly like it should.
When a product is unusable without changing configuration, it absolutely is a bug. Being customizable is great, but being broken by default is not.
Besides, the whole point of Vim bindings is supposed to be that they are the same everywhere (muscle memory yadda yadda yadda). When you have to change core bindings to something random to make them work, that whole idea falls apart, and you're probably better off using the platform standard bindings for everything. Plus, you get the additional benefit that the software fits in with the rest of the system, rather than sticking out like a sore thumb.
> the whole point of Vim bindings is supposed to be that they are the same everywhere
No, the point is customizability to tweak it to your personal needs. Vim has the most flexible keybinding system I've seen in a program so far. If you want "same everywhere" any editor will do. I have never in my life seen anyone make this argument that one of the most customizeable editors is meant to be used without configuration.
> you're probably better off using the platform standard bindings for everything
Or maybe I use Vim exactly because it fits my workflow better than the standard that was designed for the average user as a series of historical accidents?
> When a product is unusable without changing configuration, it absolutely is a bug
It's not a bug, it's a design based on how 99% of input devices in the region it was created in work. Just like US electrical appliances that you can't just plug into European power sockets. And honestly you're blowing this way out of proportion, very few Vim keybindings are incompatible with QWERTZ keyboards. I know because I used Vim for years with a QWERTZ keyboard and never felt limited by that.
But the average vim user is jumping to new instances often, so if he has to reconfigure it everywhere he might as well install a different editor with a config.
I have over 100 custom keybindings in my Vim config and can assure you I can still use the default configuration without any issues, it's just a bit slower.
The few settings I find really important can just be quickly set with a couple commands. No big deal.
I am not sure thats true. vim does give you extra utility in its availability on a wide variety of server-type platforms, but I suspect most vim users are using it actively for development on their local (or docker etc) boxes
> Besides, the whole point of Vim bindings is supposed to be that they are the same everywhere (muscle memory yadda yadda yadda).
No, the whole point of ViM bindings is that MY bindings are the same everywhere. That's why it's main config is a simple textfile that I can just `git clone` or `sftp` onto whatever machine I intend to spend more than a few seconds writing code on.
Which, incidentially, is something that is an absolute PITA, if it's possible at all with the more "modern" editors, or on the off chance it isn't a PITA, usually depends on some specific platforms offerings.
> Plus, you get the additional benefit that the software fits in with the rest of the system, rather than sticking out like a sore thumb.
Well, from my PoV, what with i3 desktop, vim in the terminal, and the browser being the only GUI application that I use regularly, vim seems to fit in pretty well with everything else.
I‘ve heard this argument in variations from QERTZ users. The thing is, programming was invented with the QWERTY UX in mind. The fact that the German keyboard resembles the American keyboard for 80% of its Lay-out doesn’t change that.
You don’t hear the Arabic, Chinese or Greek crowds complain about this, they just switch layouts.
I've been programmer for about 20 years now and I could never understand why Vi(m) or Emacs exists with those weird bindings which are completely different from pretty much everything else.
I'm not that old, maybe they had their cake in 80s, but perhaps time to move on to something modern which would have modern defaults (if many need to customize there's something wrong with the defaults) that appeal to all keyboards.
> I've been programmer for about 20 years now and I could never understand
I doubt there's any hope for you... but from other thing you said:
> are completely different from pretty much everything else.
I can conclude that you were programming something that's not a typical modern computer. I.e. you never used things like terminal (with readline), never red a manpage, never used pagers like more / less, which would mean that you also never used the most popular operating system in the world, where, for instance, if you need to get access to its service logs, they'd open in a pager...
I mean... was it like 20 years of Scratch programming on a game console or something? Or maybe COBOL on a MF? Like, what were you doing all these 20 years that kept you so far away from the most popular thing in the world?
Hey, me to! I started with ActionScript. (Well, I've done some Pascal and QBasic before then, but that doesn't count.) I was kind of a big deal on actionscript.org, when that was a thing :D I also did some C# because of FlashDevelop (I wrote some plugins).
Also, was looking at JS/TS back in the days when I had to migrate away from AS.
> Yup, I'm pretty much working with terminal everyday,
Doing something every day doesn't mean you do it well. Apparently, in your case, you don't. Readline interface to the terminal uses the same keybindings as vanilla Emacs. You just somehow don't know it. Kind of weird, as there are hardly any keybindings to learn, and yet.
> most popular thing seems to be Vscode.
VSCode is, well, junk. And so is Linux! Popular doesn't mean it's good. In programming, it's actually rare when it's both. And people like you and me have contributed to this being the case.
You see, the difference between you and me was the stupid chance. When FlashDevelop was considering Linux support, they didn't have a good program about what to do with their text editing component (Scintilla) that was festered with p-invokes. So, in a very ambitious project I wanted to replace that component with Vim. That proved to be absurdly hard... and I quickly gave up any hope of that happening. But, I learned few things about Linux that, later, made me switch.
My first editor on Linux was Eclipse. I still used it on and off for a long time due to Flex Builder, and later Flash Builder. It sucked, especially because Adobe's support sucked, and eventually, they cut it off entirely. I was still patching the last version of Eclipse to get Flash Builder running, but, eventually, that became irrelevant.
Somewhat in parallel and increasingly more often, once I started working mostly on Linux, I switched to Vim. Ironically, because I wanted to work with Common Lisp, which is another hilarious misunderstanding story. After trying it several times and giving up, eventually, I switched to Emacs.
In my professional life, I was at that time hired by HP to work on some sort of a SAP knock-off that had its interface written in Flex. By the time the project was due, they declared to the customer they won't support Flex anymore, and switched to GWT (the Java framework that generated JavaScript). I didn't make it into the group of developers who were assigned to continue that project, however, somehow, I got reassigned to the ops team.
HP had a corporate IntelliJ license, and made use of IntelliJ products mandatory at work. My job in the ops team was to navigate the cubicles of desperate Java dummies hired into this mindless grind of Java/XML and "fix" their Maven builds. Usually, the fixing amounted to explaining to them for the zillions time the basics of using their editor -- the fabled IntelliJ IDEA. It was ridiculous how unproductive these people were with that monster of an editor. Ironically, quite a few of them would also use Notepad++ as a side hustle. But they sucked at that too.
Later on, I switched to supporting MSBuild projects in a different company, and had to battle the unimaginable stupidity of its MSVS users, who couldn't understand how their editor worked, and didn't care. It was a game shop that made games for "smart" TV, and they actually wrote them in TS.
I've seen editors like Atom or VSCode come and go. And I've seen quite a few users of those too. It's a choice for people who don't have or don't value the skill of using their editor. These people are in constant fear of the tools they use, constant anxiety about the next Git command they are going to type and how this will "ruin their day", people who don't know how to open a file without extension...
I don't work with such people anymore. Not in my day job at least. Though my wife, she has to deal with this kind of audience. And, sometimes, she has to call me to fix the problems these people create for themselves.
But, you know what served me faithfully through the years, no matter the language I used, no matter the platform, no matter how modern or archaic, no matter if in the cloud, in a crippled unter-computer, or in HPC setting, no matter if having X-server? -- And, always with great performance, and always keeping few tricks up its sleeve? -- That's right, Emacs. VSCode is so pathetically bad compared to it, it's ridiculous to even think that someone may suggest it as a hacker's tool. It's a toy "doctor set" from AliExpress in the real surgery room. Good for giggles, but that's about it.
So, back to how we contribute to the awful state of affairs in programming: we don't create a system of values based on research. We proclaim that thing X is better than Y. And sometimes also give rationalization that is complete nonsense. While we might have real experts, those aren't found in the places they should be: academia failed us -- their titles are worthless. Industry failed us -- it doesn't need quality, it ranks software success by commercial success. People like me and you may stay in the industry for decades and end up complete noobs. With the added aspect that after a long time of being a noob, even if nothing really changed the noobs start to believe themselves to be pros. And then they take to teaching others.
We belong to the wave of programmers which wiped the little accomplishment that there was there in the 70's and flooded the field with ridiculous unga-bunga nonsense that we sell as "programming". We are the lords of the flies.
Modal editing exists because the mouse didn't exist then, and it continues to exist because modal editing is very powerful because you get to be in a mode where you type commands for cursor movements, textual transformations, etc., which allows power users to be very productive.
I don't think I've ever seen evidence that emacs users actually need to be very productive in their text editor even if it works.
Though it might not work - the original Mac user research found that keyboards make users think they're faster, but don't actually make them faster, because of time blindness.
I wouldn't know. I'm a vi user. I don't know how much more productive I am with VI than non-modal editors, and even if I did know that would just be anecdotal, but I feel more productive coding in (Neo)vi(m) than I do in any non-modal editor, and it's much more comfortable anyways.
Vi has a steep learning curve, but once mastered, it is on-par or exceeds the best of other editors. It is also present everywhere (on Linux at least) and works via ssh as well as locally.
I'm not using it anymore myself, but I know and respect people who do. For me the tradeoff was not worth it, however it still annoys me to hell and back that I have to reach for the mouse so often in vscode.
I develop mostly mobile apps and I need to be using mouse/trackpad anyway frequently so that's not an issue.
Though about the keyboard part: I'm used to Vscode's keyboard shortcuts too (and I can in no way say I know all of it) and I can easily navigate and code in Vscode too.
Perhaps many people who got used to those tools developed muscle memory so much that they can't give Vscode (or anything modern) the chance it deserves.
I also use keyboard shortcuts (obviously), but in some cases it seems impossible to configure them - for example maximizing the terminal window vertically seems to not be supported by shortcuts.
There's really no mystery here. The reasons are the same as in every other part of society where outdated conventions are maintained despite massive, obvious problems. The phenomenon itself is as predictable as the arguments used by its defenders, mostly variations of "it works for me".
I think there's more reasons that are not so negative.
First of all, vi predates all those others. That means it's always had an active userbase werken other tools were in fashion. Changing the bindings at any point in time would have hurt a lot of people's muscle memory. It would also be extremely annoying when one has older versions on some machines with the old bindings and some with the new. I deal with the Mac vs Windows/Linux copy paste problem every day.
Also, vim just has a ton of functions and there's always going to be some shortcuts that will be awkward on some or other keyboard layout.
Finally, you don't have to use it :) or you could distribute your custom config file with bindings to every machine you use.
… or also because it’s significantly more productive than any other editor. But hey, it’s much easier for you to assume everyone making a choice for themselves is part of some cult than giving them the ability to think and make good choices.
I use heirloom vi (while making it clear when asked that I doubt the person asking me should do the same ;)
I was basically forced into learning vi to begin with (editing things on a -very- heterogenous collection of servers) but then found after a few weeks that I found it surprisingly pleasant and stuck with it.
Then again I don't recall sending a vi instance anything involving the control key except for Ctrl-C, Ctrl-L and Ctrl-Z.
It’s not problems, it’s opportunities you’re missing, because you don’t understand and aggressively don’t want to understand the actual reasons why people are using it, whining about elitism and other bullshit instead.
Ha, true! But also interesting, how differently we work. I switch to national keyboard layout only when I have to write an email/chat message with my compatriots or maybe a document that needs those national characters. Otherwise, I just use US layout for everything. Like 99% of time I'm on US layout. It makes much more sense when programming (not just brackets, but also quotes, colons/semicolons, slashes, backticks, etc.), which is my primary use of computers.
I'm Czech and use the UCW layout which works exactly like US English, but allows me to enter Czech letters with AltGr. It's so much better than the traditional Czech layout.
What nonsense. Every single modern operating system has bindings that are usable with all keyboard layouts. Having such a default is not only possible, it's the status quo everywhere, except in software designed during the era of the moon landings.
You're not wrong about the poor default keybindings. When the effort to fix it on your part is probably less than all the time you've spent complaining about it, chances are you really are not part of the intended user base.
So something completely unattainable by a small dev team on a startup budget. Great! These are the standards by which we prevent any good things from being created.
You don't have to "develop" anything, you just have to follow the binding conventions for the platform(s). In practice, this simply means using Ctrl/Cmd+[LETTER/NUMBER] for everything, and the problem is solved.
> C-[, which cannot be pressed e.g. on QWERTZ layouts because the [ character requires AltGr.
So the user just presses Ctrl-AltGr-[, what's the problem? And changing keyboard layouts or keybinds, isn't something that someone using vim should have a lot of trouble with anyway.
> It's bad enough that a text editor that ignores the past few decades of UX research is still in widespread use,
Maybe that's because a lot of people using it decided that the "decades of UX research" produced precious little of worth. That's because alot of the "research" done in areas that are, by their nature, heavily opinionated, produces, what a surprise, mostly opinions.
And when we take a giant pile of opinions, and pile them all on top of one another, well...
...that's how we ended up in a world where, somehow, people now actually have to wait for an application to open, like they did in the early 90s, on machines that are orders of magnitude more powerful. Where webpages load 20MiB of giant hero images, useless framework code and spyware, to display 4 lines of text. Where applications get more "modern" and "streamlined" by somehow lowering information density, losing functionality and getting less self-explanatory.
As a long-time Emacs user who also occasionally uses Vi and very rarely Vim... but also knows a bunch of people who are in the later camp: nobody in that camp buys / uses "non-US" keyboards. Even on "US" keyboards, the amount of remapping a typical user does to their keys is significant.
In other words: you are complaining about a problem that doesn't exist. Users who want Vim / Emacs experience don't want keyboards that don't work well with their editor of choice. They will not be in a situation where they have to adjust their editor to the keyboard layout. If there's a mismatch, then the keyboard will be adjusted, not the editor.
Now, I'm not sure how Vi(m) users handle other written languages, but since I every now and then have to write in two non-Latin languages, in Emacs, I keep buffers for those languages with input method set accordingly. However, say, I need to write in Cyrillic, I still use the en_US modified QUERTY layout that I use for everything else + phonetic transliteration into Cyrillic. This is both easier for touch-typing, as I don't have to memorize several different layouts, and this method makes more letters easily available than there would've been on a physical keyboard.
So... no. don't stop incorporating Emacs / Vi key usage into new products. It works great.
Also:
> ignores the past few decades of UX research
Except there was none. Unless you mean it in the same way how for some reason people who make HTML pages call themselves "UX developers". What happened is that big companies wanted to sell products that looked "impressive", but offered worse user experience overall. This is how MSVS, Eclipse, and similar happened. There's literally no UX research on how people deal with typing text into computers. Whereas in practice, what I see is that people who use "visual" tools just suck at writing text. And, myself, having worked with both "visual" editors and Emacs / Vi, I would literally refuse a job position if I had to work with VSCode / IntelliJ products.
A paradigm is something more high-level than a very specific keybind conflict. Mature vim mode addons for browsers are layout-insensitive. How do you think j/k work on non-Latin (e.g. any Cyrillic) layouts? And they do.
I am a Spaniard which I learnt to use the ES layout as the 100% of the Spaniards and then I realized it sucked a lot for programming symbols. If you use Linux/BSD for programmaing and don't run something
like "setxkbmap us -option ctrl:swapcaps -option compose:rwin" (or menu instead or rwin in order to use menu+'+a to type á, you are losing your time. Stuff like "recogerá" can be easily written with menu+' made solely with the right hand as a pinch and 'a' with the left key. The only issue is 'ñ' which is a bit cumbersome to type, but there aren't many words with 'ñ' usable in the same context.
The other approach I've seen is having some sort of weird key combination (like "hitting both shift keys at once") to switch back and forth between two layouts. I saw somebody using it for QWERTY vs. DVORAK but it seems like it'd be viable for two language layouts too.
Any pointers to research? As an emacser I consider most of vim very very :repeat efficient. I'm very much still open to new ergonomic ideas though, I just never see any.
Vim style keybindings and navigation is massively overhyped as is vim itself.
Cue endless debates about how Vim is the best ever ...... I'm sick and tired of everyone telling me that their neovim setup with a tiling window manager with million customized rc files is somehow better than vscode with a mouse (which mind you still has plenty of keyboard shortcuts) with sane windows. /rant
There's a class of fanboys who will be telling you about that because they're Really Excited that they got it Just How They Wanted It.
Most of us think "we like it, some people don't, great if it's an option, probably shouldn't be the only option anywhere else."
The one-upmanship (over VSCode in your case but all editor wars get a dishonourable mention) is bullshit but, like, random strangers on the internet tell people with crippling depression "hey, you should do <thing>, it fixed -my- depression" so I think you have to just accept that "when something works really well for a human, sometimes they get overexcited and start trying to turn the something into a silver bullet that it isn't" is something that will always happen.
Note: The people doing the arseholish one-upmanship are not in any way forgiven by this, and the "everyone telling you" that you describe would aggravate me as well, but as with the Rust Evangelism Strike Force, you just have to nod and smile (and sometimes point and laugh) at the zealots and look at the technology for yourself.
Note 2: I use the original 1970 Bill Joy vi. Other people I know use VSCode. 'better' is relative, and what works best for any given person/project varies wildly - everything before this note is about the dynamics of people discussing such choices.
> Nyxt is a browser with deeply integrated AI and semantic document tools that work as a second brain to help you process and understand more, more quickly.
It'd be nice if they elaborated on what this “integrated A.I.” thing actually is in that or another FAQ entry.
Not really as customizable though, ublock has useful features like build your own filter and pick/create to block annoying webpage widgets. I do wonder if the python based aspects of qutebrowser might give a large surface to fork it and make this type of "hacker's browser" out of it though.
Did a quick run with it and turned on vi mode from the settings menu.
The first thing I found awkward about it is that prompt fields are always initiated in normal mode. So if you want to execute a command with : or interact with an element using f, you have to manually activate insert mode first before being able to enter text into the prompt.
I'm sure there's a way to change this since the entire thing is in Lisp, but it sure is an odd default.
if it's a fresh field, I think I might turn out to prefer them always initialised the same way for the sake of my muscle memory.
Now, that may not be true of -me- in practice, but it's definitely possible for whoever did implement that part to genuinely prefer it that way.
Of course, if the implementer wasn't a vi user, who fucking knows, vi is kinda baroque as fuck if you run face first into it without preparation so "the person who picked that default was trying to do vi users a solid but had to guess at some bits" is totally viable too.
I've always thought of developing a Hacker's browser. One where there are no restrictions of what it can do. For example, you can't write a chrome extension to spoof the Referrer header on requests. The Chrome browser is more locked down than you think.
There is also Chromium which you can build and patch if you really need low level changes to the browser not achievable from JS, but nothing immediately comes to mind to necessitate that.
It doesn't look easy to change and even then, there is some doubt whether it works with newer Chrome versions. Anyways, the Chrome developers are purposely making hard if not impossible to change the Referrer and other headers. Part of the blame is to comply with standards but there should be some flag to turn off that behaviour.
You could probably add this to Nyxt in a solid hour or two of configuration hacking.
The "configuration" is just more code that gets compiled in on loading. It's a complete first class citizen unlike extensions for most software which is sandboxed in a separate language and can only see certain APIs.
In Nyxt, StumpWM, Emacs, and other Lisp software you can literally put bugfixes in your config, redefine existing functions, and generally do whatever the hell you want.
That is good! I have been creating some add ons for firefox and what i dislike the most is that i can't just easily modify the UI of the browser itself.
I hate that i can't change stuff even if i am only creating add-ons for myself...
This probably wouldn't be possible due to browser sandboxing.
You could however, use a tool like External Application Button [0] in order to send the URL of the page to a script/program, which in turn can make the body of the page parsable by downloading the URL it gets, automating some action on it. I use it pretty often to automate downloads with yt-dlp or opening a picture directly in GIMP from the browser, but since you're invoking a bash/python/whatever script, the possibilities are basically endless.
> You could however, use a tool like External Application Button [0] in order to send the URL of the page to a script/program, which in turn can make the body of the page parsable by downloading the URL it gets, automating some action on it.
This works less well than it used to now that CMSs and blogs are now SPAs that render no text without javascript being enabled.
Yes, that is a shame, but that can be worked around by sending it to something like PhantomJS, headless Chromium, or any other scriptable browser that will actually run the JS on the page and render it in the background. Very heavy as you're basically running a full browser in the background, but totally doable.
And then call the function like C-space buf-text-to-pipe-cmd and specify the commands to pipe to. Output will appear in a new buffer that can be further used as the source for piping.
DOM handling would be a tad more laborous, but you can pick DOM elements from output of nyxt:document-model with CSS selectors using clss:select.
Since we are on the topic of hackers browsers, does anyone know if Firefox can be made to split pane (both for seeing the same page side by side and also doing it for two different pages)? Having done that with file browsers and IDEs, I wonder how come it wasn't a main feature? Nobody needed to compare pages side by side?
Thanks - this is useful indeed but it is sort of a hobbled view - I don't have access to the extensions I have installed in the side view. E.g. the main view shows the page in dark mode via dark reader but the side view doesn't have access to the extension so it has white background which is very jarring (better than nothing though). I wish they allowed a full-on split - almost like having two browser windows (with a common menu/bookmarks bar that acts upon the "active" pane).
For those wondering whether this is a new browser engine, the FAQ says:
"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 (experimental (Blink))."
tl;dr; no. It's just another browser UI, albeit a very different one.
I just want a WebKit-based browser where everything can be controlled by a prominent LLM prompt box. No more clicking through constantly changing menus or trying to remember rarely-used vim shortcuts, just tell it what you want to do. Bonus if it supports continuous voice input.
Use Vivaldi then. Just press F2 and you can type any command in the browser. You can also use it to search your history and bookmarks and do basic arithmetic.
You can also combine commands into so called command chains.
Does it do regex search? I so often need to do a foo|bar in a page.
Back in the days, before Firefox switched to the Google Chrome model of extensions, there used to be a really nice advanced search addon. Nicely integrated into the UI.
Looking forward to the MacOs version! I'm currently using Vivaldi and it frustrates me on a daily basis how unfeatureful, unextendable and buggy it is.
My ideal browser would be
- chromium-based [optional] - willing to forgo this if (1) it has a lot of features built-in, or (2) it is extendable in a language like `lua`.
- tree view of tabs
- vim keybindings
- splits, moving windows to new tabs and back
- file-based configuration
- [optional] history sync (i'm fine with using my own cloud provider like icloud/dropbox)
- renaming tabs and windows
- remote control server (so i can interact with it from hammerspoon/alfred, eg: open the tab that is a local file with .pdf extension and refresh it (for asciidoctor/latex development))
Really like the idea of a tree-based browsing history. It is more in tune with the graph-traversal nature of browsing the internet, and could be extremely useful for people who conducts extensive reading or research on the internet. Honestly feel like this should be an option for more web browsers as an alternative to the 1D, flat structure of tabs.
I had a period where I used uzbl(it died simply because of the constant problems with webkit-gtk) and I tried to use qutebrowser after vimperator became unusable, but from a feature perspective this looks fantastic.
They added support for things such as keepassxc. It has nice defaults.
But they really went ALL IN with the lisp here. For some people that's a plus, but it seems a lot more unapproachable than emacs configuration to me.
I think that will ultimately hurt its adoption and unfortunately these things thrive on the size of the active community.
EDIT: part of that is also lack of practical documentation. They have documented a lot about nyxt, but there is very little practical documentation
I’ve always assumed the major browsers had all sorts of security stuff going on behind the scenes, and using a small alternative like this (or suckless surf) was just asking for trouble. But, I don’t have any real knowledge about security stuff.
How misinformed is my take? Are these kinds of browsers OK? I’d like something light, if possible.
Lightweight web browsers don't have as large of an attack surface, particularly if they eschew JS, cookies, etc or you disable them. Nyxt is alpha software, so YMMV until it's more feature complete, and independently audited to correctly implement WebKit and WebExtensions. Run Tor Browser without JS in a VM for security+privacy.
I'm a qutebrowser user and I really have been rolling it around in my head to check this out and switch to it. My main issue with it is that I develop userscripts for qutebrowser (not greasemonkey scripts, qutebrowsers version of extensions) and the lisp only thing in nyxt bugs me. I like lisp, but I'm stronger in other scripting languages. The benefit is of course i would not be limited at all to functionality because any part of nyxt can be modified.
It seems like an absolutely fantastic project and I shall see if I want to invest in the effort it takes to move.
I personally use Orion Browser (macOS) and Homerow (macOS) and it gets me in a similar situation, without the buffer stuff, and with a more traditional setup. I can recommend that if you're looking for an alternative.
There was a programming language taxonomy thread posted a few weeks ago and I seriously think if you want to ‘git gud’ you should dabble in all of the families.
Awesome project! From the website I wasn't quite able to tell where exactly and how AI comes into play.
I think apart from fuzzy searching headings a semantic search functionality for the whole text would be a really nice default feature. I implemented frontend-only semantic search with transformers.js here: geo.rocks/semanticfinder. The implementation is very straightforward and it would be easy to integrate in the browser, maybe as a plugin or similar.
Cool stuff. We all need to escape the oligopoly of Chrome and Safari. Consider making a build for Android and consider inserting a JS polyfill layer that could stub any weird API with an extension, without rebuilding the browser (side effect: it's an ultimate adblock solution).
Why is the only Mac option a non-default, local repo-based Macports installation? What's wrong with a binary or a port that is actually listed in Macports? Isn't that the whole point of Macports?
WebKit and Webengine. And the versions of these renderers that this and similar projects like qutebrowser use are just too full of bugs to be a main browser. That’s why I don’t use them, although I would really love to.
Still using big tech c++ diareha of webkit(apple) or blink(google).
Please, do acknowledge this is nearly pointless.
Stop coding that please: first thing first, namely code a web engine in a plain and simple language (like C89+ with bits of c99/c11) and not using that any grotesque and absurd language syntax like c++... even though the core of the issue is the web itself.
Keyboard-driven UI on Android? Well, for the brave and true hackers (if you don't connect a keyboard to your android device which you can ... but why having an android device then?)
What about Windows that makes it unsuitable? In fact, the majority of "hacking" and the proliferation of "hacking culture" over the history has been done on Windows - not any flavor of UNIX like many would have you believe.
You wish. Proper hacking has been done under Unixen and before, MIT with ITS and Lisp.
You don't know anything about hacker culture. The cracking one, maybe. Unix and Lisp users run circles on Windows' crappy warez culture any day.
Can you clarify what you mean? It can certainly be run on hardware that you call a server, just would depend on if you're running a graphical environment, it's not able to run in a terminal emulator afaik.
If you want a remote browser capable of running on a server (with the client, browser UI in a regular web page) check out BrowserBox: https://github.com/dosyago/BrowserBoxPro
I expect you can run it in headless mode (new --headless switch), start a Swank server (the backend of Slime, the backend of the most used CL "language server"), and connect to the Lisp process from home, through a SSH tunnel. And control the browser from the Lisp REPL, or a Lisp script, like we would with any running Common Lisp program.
It's not what I expected from their webpage, I think their Github explains it better -
Nyxt [nýkst] is a keyboard-driven web browser designed for power users. Inspired by Emacs and Vim, it has familiar keybindings (Emacs, vi, CUA), and is infinitely extensible in Lisp.
It's not for the OSINT community, is how I'd read it.
"Hacker" as a term has and seems to continue to hold a dual meaning--the penetration testing, blackhat / whitehat, OSINT meaning, OR the creative software engineer, clever maker, resource-constrained artful solver-of-problems.
That Nyxt is targeted at "hackers" therefore requires some disambiguation. It is not primarily for the former camp, and is largely for the latter, it appears.
I've never thought about it until I saw this! Now I'm really irked about there not being a solid, mature browser based on extensibility. Where the base is basically an address bar and history awareness (i.e. back/forward) and even bookmarks is a module, so that you don't even need an integrated solution but can instead rely on e.g. Raindrop.io as your bookmarks manager. Tab management another one, so for example you could have _only_ a powerful vertical tabs mode if that's all you need.
You know what, it feels like this should have happened 20 years ago and it would be as popular as Vim or Emacs now, but somehow never actually did. It would be the ultimate response to Chrome, Edge, even Firefox feature creep, forcing its developer to commit fully to web renderer excellence (speed, RAM, web standards) and maybe some optional official modules if you want them.