Hacker News new | comments | ask | show | jobs | submit login
Show HN: Next Browser native on Linux
198 points by jmercouris 74 days ago | hide | past | web | favorite | 114 comments
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!

No adblock is a show stopper for me, but they have a campaign on Indie Go Go with adblocking as one of the goals



This is correct! it is also next on our to-do list! https://github.com/atlas-engineer/next/tree/master/documents...

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!

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

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.

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

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

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

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 :/

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

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.

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?


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.

At one point you could embed webkit in emacs. https://www.reddit.com/r/emacs/comments/4srze9/watching_yout...

Do you plan to support WebExtensions[0] once they're standardized?

It seems like every time a new browser comes out, the immediate question is, "what does the extension ecosystem look like?" Since Next's website says that its goal isn't to be a massively popular, omnipresent browser, the answer to that question is probably always going to be "worse than Chrome/Firefox." Even if I'm writing my own extensions to fill in that gap, I'm fine dipping into Lisp for lower-level functionality or to customize the browser itself, but for higher-level stuff I'd like to see browsers use existing standards rather than have 3 different APIs to do roughly the same things.

As a user, it's very tough for me to justify doing any browsing, even just experimentally, outside of Firefox where I have UMatrix and Ublock. And while I'm sure you'll put in a great adblocker eventually, it probably won't be as good as UMatrix and Ublock, because the stuff you're building won't have the same level of widespread scrutiny that those extensions get.

Nowadays I feel more and more like most browser extensions ought to be written in a way that is roughly as cross-platform as the web itself.

[0]: https://browserext.github.io/browserext/

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

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


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

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!

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.

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

I saw your post at lisp.reddit.com today and there was a redditor there that brought forth webkit security concerns that IMV you did not properly address.

Thread is here (https://old.reddit.com/r/lisp/comments/a3b8m0/browsing_with_...)

I am an ex-Googler and I happen to know the effort that the Google security team expended when designing the Chrome security model was quite significant. We would all like more competition in the browser arena but running webkit without any security protections like Next browser does is putting yourself at risk, unnecessarily. I urge you to spend some time understanding the security implications of what you are doing.

Wow, that thread is horrible. It's just flamebait from both sides. From metroholografix:

> I fear that webkit can not be salvaged

> How about all the huge OSX vulnerabilities that have been discovered?

> You are so out of touch with the state of cybersecurity that it's terrifying. Not only that, but you insist on this nonsensical adversarial attitude towards me when I'm spending my personal time trying to inform you.

> WebKit, which is abysmally bad security-wise to begin with

From the other side:

> If I didn't know any better I would say you were a paid blink shill

> Safari, which runs webkit is safer than Chromium. Because at least we know that Apple cares about security.

In all, I disagree with u/metroholografix's claims that Chrome is inherently significantly more secure than Safari. Sure, it might be if you are comparing yourself with running WebKit in-process and with no sandbox. But with the appropriate protections which macOS provides (which is where I fault u/jmercouris, because he cannot compare his project with Safari because his project doesn't actually implement these security features), it is stupid to move a project to Blink in this case.

Hey there.

Can you point at something in my reddit posts that is inaccurate or plain wrong? I agree that my tone could be better but notice the difference between my first post to him and my subsequent replies. It's hard to maintain a civil attitude when I am immediately accused of being a shill. Nevertheless, I think I have provided enough useful information to him. Notice how he responds each time.

You wrote that you disagree with me regarding Chrome being inherently more secure than Safari. Fair enough. Do you have any additional information that makes you think so? I pointed to PWN2OWN when I made my point. I think it easily proves that Chrome is indeed inherently more secure than Safari. That does not mean that he has to move to Chromium, it was one suggestion. He could stick with WebKit and implement a sandbox of his own. Or choose not to do that but let users know, loud and clear, that this is the case so everyone understands the trade-offs involved.

To me, based on my interactions with him on reddit, it seems that jmercouris needs to revisit a lot of his beliefs and rapidly bring himself up-to-speed with the current state of browser security.


The crux of the argument I'm making is that both Chrome and Safari are quite secure. Maybe Chrome is slightly more, maybe it's not, but it's disingenuous to present WebKit as completely broken and Blink as the only engine with good security engineers.

> He could stick with WebKit and implement a sandbox of his own.

I think this would be the best solution. Running WebKit without a sandbox is stupid, but I think your responses did not help jmercouris take your comments seriously because, to be honest, you do kind of look like a Blink shill.

Here is some more data regarding Chrome vs Safari, from https://www.zerodium.com/program.html

These are prices for 0-day exploits.

For desktops :

$250,000 - Chrome RCE + SBX (Windows) including a sandbox escape

$80,000 - Safari + SBX including a sandbox escape (it is on the graphical table below the changelog)

$100,000 - Chrome RCE without a sandbox escape

$50,000 - Edge, Safari, Firefox RCE without a sandbox escape

To me, these prices clearly indicate that Safari is a lot easier to exploit than Chrome. They also indicate that the Chrome sandbox is a lot harder to bypass (look at the relative price differences).

For mobile the payouts are similar which indicates that Apple has paid more attention to IOS security-wise. That is also the consensus amongst most security experts I know.

My guess is that the payout is partially a function of popularity, which is why the Windows exploits have higher bounties.

Exactly. His argument would make sense if there were ONLY supply side differences but there are clearly HUGE demand side differences with Chrome making up a large majority of internet traffic.

My impression was that with the switch from (UI)Webview to WKWebKit the webview is put in a sandbox automatically. At least the rendering is now out-of-process. Do you know anything about that?

Well, WKWebKit is in fact sandboxed, on macOS, as per what is going on with Webkit2GTK+, I am less familiar, but the project is well aware and on top of all security vulnerabilities: https://webkitgtk.org/security.html

Ok, didn't notice that this is a linux app that uses plain WebKit.

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

[Vimium](https://vimium.github.io/) is nice.

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!

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

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

also qutebrowser is vim-like keybinding, and nextbrowser is emacs-like keybinding

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

Which only encourages the idea that Next is Qute's direct competitor.

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.

Isn't NeXT still a trademark name?


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


thank you! :)

Tridactyl (https://addons.mozilla.org/en-US/firefox/addon/tridactyl-vim...) is another viable alternative (modern incarnation of Vimperator/Pentadactyl).

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.

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!

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!

> 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

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.

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!

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.

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)


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!

We should have more people who can't wait to replace chrome.

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

hopefully adblocking will come soon!

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.

enjoy :)

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!

Dear lisp fanatics,

Please write an ad blocker in lisp for this thing.

Sincerely Yours, Chance

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.

its in the works!

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

Great to see people using Common Lisp.

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.

please register to vote (registration is on download page)! https://next.atlas.engineer/download

if there is enough interest for a Windows port, we may very well make one!

The logo on github looks way too much like NeXT Computer's

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.

Crap, I thought they meant the NeXT browser.

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:

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

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

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.

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

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.

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

I find with BeautifulSoup or JSoup it is often just as easy to write a scraper than an API client, particularly when the authentication for the API is like this:


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

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

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

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.

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.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact