1. 3

    What’s the engine?

    1. 5

      I was curious as well from the README.org in git: “Next supports GNU/Linux, macOS, and Guix with engine support for WebKit and WebEngine/Blink.”

      1. 8

        I would be tempted to try this, but I really don’t want to contribute to making the WebKit monoculture even worse.

        1. 10

          Look I am very vocal about browser monoculture and am a volunteer for Mozilla but I think you should reconsider here. Next browser has a lot going for it and the engine is not where its interesting parts are. The fact that it supports more than one engine makes it easier in the future to port to a non webkit-derived engine. A web with more user agents is always good, specially new browsers like this which are trying something different UX wise.

          Also, remember that Mozilla doesn’t make it easy for people to build on top of their engine. It is very hard to start a browser today and not go in the webkit/blink path. For example, I wanted a Web View for Racket because I couldn’t find one, I ended up with a mvp of a webkit wrapper. I’d prefer to go with Gecko but couldn’t find how. It is not as if the developer of Next browser is actively supporting a browser monoculture, they are doing what they can and shipping a nice product with the engines that are available today. I think that is great.

          1. 2

            Qutebrowser supports more than one engine, and is arguably much more mature than this project.

            1. 6

              It is not a competition. You can support Qutebrowser, or this one, or both. The more the merrier. If instead of supporting small independent vendors, we keep pointing fingers shouting $ALTERNATIVE is better then we just end with less browsers.

              I like Qutebrowser too, and Dillo. We need to support a diverse ecosystem, even if in terms of engines things are looking rather grim.

              1. 5

                then we just end with less browsers

                Except we don’t actually get “more browsers” in a meaningful way; we just have the same browser over and over again with different trimmings.

                1. 2

                  Yes you do. Most of the differences are happening outside the engine with different browsers packing different UX, ad-blocking and other features.

                  I too want more engines but we don’t have more engines to embed. At the moment all the embedable engines are webkit/blink derived. MacOS WKWebView, Windows 10 is getting blink, Linux is mostly around WebKitGTK and QtWebEngine.

                  Yes, I agree we need more web engines but the web got so complicated that no one can build them from scratch anymore. Unless devs start contributing massively to Mozilla to make Gecko embedable (checkout GeckoView which is an embedable Gecko but as far as the repo goes, there are only samples for Android), we won’t have alternatives.

                2. 3

                  This is far from a ‘diverse’ ecosystem. All of these browsers use webengine or webkit.

                  1. 1

                    Diversity is not an absolute, it is a spectrum. It is more diverse to have more user agents even if they use similar engines but are exploring different approaches to the rest of the app than it is to have just three browsers, two of which are webkit/blink. Opera, Brave, are all blink based and some of their innovations are being adopted by other browsers. I’m sure everyone would like more engines but we don’t have them.

                    Mozilla should throw more weight into making GeckoView work well on the Desktop so that people could build browsers with it, but even without that, more user agents is better.

                3. 2

                  Indeed, and as a former Qutebrowser user myself I can say that it inspired me for many features of Next. Note that Next takes a radically different approach though: it exposes 100% of its (Lisp) code base to the user, open for configuration. The goal is to have something extremely extensible / hackable.

                  The minibuffer UX of Next is mostly inspired by Emacs Helm / Ivy and that differs quite a lot from Qutebrowser approach.

                4. 2

                  Isn’t servo easier to embed? Why not go with that?

                  1. 3

                    Servo is very incomplete.

                5. 2

                  What do you mean? We support 2 engines (and possibly more in the future), there is no monoculture here :p

                  1. 8

                    Like the old joke goes: “We play both kinds of music here: country and western.”

                    1. 3

                      I don’t get the joke, there are two browser engines, and the chrome here is agnostic of the engine.

                      1. 8

                        They’re both just different variants of one Google-backed codebase; it’s still a Google monoculture.

                        1. 4

                          Are Google contributions being backported into WebKit? Otherwise, Google hasn’t exerted influence over WebKit since they forked off six years ago, right?

                          1. 2

                            I’d say it’s the other way around: Google forked WebKit. WebKitGTK is developed independently. If I understand it right, WebKit has a long history (KHTML) that predates the work of Google.

                          2. 2

                            The “chrome”? Did you mean the “core”?

                            1. 9

                              Browser chrome usually means browser ui

                    2. 2

                      Indeed. For now the PyQtWebengine port needs a bit of finishing but we are working on it. Soon both renderers will be equally usable!