Hbro: Haskell based browser | Hacker News Reader

Hbro: Haskell based browser

github.com

74 pointsartagnon33 comments

I wouldn't call that a "Haskell based browser". 1500 lines of Haskell against maybe 300 KLOC (guessed) of webkit alone. That's not "Haskell based", that's only using Haskell as a glue.

The same goes for uzbl, too, of course. Things like the Grail Browser [1] (a Python webbrowser, including the possibility to run client-side python-code - but sadly obsolete and not maintained anymore, as far as I can tell) are so much cooler than just tying webkit to GTK using $LANGUAGE.

I mean, it's not like HTML layout engines or JS-interpreters are somehow impossible to write from scratch.

[1] http://grail.sourceforge.net/

> I mean, it's not like HTML layout engines or JS-interpreters are somehow impossible to write from scratch.

Today's web standards are large & complex enough that it is practically impossible without a full-time team.

You could have said the same thing about unix-like operating systems in 1991 - yet, somebody wrote one from scratch without a full-time team.

I'm not trying to put this little project here down, far from it. I think it's pretty neat. I can imagine even neater (if that's a word) things, though... :-)

IMO modern web browser internals are more complex and less fun to work on than 1991-era Unix clones.

I'm not being defensive of this project, I'm being critical of the direction web architecture is going.

>You could have said the same thing about unix-like operating systems in 1991 - yet, somebody wrote one from scratch without a full-time team

Err, at 1991 he just wrote a rudimentary OS from scratch. To make it more unix-like, stable and feature full took hundreds of people, including tens of full time company employees (IBM, RedHat, etc).

This is one of my fears with the complexity explosion called HTML5 / CSS3.

We are bequeathing the future a world where building new browsers is approximately an impossibility.

The Web is so much. Now all devices can consume the same files with comparable user experiences. There are reasonable standards. Javascript is a reasonably advanced and simple language (for the time being). But the web has failed much as well.

Hopefully the web will mature someday and someone will clean up the mess we are leaving them.

> I wouldn't call that a "Haskell based browser". 1500 lines of Haskell against maybe 300 KLOC (guessed) of webkit alone.

WebKit is much bigger than that - at least one order of magnitude bigger (that is, 3 millions of LOC).

So yes, this is a tiny wrapper around a huge C++ codebase. The name is kind of misleading. But still a cool project.

The comments criticizing this for using WebKit are ridiculous. Most Safari users would never guess that Chrome runs on the same layout engine, but with a different JavaScript core, networking code, a sandbox, an extension architecture, and UI.

Using Haskell for any of the above components (especially the last three) could help make a browser that's more configurable and safer than anything Firefox Chrome or Safari could ever offer.

Certainly, a browser larger written in Haskell might be interesting.

People are critising this because so far they have done nothing interesting, just written a simple 'hello world'-type wrapper around a mountain of C++ code.

Yes, I was searching for an HTML renderer written in Haskell. It makes me remember HsExcel http://neilmitchell.blogspot.com.ar/2007/03/hsexcel.html

I thought this would be about rewriting the core HTML renderer or JS engine in Haskell. As it stands now, is this not just the "chrome" around WebKit?

I can't install it now, but I will as soon as possible.

Now I'm using Conkeror [1]. Essenstial features for me, are:

  Buffer selecting with fuzzy matching
  Hinting links with letters, home row would be superb
  Some developer interface for creating interactive javascript extensions

[1] http://www.conkeror.org/

And the ability to block ads, which is possible in Conkeror.

I'd also prefer an Emacs-style keybinding set (or at least the ability to map one), so I don't have to switch muscle-memory mode when jumping from my editor to graphical browser. But, I'd be willing to give that up if the memory footprint of a thin Webkit-based browser is more minimal. I occasionally have to restart Conkeror after sustained heavy use due to it hogging system resources (it'll eventually bring my Atom n270 to a grinding halt). This is probably xulrunner's fault though, I suspect.

This is probably xulrunner's fault though, I suspect.

Do you have any actual data to support that claim (or suspicion, as you want)?

It's just a suspicion, as stated. The reason for this though is that Firefox has (or had) the exact same behavior in older versions I've used prior to switching to Conkeror.

I was thinking this was going to be your argument, which is why I pressed the issue. If you have a reproducible testcase where Firefox without plugins ends up "hogging system resources", then by all means report it.

You may like dwb[1] It uses webkit and handles what you mentioned. Written in C++, so you don't get the Haskell learning part, but it doesn have the javascript extensions thing (albeit not fully finished yet).

[1] http://portix.bitbucket.org/dwb/

I honestly love projects like this one, but is the implementation language really worth fragmenting this niche? Uzbl is in Python and I can't think of any objective reason why Haskell would be better for a browser.

There are some benefits using a compiled, optimized and modern statically typed language for desktop software that runs on the user's machine -- it's less work to get a smaller memory footprint, reduced liklihood of runtime errors, faster start times.

For "big" software I agree in principle, but for both of these browsers, the vast majority of computation happens in the embedded WebKit rendering engine, which is written in C++. The browser built around it is more UI bindings and an API to interact with other Unix software, and for that, afaict, Python isn't really slowing uzbl down.

It's only ~1500 lines, with comments.

  find Hbro -iname '*.hs' | xargs cat | wc -l

A little off-topic, why didn't you just do "xargs wc -l"?

Ah! Didn't realize wc provided a total. I had used the "cat | wc" bit for scripts to just grab the number. Thank you.

Continuing on this off-topic, this construct is not optimal and can possibly break if one of the filenames has some funky characters (spaces, line breaks, carriage returns, unprintable characters, ...). This happens (unfortunately) more often than you think, and it's a very good idea to learn how to used these commands defensively.

Basically you have two choices, depending on the Unix you're using:

- find ... -print0 | xargs -0 wc -l

- find ... -exec wc -l {} +

The second one is defined by POSIX and, as far as I know, works on every Unix except for OpenBSD (who only implemented this feature starting version 5.1 in 2012).

The first one is non-POSIX so several Unices do not implement -print0.

To the best of my knowledge, GNU find should work fine with both.

More info: http://unix.stackexchange.com/a/41745/4098

Because of this:

     Any arguments specified on the command line are given
     to utility upon each invocation, followed by some
     number of the arguments read from the standard input
     of xargs.  The utility is repeatedly executed
     until standard input is exhausted.

In other words, if the argument list is too long, xargs will chunk the input and call the program repeatedly. This means that on very large projects, 'wc -l' will be called several times on subsets of the files, and you will get an incorrect total listed at the bottom.

putting a 'cat' in between fixes that. 'cat a b; cat c d' is equivalent to 'cat a b c d', so the chunking doesn't matter. And wc -l can just read from stdin without worrying about how many files there are.

Come back when they replace WebKit with something written in Haskell. I could write a "browser" in about 50 lines of C if I wanted.

"I honestly love projects like this one, but is the implementation language really worth fragmenting this niche?"

If you honestly love these kind of projects, than I can't understand why you're asking this question?

It just has to be worth for the guy doing it. Every other view point considering the usefullness of it or how profitable it would be, is just killing all the fun and in a way taking away all the meaning.

"Uzbl is in Python and I can't think of any objective reason why Haskell would be better for a browser."

It's like asking, if there's an objective reason to write an applikation in Haskell instead of Python.

I feel like something similar could have been said about Xmonad. Yet, through its configuration and extension mechanisms, it's become a gateway for a lot of people wanting to learn Haskell. This niche isn't likely to fragment as long as it's made up people obsessively scratching their own itches.

xmonad was written in Haskell because it needed to be small, fast, but safer than C.

On the other hand, projects like this come in handy when someone inevitably brings up the tired old line of "are there any _real_ projects written in Haskell?".

Uzbl isn't really written in one language. uzbl-core (the Webkit wrapper) is written in C, the event-processing framework and tabbed-browsing wrapper are written in Python, and much of the functionality is handled by external scripts written in sh and javascript.

The difference has nothing to do with the language; hbro is taking a very different approach to configuration and integration. (e.g. uzbl does IPC using FIFOs and sockets; hbro is using ZeroMQ. uzbl is extensible with external scripts; hbro seems to be extensible using Haskell.)

(I'm the maintainer of uzbl. k0ral used to be involved with uzbl, and I'm sure hbro has learned from uzbl's mistakes.)

We are the knights who say NIH!

I don't think NIH applies to projects like this. It's not like they're writing an HTTP server.

Reply on news.ycombinator.com