Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Next Browser native on Linux

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 117 posts

Re: Show HN: Next Browser native on Linux

#61

Post by xte »

jmercouris wrote: post #47
xte wrote: post #46

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

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

Re: Show HN: Next Browser native on Linux

#62

Post by mxuribe »

hedning wrote: post #56
ryacko wrote: post #38

Earlier quoted context omitted.

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!

Re: Show HN: Next Browser native on Linux

#63

Post by xte »

bloopernova wrote: post #41
nine_k wrote: post #40

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

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…

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

Re: Show HN: Next Browser native on Linux

#64

Post by dmos62 »

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…

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.

Re: Show HN: Next Browser native on Linux

#65

Post by snaky »

nine_k wrote: post #40

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

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

Re: Show HN: Next Browser native on Linux

#66

Post by dmos62 »

purerandomness wrote: post #60

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.

Re: Show HN: Next Browser native on Linux

#68

Post by kodablah »

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…

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

Re: Show HN: Next Browser native on Linux

#69

Post by kodablah »

> 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

Post reply on HN