5 ms·

Hbro: Haskell based browser

74 points by artagnon 14y ago

dscrd 14y ago
We are the knights who say NIH!
- tree_of_item 14y ago
  I don't think NIH applies to projects like this. It's not like they're writing an HTTP server.
dhucerbin 14y ago
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/ http://www.conkeror.org/
- bm3719 14y ago
  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 14y ago
    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 14y ago
      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 14y ago
        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 http://news.ycombinator.com/item?id=4123656
- jdost 14y ago
  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/ http://portix.bitbucket.org/dwb/
pestaa 14y ago
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.
- dons 14y ago
  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.
  - _delirium 14y ago
    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.
- mjhoy 14y ago
  It's only ~1500 lines, with comments. find Hbro -iname '*.hs' | xargs cat | wc -l
  - aoe 14y ago
    A little off-topic, why didn't you just do "xargs wc -l"?
    - mjhoy 14y ago
      Ah! Didn't realize wc provided a total. I had used the "cat | wc" bit for scripts to just grab the number. Thank you.
    - babarock 14y ago
      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 http://unix.stackexchange.com/a/41745/4098
rwos 14y ago
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/ http://grail.sourceforge.net/
- bct 14y ago
  > 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 14y ago
    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 14y ago
      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.
    - batista 14y ago
      >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).
pka 14y ago
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?
mgurlitz 14y ago
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 14y ago
  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 14y ago
    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 http://neilmitchell.blogspot.com.ar/2007/03/hsexcel.html

74 points by artagnon 14y ago

dscrd 14y ago

We are the knights who say NIH!

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

dhucerbin 14y ago

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/ http://www.conkeror.org/

bm3719 14y ago
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 14y ago
  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 14y ago
    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 14y ago
      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 http://news.ycombinator.com/item?id=4123656
jdost 14y ago
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/ http://portix.bitbucket.org/dwb/

pestaa 14y ago

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.

dons 14y ago
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.
- _delirium 14y ago
  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.
mjhoy 14y ago
It's only ~1500 lines, with comments. find Hbro -iname '*.hs' | xargs cat | wc -l
- aoe 14y ago
  A little off-topic, why didn't you just do "xargs wc -l"?
  - mjhoy 14y ago
    Ah! Didn't realize wc provided a total. I had used the "cat | wc" bit for scripts to just grab the number. Thank you.
  - babarock 14y ago
    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 http://unix.stackexchange.com/a/41745/4098

rwos 14y ago

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/ http://grail.sourceforge.net/

bct 14y ago
> 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 14y ago
  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 14y ago
    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.
  - batista 14y ago
    >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).

pka 14y ago

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?

mgurlitz 14y ago

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 14y ago
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 14y ago
  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 http://neilmitchell.blogspot.com.ar/2007/03/hsexcel.html