

Hbro: Haskell based browser - artagnon
https://github.com/k0ral/hbro

======
rwos
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/>

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

~~~
rwos
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...
:-)

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

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

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

~~~
wslh
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>

------
pka
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?

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

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

~~~
gcp
_This is probably xulrunner's fault though, I suspect._

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

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

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

See also: <http://news.ycombinator.com/item?id=4123656>

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

~~~
mjhoy
It's only ~1500 lines, with comments.

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

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

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

------
dscrd
We are the knights who say NIH!

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

