Live data from Hacker News

Nyxt: The Hacker's Browser

nyxt.atlas.engineer

91–100 of 262 posts

Re: Nyxt: The Hacker's Browser

#91
post #23

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.

What other restrictions are you referring to? This SO post seems to cover how to change headers (including Referrer) in Chrome API: https://stackoverflow.com/q/30999159/11173996

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.

Re: Nyxt: The Hacker's Browser

#92
post #17

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'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!

0: https://github.com/dosyago/BrowserBox

1: https://github.com/dosyago/BrowserBoxPro

2: https://news.ycombinator.com/item?id=35996647

Re: Nyxt: The Hacker's Browser

#93
post #71

No support for Windows, really? That's unfortunate.

what kind of "hacker" use windows as a main OS though? windows is only for gaming and testing the software you ship

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.

Don't gatekeep.

Re: Nyxt: The Hacker's Browser

#94

Earlier quoted context omitted.

what kind of "hacker" use windows as a main OS though? windows is only for gaming and testing the software you ship

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. Don't gatekeep.

Windows is good for getting hacked, unix is good for hacking

Re: Nyxt: The Hacker's Browser

#95
post #86

Earlier quoted context omitted.

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.

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

Re: Nyxt: The Hacker's Browser

#96
post #79
post #76

Earlier quoted context omitted.

You're not going to get a default that suits everyone. Stop being so sensationalist and just rebind them.

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.

So use a normal browser. Don't use one self-described as being for hackers.

Re: Nyxt: The Hacker's Browser

#97
post #70

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…

True, Hackers hate changing settings.

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.

Re: Nyxt: The Hacker's Browser

#98
post #77
post #72

Earlier quoted context omitted.

Hardly sounds like either a bug or a showstopper when you can rebind any command

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 t…

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.

Re: Nyxt: The Hacker's Browser

#99

Earlier quoted context omitted.

>When a product is unusable without changing configuration, it absolutely is a bug I don't think that adage applies when the target user is the average VIM user

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 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

Re: Nyxt: The Hacker's Browser

#100
post #84

Earlier quoted context omitted.

>Every single modern operating system 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.

Tell that to my pinkies. Reaching for Ctrl/Cmd+[LETTER/NUMBER] when navigating entirely by keyboard is a really bad idea.
Post reply on HN