Show HN: Next Browser native on Linux
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 ] threadI 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.
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.
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.
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!
Interesting to see that Next Browser integrates Lisp with WebKitGTK+.
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
Only allows one to not move a mouse sometimes.
https://github.com/atlas-engineer/next/issues/32
https://www.indiegogo.com/projects/next-browser-nix-support#...
I know it’s not as comprehensive as extension based blocking, but it seems solid.
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.
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.
" 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."
0 - https://github.com/cretz/software-ideas/issues/82
https://www.youtube.com/watch?v=o2ObCoCm61s
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".
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!
- "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`.
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!
hopefully adblocking will come soon!
(e.g. search in activity monitor for "cocoa-webkit" and "next", and make sure there are no processes with that name)
I'm not using libxmlrpc++, just libxmlrpc
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.)
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 :/
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.
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...
https://www.gnu.org/software/emacs/manual/html_mono/eww.html
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.
Firefox with XUL was this kind of browser.
if there is enough interest for a Windows port, we may very well make one!
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...
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
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".
Bravo
There's also qutebrowser [1], but none of these are usable without a proper adblocker implementation.
[1] https://qutebrowser.org
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
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
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.
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.
xz is more widely installed, so it's a case of Worse Is Better.
https://en.wikipedia.org/wiki/NeXT
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!
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!
Next Guix pack should work flawlessly!
Great to see people using Common Lisp.
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.