1. 46
  1.  

  2. 4

    Interesting, looks a lot like qutebrowser, but with emacs bindings.

    1. 6

      That’s true. Note that Next also has a vim mode. A major difference though is that it isn’t tied to a particular renderer engine (Next had a WebKit port first), since the logic is in a separate Lisp core. Which allows one to inspect, develop and change it at runtime.

      1. 4

        A major difference though is that it isn’t tied to a particular renderer engine (Next had a WebKit port first)

        qutebrowser also originally started with QtWebKit and you can still use it with that (instead of the Chromium-based QtWebEngine) FWIW.

    2. 2

      Looks cool but I’m too risk adverse to invest in something like this.

      1. 1

        Risk adverse?

        1. 2

          This project could die at any moment. I try to avoid filling my head with stuff I won’t use in the future.

          1. 1
            1. 4

              I more meant “what about this is so risky you shan’t use it?”, it didn’t occur to me that verbal cues are lost through text like that, I’m tired.

          2. 0

            I can understand, but note that IMO using Vimium, Tridactyl and friends is more risky. Similar projects that were tied to a single platform all died in the past (Vimperator, Conkeror,…). Next’s core is an independent Lisp program (and Lisp is, by the way, known for its stability).

            1. 5

              I’m not sure that’s fair. Qutebrowser has a nice list of similar projects - http://qutebrowser.org/#_inactive - and you can see that the graveyard is equally littered with “independent programs” and browser extensions : )

              1. 2

                Vimium exists for a very long time and is very unlikely to die. Port also exists on Firefox. I use both ATM and didn’t have any problems whatsoever.

                1. 1

                  I don’t use those either. I tried Qutebrowser briefly but, again, too high risk. Browsers at this point are a closed platform

              2. 2

                @vindarel: I was comparing Next browser, qutebrowser, and surf over the weekend. If one wanted to capture network traffic to, say, write a WARC file for archiving, is this possible in Next? Where would I start looking? Seems like this might be doable in an ordinary browser extension via webRequest API, but I find the idea of a programmable browser more interesting.

                1. 3

                  It is possible (although it depends on how precise you want to be, we don’t make full use of what WebKit or Webengine offer yet). See remote.lisp and its D-Bus endpoints like buffer-did-finish-navigation: https://github.com/atlas-engineer/next/blob/master/source/remote.lisp#L519. You could add your processing after resource-query-default has finished, typically with an after method (proper hooks are also in the roadmap).

                2. 1

                  What is the benefit over Vimium plugin (and friends?)

                  Using different rendering engines is not exactly feature I can’t live with, especially as I can easily install all relevant browsers.

                  1. 8

                    Ah, there are many, thanks for asking :)

                    • we wanted to support different rendering engines for users to choose a more secure one (the Blink renderer). Not relying on a single one also makes Next future-proof. Vimperator, Conkeror and friends all died because they were tied to a particular platform.
                    • Next supports different key schemes: Emacs, Vim, specific ones.
                    • you can tweak Next/develop extensions has it runs. Tweaking Vimium and all is cumbersome, and limited.
                    • you are not limited by a browser’s api. You can develop a feature that calls an external program and writes the filesystem easily.
                    • with Next you can do more than with Vimium and friends.
                    1. 1

                      OK, thx for the info.

                      Why is there no Windows binary ? I could create chocolatey package if you make one.

                      1. 2

                        None of us use Windows, and we were busy finishing up the Blink port and must-have features for 1.3. Yet, we provide an experimental cross-platform pyinstaller archive: https://github.com/atlas-engineer/next/issues/275 We would like very much feedback on it specially on Windows ! I am unsure how to setup D-Bus for Windows though. Thanks for any hints.

                        1. 1

                          There is no such thing as D-Bus for windows. Windows has different IPC/RPC mechanisms.

                          1. 2

                            I read that though:

                            The Windows port is knowing to work on Windows XP, Windows Vista and Windows 7

                            https://www.freedesktop.org/wiki/Software/dbus/

                            1. 2

                              I wouldn’t be very optimistic. Those systems are all dead for a very long time.

                              1. 1

                                damn :S thank you.

                  2. 1

                    how is this different than puppeteer?

                    1. 2

                      Next could be also a headless driver to two rendering engines (and it is already a bit). But Next is more a usual web browser that has a UI, that humans manipulate with keyboard shortcuts, that aims at offering features to power users to surf the web (and not only), and that is easily hackable. I think that offering puppeteer-like capabilities to a real web browser can give great things.

                      (also, no need to restart the browser to test one’s changes and that’s a real drug)

                    2. 1

                      Very cool! Definitely going to play with this. Extra points for Python extensability and the fact that you cribbed the old school NeXT logo design :)

                      Any chance of a Homebrew formula? I know you folks are busy but I can’t get anything from MacPorts to like, work, ever (I know folks have had similar experiences with brew, YMMV)

                      A homebrew binary download (Cask) is already available! Just brew cask install next and away you go :)

                      1. 1

                        Why is this tagged with python?

                        1. 5

                          I tagged it with python because we ship a PyQt platform port in this new release. You could have fun sending commands to the browser with Python (we have a simple testclient.py that shows some commands). You can create new buffers (tabs) and windows, ask for page information, or send some JS and get the result.

                          1. 2

                            Thats very nice. Its not easy to do this on “regular” browser, especially as it doesn’t have normal UI as other programs and hence can’t be easily automated with tools such as xdotool or AutoHotkey.

                            Makes exploits easier tho… there should be an option to prevent this somehow that isn’t changable by automation. Otherwise, what is stopping me to get fantastic info about your doings on the web in the background, constantly. Now you would have to constantly screenshot for this which is pretty visible. AFAIK, even web drivers do not allow for connecting to running instances that they didn’t start.