Show HN: Next Browser native on Linux • Hacker News Board

Re: Show HN: Next Browser native on Linux

#31

Post by jmercouris » Wed, Dec 05, 2018, 4:26 PM UTC

rauhl wrote: post #27

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

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

hopefully adblocking will come soon!

Re: Show HN: Next Browser native on Linux

#32

Post by dmortin » Wed, Dec 05, 2018, 4:28 PM UTC

PaulHoule wrote: post #25

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. Th…

There are text based browsers which can be used for this: https://en.wikipedia.org/wiki/Text-based_web_browser

Re: Show HN: Next Browser native on Linux

#33

Post by jmercouris » Wed, Dec 05, 2018, 4:28 PM UTC

dtornabene wrote: post #26

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

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!

Re: Show HN: Next Browser native on Linux

#34

Post by jmercouris » Wed, Dec 05, 2018, 4:29 PM UTC

snaky wrote: post #23

dmortin wrote: post #4

Earlier quoted context omitted.

Isn't there some popular language with the same capabilities? Is it a Lisp speciality?

Nowadays it's usually called 'hot reload' and everybody hype about how cool is that in React Native and Flutter.

2hype4me

Re: Show HN: Next Browser native on Linux

#35

Post by Ambrevar » Wed, Dec 05, 2018, 4:30 PM UTC

dtornabene wrote: post #26

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

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

Re: Show HN: Next Browser native on Linux

#36

Post by jmercouris » Wed, Dec 05, 2018, 4:30 PM UTC

mosselman wrote: post #29

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)

Re: Show HN: Next Browser native on Linux

#37

Post by jmercouris » Wed, Dec 05, 2018, 4:30 PM UTC

opencl wrote: post #30

jmercouris wrote: post #24

Earlier quoted context omitted.

to answer your question, yes

Great, thanks. My Lisp skills are very rusty but I think I'll give this a shot.

enjoy :)

Re: Show HN: Next Browser native on Linux

#38

Post by ryacko » Wed, Dec 05, 2018, 4:32 PM UTC

Majestic121 wrote: post #11

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.

Re: Show HN: Next Browser native on Linux

#39

Post by always_good » Wed, Dec 05, 2018, 4:36 PM UTC

snaky wrote: post #23

dmortin wrote: post #4

Earlier quoted context omitted.

Isn't there some popular language with the same capabilities? Is it a Lisp speciality?

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.

Re: Show HN: Next Browser native on Linux

#40

Post by nine_k » Wed, Dec 05, 2018, 4:37 PM UTC

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