Show HN: Next Browser native on Linux

198 points by jmercouris ↗ HN
Thanks to a new design Next is now available for Linux!: https://next.atlas.engineer/article/technical-design.org

What is Next? Next is a Lisp based productivity focused browser. You can read more about that here: https://next.atlas.engineer/article/the-next-thesis.org

You can download a binary from here: https://next.atlas.engineer/download

You can view our GitHub here: https://github.com/atlas-engineer/next

Thanks for your time, I'm very interested in the HN Community feedback, thanks!

116 comments

[ 2.1 ms ] story [ 175 ms ] thread
Demo videos: https://next.atlas.engineer/#features

I don't get the choice of Lisp. I don't mind it, I use Emacs, but a more popular language can have more complete platform bindings:

> Sadly, the GTK bindings are not in a shape that is enough to fulfill our needs. We've tried to get Next running with CL-CFFI-GTK on GNU/Linux for many months, to no avail.

Well, the Lisp part is for the reprogrammability of it all, the inspectability. You can on-the-fly edit a compiled version of Next, which is pretty cool I think!
Isn't there some popular language with the same capabilities? Is it a Lisp speciality?
It is a Lisp specialty, yes. Lisp has other facilities as well, such as meta-programmability, you can define new syntax, make macros etc, it is a very powerful language!
Nowadays it's usually called 'hot reload' and everybody hype about how cool is that in React Native and Flutter.
Well, those are GUI toolkits. A lisp doesn't compete with them. Any GUI that you build with a lisp still needs to support that sort of thing.

Also, when people praise a feature that RN or Flutter have, they are really saying that it's nice that a tool that's practical today has the feature, not that it's never been done before. That something has been done before isn't all that interesting.

If you don't realize this, you become the person running around unhelpfully reminding everyone that smalltalk or a lisp machine had a feature years ago, yet neither offers a practical way to build mobile apps today unlike RN/Flutter.

It’s is pretty cool, the alternative being compiling. I know there was a way to hot reload swift, when I tried back in like 2016. But it required strange swizzling, and still had a compilation lag (not that Babel doesn’t, but it’s usually faster)
Lisp appears to be the whole point of the effort, so Lisp problems are just to be endured and, they hope, overcome.

Not having a flagship modern application has kept Lisp on the margins. Emacs no longer suffices to maintain the language's edge, not least because Emacs Lisp is not a modern dialect. It remains to be seen what improvements to the language or its ecosystem will be needed to support this development, but there is no substitute for trying.

well said! another hope is indeed to increase the popularity of Lisp by providing a "killer" application. Next is still in its infancy, but we have had barely any time at all, and it is on its 5th rewrite, and already it is quite powerful!
I remember installing this browser after one of the first releases, but lost track of it after a little while. Nice to see all the growth its had, I'll have to reinstall it!
Yes, please give it a try :D

I think we are now on our 5th rewrite. It is still very alpha, but from here on out, now that we have settled on an architecture, it should mature in stability and in feature set quite nicely!

The real hard part was getting off the ground!

It looks like a direct competitor to Qutebrowser which uses PyQt5 + QtWebEngine: https://qutebrowser.org/

Interesting to see that Next Browser integrates Lisp with WebKitGTK+.

also qutebrowser is vim-like keybinding, and nextbrowser is emacs-like keybinding
Which only encourages the idea that Next is Qute's direct competitor.
this is true, but one of the main co-authors is a VI/EVIL user, so we are working on VI keybindings for the next release. Still trying to work out how to best integrate them into the system, that's all :)
Well, we are not competitors, we target different markets. Next is infinitely extensible, Qutebrowser is not. Also Qutebrowser is married to QT, Next is not. If we wanted to, we could in about 1000 lines of code make a QT port for Next that uses Blink. Take a look at the platform ports https://github.com/atlas-engineer/next/tree/master/ports and you will see that they are quite trivial to implement :)
It seems pretty interesting, especially the mouseless part.

I tried [Vimperator](http://vimperator.org/) on Firefox for a while, but it seems the web was really hard to use without a mouse.

I might give it a try again

Sometimes, CTRL-F the text of the link highlights it, so pressing ESC and then enter would select the link.

Only allows one to not move a mouse sometimes.

When searching using / you don't need the escape part. There's also ' which only searches links.
Man, this is a handy little reference; I hadn't known about these! Cheers!
I’m really excited to see this! I’ve got it compiling right now. Can’t wait to give it a spin.
I hope you enjoy it :) thank you for your interest!
No adblock is a show stopper for me, but they have a campaign on Indie Go Go with adblocking as one of the goals

https://github.com/atlas-engineer/next/issues/32

https://www.indiegogo.com/projects/next-browser-nix-support#...

I’ve been going pretty strong with a host based blocker. I mention this in case you really want to use Next and are willing to try a different blocking approach :)

I know it’s not as comprehensive as extension based blocking, but it seems solid.

We've been leaning towards using Webkit's integrated content blocking rules, but we weren't sure how effective it would be, thanks for the feedback!
A lot of the focus seems to be on making the browser easily extendable which is great, but can extensions interact with/modify the contents of web pages rather than the browser itself? I am not seeing it in a quick browse through the docs, and that is kind of the main point of most browser extensions.
to answer your question, yes
Great, thanks. My Lisp skills are very rusty but I think I'll give this a shot.
(comment deleted)
I like the idea but it doesn't go anywhere near far enough.

I feel like the web has become that "City of Destruction" that is talked about in "Pilgrim's Progress"; something like 95% of the bytes transferred are just junk.

I am not at all interested in "seeing the content the way the created intended it", I really would rather decompose it into a semantic graph and then put it together to show me what is relevant.

That means no Javascript. If I have to have a malware player so I can use the junkware of the day I'll use Chrome.

There are basically two ways to do that. Decompose final page, that is composed usually by internal Javascript these days. Or decompose the page structure, which is usually a bunch of API calls, requests, and some data transformation. The former is simpler, the latter is good potential use case for programmable browsers like Next.
Like Reader Mode ?
That just seems to add a lot of fashionable whitespace so that I can only use 50% of the pixels on the screen that I paid for.

Reader Mode just seems like the button on a tracfone that does nothing but burn up half a minute by booting up a useless web browser.

Maybe next can be a good pivot to do just that. It seems the author is willing to try other ways to use the web.
For those wondering about the Pilgrims Progress reference, this is probably what OP intends:

" HELP. Then said he, Give me thy hand: so he gave him his hand, and he drew him out, and set him upon sound ground, and bid him go on his way. [Ps. 40:2]

{33} Then I stepped to him that plucked him out, and said, Sir, wherefore, since over this place is the way from the City of Destruction to yonder gate, is it that this plat is not mended, that poor travellers might go thither with more security? And he said unto me, This miry slough is such a place as cannot be mended; it is the descent whither the scum and filth that attends conviction for sin doth continually run, and therefore it is called the Slough of Despond; for still, as the sinner is awakened about his lost condition, there ariseth in his soul many fears, and doubts, and discouraging apprehensions, which all of them get together, and settle in this place. And this is the reason of the badness of this ground."

I feel like gopher, the once alternative to the World Wide Web, before it became overwhelmingly less used, was really technologically superior. Its simplicity and structure would have been difficult to coerce into the ugly monolith that web has become (in my opinion), and would have promoted proper modularity, which is how I would generalize "semantic graph" you mentioned.
Funny, the number of Gopher servers has started to grow again lately...
I have been putting some real thought into this as an idea for client-side scraping and re-presentation [0]. I have come to the conclusion we just need a community maintained set of code that turns popular websites into APIs that people can program against. If you turn that into an easier-to-read-sans-BS page by querying the API, so be it. It of course needs to be deployed as part of the app, there are legal issues with hosting the API externally. I have started some work around this concept for my own personal use on pages that give me too much guff.

0 - https://github.com/cretz/software-ideas/issues/82

Being junk to you doesn't make it junk to everyone else. The only content you could re-present in 'your' way would be static contents, and only if they fit a specific design. This leaves out a significant portion of things that require dynamic capabilities. Something as simple as openstreetmaps would not work in this somehow ideal world.
i'll just download OSM and view it locally.

The Boston Globe ran an expose a few years back that came to the conclusion that the cost of mobile data to download ads is orders of magnitude greater than what the web sites make.

If verizon kicked back 2% of revenue to web sites then they would make more money than they do from ads now, and verizon would get the warm fuzzy love that they wish they could have gotten from Go90, Oath, etc. But no: their business model is "buy web sites crammed with porn, remove the porn, and hope some users are still around when they are done".

Except osm is used with specific integrations, like graphing locations, showing city layouts. It's incredibly naieve to believe you'll just replace the very real Js use cases without knowing how it works
Hi there, bit of a lisp fanatic so excited to see this. Just some questions: I'm not very knowledgeable about browser architecture, and my search foo is failing at a first try, could you provide a couple of links on what you mean by "controller"? My second question is probably dependent on the first, but: are you worried that using xml-rpc is going to be a bottleneck? last question: I'm a little worried about the note on the installation page to modify the kernel for a userland app to change root, could you reassure me that I'm just an ignorant fool that simply doesn't understand whats going on here? these might seem adversarial, but I promise, I'm actually really excited for this, I just want to understand whats happening. I'm grabbing a copy of the source and will definitely be sifting through it over the holidays, good luck!
controller? in which context?

xml-rpc will not be a bottle neck. There are very few commands being passed back and forth between the Lisp core and the platform port. Basically only on keypresses, or if the Lisp core itself initiates it.

With regard to changing root, I have no idea what it means myself either, as I am not a Linux user, but from what I understand, it is necessary to get any Guix pack to work, I don't think it is a huge security risk. Then again, I am also not a Linux user, so hopefully someone more knowledgeable than me will chime in.

Thanks for the well wishes!

thank you for taking the time to reply, much appreciated
Those are all good questions!

- "Controller" is just for the sake if this article, to distinguish the part that this project (or any other power-user browser for that matter) is about. It's everything that it not the GUI or the renderer.

- XML-RPC: we were asking ourselves the same question, and the answer could only come out of real-world use. The happy result: no, it's not gonna be a bottlenext, it's very smooth! In the end, XML-RPC is only a medium to send "GUI"-related queries, it's never a tight loop or anything.

- The user namespace: this is only for the Guix pack. It allows the executable to do some filesystem name translations so that it can find it's own executables and libraries. If you are worried this would be an issue, you can simply extract the archive to `/`, it will only use two folders: `/bin` and `/gnu/store`.

thank you for taking the time to reply, all of this makes sense.
Congratulations! It won’t be ready for primetime until there’s a good adblocker — but now that it runs on Linux, folks like me can work on an adblocker for it.

I’m really excited for you & for your browser. I was a contributor to your Indiegogo campaign & was really bummed to see it fall short of the mark (although no doubt nowhere near as bummed as you were); it’s great to see that you’ve managed to move ahead nonetheless.

I can’t wait to replace Firefox!

thank you for your ongoing support, I really appreciate it! :)

hopefully adblocking will come soon!

We should have more people who can't wait to replace chrome.
Won't start on macOS 10.14.1
make sure to completely kill any running zombie instances of the program, copy it to your disk and try running it again.

(e.g. search in activity monitor for "cocoa-webkit" and "next", and make sure there are no processes with that name)

I think it is more than that, libxmlrpc++.8.39.dylib missing in my case I guess
it should be shipped within the app bundle, can you please tell me what "otool -L Next.app/Contents/MacOS/cocoa-webkit" returns?

I'm not using libxmlrpc++, just libxmlrpc

This is what I get:

  /Applications/Next.app/Contents/MacOS/cocoa-webkit:
  @executable_path/../Frameworks/libxmlrpc_server_cgi.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc_xmltok.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc_util.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc_packetsocket.8.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc_server_abyss.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc_server.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc_abyss.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc_client.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  @executable_path/../Frameworks/libxmlrpc_xmlparse.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
  /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1560.12.0)
  /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
  /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.200.5)
  /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1671.10.106)
  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1560.12.0)
  /System/Library/Frameworks/WebKit.framework/Versions/A/WebKit (compatibility version 1.0.0, current version 606.2.104)
here you go: ( for /usr/local/lib/libxmlrpc++.8.39.dylib)

  libxmlrpc_packetsocket.8.39.dylib:
	/usr/local/lib/libxmlrpc_packetsocket.8.39.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/lib/libxmlrpc++.8.39.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/lib/libxmlrpc.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/lib/libxmlrpc_xmlparse.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/lib/libxmlrpc_xmltok.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/lib/libxmlrpc_util++.8.39.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/local/lib/libxmlrpc_util.3.39.dylib (compatibility version 0.0.0, current version 0.0.0)
	/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.0.0)
What if a browser was built like Emacs is built? With low-level rendering core exposing almost everything to scripting in Lisp, and the entire UX written in Lisp, fully customizable?

It appears that Next goes in this direction. I don't know if gtk-webkit allows to script it very deeply, e.g. enough to expose DOM and write extensions in Lisp.

It would also be great to have something like the Emacs's customization framework, and something like Melpa. (But this is obviously far down the road.)

Ever since I started using Org Mode in the Android app "Orgzly" and in Visual Studio Code, I've been wishing a lot more was written so it could take advantage of Lisp.

Mostly because I'm selfish and want more of Org Mode's features supported in more places, but also I'm super impressed by Emacs' scripting/control abilities.

I'd also like to see vim with a mode specifically for Org Mode. But that sort of idea is very much beyond my talents :/

Yes, when I finally have free time, I'll spend some of it to write a reasonably good implementation of Org Mode data model in Typescript, and maybe in something else, to help making Org Mode support painless everywhere, like Markdown now.
I really wish I was a better, more focused, coder to be able to help such efforts. It would benefit me to really learn Typescript deeply, since many of my employer's projects are written in it. Me = Sysadmin/Devops = jack of all trades, master of none.
I make lists. Lists (and a planner I mostly ignore) keep my on track. The "Get(ting) Things Done" method is, in some ways, making lists. Maybe that could help?

That, and pacing myself during mentally intensive tasks. I do 25 on, 10 off (more than pomodoro, because my brain). This works really well for me. You may have to adjust the variables to make it work well for you.

There is a vim org-mode plugin but it's super-limited, mostly only proper syntax highlight + folding...

Anyway, my dream is a browser, a real one for modern web, built-in in Emacs. eww is nice but substantially useless and anytime I use Firefox (witch is well... Nearly any day) I complaint due to it's limited "window/buffer" (tabs) management, inconsistent keybindings support despite saka key, limited text navigation capabilities etc...

Imaging your (big) bookmark collection in an org file, ivy-searchable on demand, seamless integration for instance when you receive complex html mails (sgrunt), or for html feeds (sgrunt again) etc. instead of asphyxiated bookmark bar/manager + tab manager... Webpages as Emacs buffers, arranged as any Emacs windows, with consistent keybindings etc...

If you ever feel like "deep diving" into Org Mode, I'd consider giving Emacs a try.
You're basically just using Emacs then, right?

https://www.gnu.org/software/emacs/manual/html_mono/eww.html

Yes, this is a nice thing. But it supports way fewer features a modern web site could legitimately use.

The modern browser engine exposes a lot of controls to scripts and to the chrome layer. IIRC Firefox uses this extensively to code (most of) the UI in Javascript and HTML/ CSS. But this is not very exposed to the user, and web extensions are intentionally limited.

> What if a browser was built like Emacs is built? With low-level rendering core exposing almost everything to scripting

Firefox with XUL was this kind of browser.

give us microsoft users a chance too. i'd like to try it, but im not going to waste precious free time to do so.
Hum, a prize for such a good work, a minus for posting a https://next.atlas.engineer/article/technical-design.org that's actually html, not org... I'd open in Emacs and say "sgrunt"... :D

BTW for me the sole really missing points today are addons, something like PrivacyBadger, Google/Facebook container etc I use Privoxy but that's not enough (or I do not know how to use it well enough) and I feel the need of something more integrated in Emacs that works really, not like eww...

It is actually an org file :)

https://github.com/atlas-engineer/next-site/blob/master/arti...

Next has a long way to go, but now that the architecture is solid, we're ready to make a lot of progress on feature building and stability

Thanks for your work, I have tried few months ago Next and really like it despite for now it's not my default browsers, I haven't really enough competence to help but I certainly follow the development process!

IMO after Ubuntu "collapse" (IOW the decision to leave Desktop apart) GNU/Linux start to be no more a generic desktop OS but again a niche desktop for us geek and in that sense it's time, at least, to regain the power of our classic tools, avoid they fade into oblivion and life as happy and comfortable we can. In that sense having a browser like Next is a needed thing.

If I look at my actual desktop usage Emacs il 100% of the time since it's my WM but the second most used application is FF and it's a pain, even with Saka key, GhostText etc...

Hope for the best :-)

Ps on org file, yep, only I was hoping to being able to browse-url-emacs directly :-) It's something like "hey, org can do nearly anything, we can start imaging a web-org sites: casual users get org-exported html, tech-savvy one get directly org so they can navigate them, save them etc with ease".

Good job on the website. Clear and simple. I might give it a go, I wanted lean and keyboard oriented (never got to setup firefox extensions properly for that).

Bravo

I see complaining about GTK on your first link - have you heard of Qt?
I've not only heard of QT, I originally developed Next in QT. I can't say it was a good time :D
Not GTK per se, but the Common Lisp bindings for GTK.
Very nice, we need more of that.

There's also qutebrowser [1], but none of these are usable without a proper adblocker implementation.

[1] https://qutebrowser.org

Many browsers like this rely on network-level ad blocking, because the devs, and a lot of their userbase (mostly power users), prefer it over maintaining a js implementation.
Qupzilla also was a nice one until they killed it and migrated the code to KDE (triple facepalm).
I'm using Falkon, which it became, currently. It's pretty good. You can write plugins in C++, Python, or QML (in master).
Looks like a great idea. However as someone who spends all day in vim, I wish it had an option for vim bindings or at least some kind of modal interface.
> Another cool side effect of this approach and that it is by design very natural to add support for extra web renderers.

As you start moving to other platforms and see WebKitGTK as a limiting factor, I would strongly suggest looking at CEF [0] as an extra addition to your abstraction. I know you fear a Google/Blink hegemony based on your post, but beyond that it is the best cross-platform browser embedding lib I have used (I developed a browser using it and Qt myself).

0 - https://bitbucket.org/chromiumembedded/cef

There is also Vimb [1], which is another keyboard-focused web browser. It also runs on GTK+ and WebKit2. How does Next compare to it? (Except for obviously being more suited for scripting and having Lisp support.)

When I was trying Vimb for myself it suffered from frequent WebKit («WebView crashed») crashes. And also its performance seemed to me worse than, say, latest Firefox Quantum or Chromium — it was consuming much more RAM when using many tabs or opening extremely large web pages (few megabytes of html with many pictures in it). Although it starts a lot faster than the latter two.

How does Next compare to Vimb with respect to performance and crashes?

[1]: https://fanglingsu.github.io/vimb/

EDIT1: minor change of wording

Hi, thank you for your interest!

I've never used VIMB, but I guess it is subject to the webkit port, since on Linux you more or less only have Webkit2gtk+ your experience should be roughly the same.

There seems to be a lot of demand for a blink/chromium port, and while I am personally strongly against blink/chromium, we may produce a port, or perhaps a quantum port if that is at all possible.

Am I the only one who is every problems with the download being an lzip file?

I really fought with my laziness to search what a "lz" file is, and the command to use to extract.

I'm doing:

"tar --lzip -xvf next-linux-gtk-webkit.tar.lz", and getting "tar (child): lzip: Cannot exec: No such file or directory". I guess I have to install lzip and tar isn't enough (so, the command I found was wrong).

Is there a reason to not use the more popular (on Linux) tar.gz or even .zip? I assume lzip offers better compression, but I bet I'm not the only one who's heard it for the first time today.

From my understanding (and the biased content at https://www.nongnu.org/lzip/lzip.html ), lzip is higher compression than zip and gzip. It uses LZMA, which makes it essentially the same as xz (which itself is 7zip without the tar-like functionality). The difference seems to be that the metadata in lzip makes some smarter choices, which reduces redundancy and makes recovering from corruption easier compared to xz.

xz is more widely installed, so it's a case of Worse Is Better.

Super cool that you use this Guix thing and all that (although Nix is better, who cares), but it is impossible to run this thing.

I've followed the steps and still my binary won't execute and the error messages aren't helpful. Please compile this thing into a single executable!

If you can produce a single executable, I will be quite amazed :D considering there is both a lisp core and platform port which are separate programs, however, you are free to try :D

on a more serious note, it is still alpha, so sorry about any issues you are having, we're working on making things easier for users to install and more robust!

I know, it's my bad, there is an known issue in the Guix pack, I'm working on it!

Next Guix pack should work flawlessly!

Should have just forked Chromium tbh. Then all the extensions and configs could easily be transferred over.

Great to see people using Common Lisp.

I see no one mentioned luakit (https://luakit.github.io/). From the site: "Luakit is a highly configurable browser framework based on the WebKit web content engine and the GTK+ toolkit. It is very fast, extensible with Lua, and licensed under the GNU GPLv3 license. It is primarily targeted at power users, developers and anyone who wants to have fine-grained control over their web browser’s behaviour and interface."
I love LuaKit. Zero chrome/bezel on the browser windows - turn off window decoration and the web content is just a (fully) resizeable rect in your desktop layout. The vim-style keyboard controls are a plus (for me, anyway).
Luakit is probably what's closest to Next in terms of design.

The important differences, in my opinion:

- Next is not bound to WebKitGTK+, so unlike Luakit it can run on different platforms with different engines.

- Next uses Lisp, which is I believe much more powerful, both for large scale development and hackability.