Vimprobable web browser Interview

mtreibton · 2010-12-20 12:39:34

Hi,

I know some of you here like this browser - and a fellow user suggested I posted a transcript of an interview with the developers, so here it is. Enjoy!

> * Introduce yourselves -- how long have you been using/developing
> Vimprobable, and what attracted you to it?

[HS] I'm Hannes Schüller, working as an engineer in aircraft information
security during the day. I started using/developing Vimprobable sometime
between August and October of 2009 - depending on what one defines as
the beginning of Vimprobable (see next question).

[MF] I am Matto Fransen. I have been using Linux for 15 years. I like the speed
and the userinterface of textmode applications. So most of the time I used
textmode webbrowsers. For graphical usage I have been using Vimperator for
quite some time. I use vim a lot and have got used to the hjkl
motion-keybindings. The fact that Vimperator was build as a plugin for Firefox
did not seem the optimal solution to me. Also I had experienced some troubles
during upgrades of Firefox. So I started looking for a different solution. I had
tried out UZBL and Vimpression. In november 2009 I discovered Vimprobable and
started using it. In december 2009 I wrote my first patch for Vimprobable.
In the mean time Vimprobable has replaced my usage of textmode webbrowsers almost
complete. The userinterface is good and so is the speed.

[TA] Hi.  My name's Thomas.  I'm a senior software engineer for a small company
in England producing firewall and web-content security software.

I've been using Vimprobable since the Vimpression days after I stumbled
across it quite by accident.  Unlike Hannes' unhappy experience it did
compile for me, although wasn't that usable.  At that time, I had been
using Vimperator a lot, and didn't think anything of it really -- sure, it
was slow, but then there's this underlying acceptance from most people (not
myself!) that this is how browsers are meant to operate.

I'd tried uzbl, but unlike its rather interesting name, didn't deliver on
that front.  It seems to me their pipelining of "one tool to do one thing
well", when combined in a long chain of IPC will form a web-browser, just
didn't work for me.  Uzbl was slow, and crashed a lot.  A shame really,
since it still looks promising.

So it was by chance in April 2010 I had heard of Vimprobable via a post on a
NetBSD mailing list I think.  I was already thinking of trying to improve
uzbl, but after trying Vimprobable, I decided it was time to roll up my
sleeves and look at this particular browser more closely.

So in April, I caught wind of a thread which had proposed to hook directly
specific key-bindings to switch tabs via xdotool -- but this was, a
sub-optimal solution.  So I pitched up, suggesting that one could send fake
key-presses via XSendEvent() instead, making it agnostic to most specific
programs.  The original author and I worked to improve this, and the
resultant patch was accepted into Vimprobable as a result.  My work on the
FVWM window manager (having a strong background in X11 programming) made
this easier for me.

Aside from that, I've sent through a lot of patches for memory fixes, cookie
support, etc.  Which has earned me respect as a developer on the project,
although I don't consider myself worthy of such a status -- I still consider
myself as a patch-monkey, and always will do for this project, most likely.
:)

> * How did Vimprobable start -- and what was the main motivation behind
>   writing it?

[HS] As so many other stories, this one also started with pain. As much as I
liked Vimperator and what it did, its Firefox basis had really made it
unusable. So I looked out for alternatives. At that point, I found three
potential candidates for my daily browsing:

- uzbl looked very interesting, but relied heavily on Python scripting
  (a language I strongly dislike), was a little bit fiddly and (at the
  time) couldn't be used in different input modes. I was (and still am)
  pretty sceptical about the practicality of some design decisions.
  Think file downloads: I'm quite sure there will be some download
  methods around which will simply never work by passing it to wget.
  Which is not a fault of uzbl, but of crazy website authors using
  stupid schemes to 'protect' their files, but from the user
  perspective, this doesn't really matter unfortunately.

- surf version 0.1 had just been released, but it did too little for me.
  I followed the discussions on their mailing list and it seemed they
  even wanted to slim the functionality down even more. It wasn't fully
  usable with the keyboard. Also, no modal design.

- vimpression looked very promising: Vimperator-like design, but
  standalone. I decided to give this one a try.

Unfortunately, it didn't even compile. After a few quick fixes, I found
some of the functionality which was promised on the website not working
(most importantly link hinting) and other features I considered
essential to be simply missing (bookmarks and so on). Still, vimpression
looked like the best basis, so I started hacking away.

When I had collected a couple of patches which made the browser
basically usable for me, I sent them over to the original author (Leon
Winter). His reply was very nice and encouraging, but ultimately
disappointing: He had abandoned the project. This was unfortunate. I
asked him whether I could continue the development under the original
name, but he prefered an actual fork - so that was what I did. I
integrated my changes into my own tree, renamed the browser to
Vimprobable and put the repository on my website.

I didn't really advertise it. I posted on suckless' mailing list - that
was it. My expectation was that maybe one or two people would have a
look and smile, but not more. Boy, was I wrong...

[MF] This one is for Hannes :)

[TA] Hannes has provided more information here than I ever could.  I did send
Leon a few emails back in the day but never heard back from him.  :)  I
don't take exception to that though.

> * There's been something of an explosion regarding minimal web-browser,
>   and basing them on editors as inspiration.  Do you think Vi(m) lends
>   itself well to this in web-browsing, and why?

[HS] First of all, with regards to what you call an 'explosion': This is the
natural reaction to the common browsers having become way too bloated.
There is an audience for usable and fast browsers. 'The right tool for
the right job' as a paradigm doesn't go away just because the big ones
all compete in the opposite direction. All I can say is that if Leon
hadn't given up on vimpression, I wouldn't have started Vimprobable. I
would have been glad just to provide patches to someone else's project.
However, the authors of some of the projects which have been started
since then (I listed the ones which existed prior to Vimprobable) think
differently. That is their right. Some of these projects have cited very
good reasons to be independent (usually fundamentally different design
goals). Others might be pure vanity projects which will probably
disappear again soon. But that's the beauty and the bane of free
software: We can share useful code with the former developers while the
latter are allowed to have their way, too.

As for Vim being used as a sort of basis (or rather inspiration), I'd
say it works, because it's a well-proven and efficient concept. So why
wouldn't it be a good idea for web browsing? I'm going to let you in on
a secret now, though: I'm not actually using Vim on a daily basis.
Vimprobable (at least as far as my parts are concerned) is written in
nano :)

[MF] The web-browser has become an major application which is used very often during
the day. So a good and efficient userinterface becomes more important. In my
opinion vi lasts as long as it does because among other things it has a
very efficient userinterface. Also, when one works a lot in vi (or vim), a
lot of the frequent used key-parterns have become a habit. So it is a great
thing if those habits can be expended to other heavy used applications.

[TA] It can do, I suppose.  I use Vi(m) daily (more emphasis on Vim, although I
use enough bindings from both such that it might as well be vi pure -- or at
least ":set nocompatible" mode.  :)  Vimperator has shown how popular the
modal interface to browsing can work, and if, like me as a programmer, you
find yourself in an editor like Vim all the time, extending that to the next
most common task of web-browsing isn't too much of a stretch.

I like the ability of my browser (Vimprobable) that I can have a URL in the
clipboard, and simply switch to it and press the "p" button to open that
URL.   I often then watch in amusement, my colleagues copying and pasting
with the mouse some URL, which I've then done in seconds, simply because my
browser is seemingly modal.  :)

So I think it can work, but it's not for everyone.

> * Most people will have heard of Vimperator -- what limitations does
>   this have which make it undesirable for people who have or are
>   thinking of swithing to Vimprobable.  Is this a worthy consideration?

[HS] Is it a worthy considerations? I don't believe there is much of a choice
*not* to switch right away :)

As mentioned earlier, Vimperator itself is amazing. Firefox, though...
where do I begin? Almost unbearably slow (ten seconds for startup on my
quad core), unusably slow tab completion, extremely stupid new features
being introduced in every new version which turned into a chore to
disable (spell checker - need I say more?) while at the same time,
useful features seemed to be either removed or at least hidden under a
load of crap. Last, but not least, there is the Google issue for me.
Sending every URL I visit to a company which admits to live off private
data is simply unacceptable. And that's just one of the many intrusions
of privacy Firefox 'provides' its users with in the default settings.
Securing that browser has become virtually impossible.

[MF] Vimprobable is fast. It starts fast and it runs fast. Also it has a very good
tab-completion system, which is hard to beat.

[TA] It is -- although for some things, the Gecko rending engine is slightly more
polished than some of the Webkit ports.   Vimprobable uses the GTK webkit
port which isn't necessarily as mature as some of the others.  That said
though, it's perfectly on-par, and usable.  It's simply a lot faster, which
for most people is more important than anything else.

> * Does webkit -- the rendering engine used as a basis for Vimprobable --
>   make it easier or harder to write modal web browsers?  Are there any
>   disadvantages to using Gecko, from Firefox?

[HS] It makes some thing easy - for once, Webkit (or rather Webkit-GTK which
we're using) is much more accessible than Gecko (which is basically
impossible to get without the XUL baggage). Personally, I believe
linking any web-rendering engine to /any/ toolkit is crazy (especially,
because this means 'style' settings of the system will invade websites
which have their own colour scheme and design when it comes to form
elements), but there is no way to get a fairly complete rendering engine
without any toolkit. So it's an acceptable tradeoff. There is one major
disadvantage compard to Gecko: Although many developers using the engine
have requested it for a long time, there is still no API to access a
website's DOM tree directly in C. Which means we all have to deal with
Javascript to implement the logic which, for example, deals with
hinting.

[MF] The groundwork was done in Vimpression and by Hannes, so I can not talk from
experience, but the API of webkit makes it relative easy to build a
browser around it.

[TA] See above for the last question.  The big bottleneck here with the GTK
webkit port is lack of a solid DOM support.   Other than that, I think it's
lovely to develop against.

> * What major features or roadmap does Vimprobable have ahead?  Are
>   there any limitations in any of the libraries Vimprobable might use
>   which will make these tasks easier or harder?

[HS] We're pretty close to a 1.0 release right now. Just two bigger tasks left:

- Proper SSL support: Right now, Vimprobable simply accepts any SSL
  certificate presented to it at face value. This makes it vulnerable to
  man-in-the-middle attacks. Before anyone panics: This is a problem it
  shares with all of the other 'minimal' browsers. In this case, there is
  actually a small problem here: libsoup, which the HTTP communication in
  Vimprobable is based on, only has got two settings for this. Either, it
  checks certificates against a CA bundle or it doesn't. The latter is the
  default setting which results in the behaviour found in Vimprobable
  right now. The former, however, implies that any certificate which can't
  be verified with the provided bundle will be rejected. Which means users
  wouldn't be able to connect to such sites at all. So we need to depend
  on yet another library here to check the certificates outside of libsoup
  and in the case of an unverifyable certicate to present the user with
  the choice of accepting or rejecting the connection.

- An extended :map command. This function (in the vimprobable2 branch)
  is already pretty powerful, but I'd like to be able to bind keys to full
  colon commands. E.g.

  :map <C-e>=:set images=false

  Meaning that pressing Control+w should disable images to be displayed.
  This would give the users even more customisation power.

There is currently no plan for the time after version 1.0. As I see it,
what will happen then is mainly up to the user community. Just like
there already are quite a few features in there right now which I never
anticipated when I started the project. It's obviously not 'anything
goes', but if something won't affect performance, decrease usability or
increase complexity, why not?

[MF] Vimprobable tries to be a lightweight application. So in the future there
will be discussions about which features to add and which not. I expect that
the features that will be added in the future will be modest and mainly focussed
on improving the efficiency for daily use.

[TA] Hannes has already mentioned SSL support (which I am working on, since I
touch on that a lot at work).  This is quite important, and exposes most
limitations in what libsoup (a library we use extensively to do a number of
web-based things) is able to do.  We can just about use libsoup to do SSL
validation, but it is somewhat limited.  My vapourware-ish prototype
directly binds to GNUTLS instead.  Much easier and cleaner than the OpenSSL
bindings.  :)

> * At the moment there seems to be two Vimprobable versions.  What
>   process model is used to decide if a feature or bug-fix affects
>   both.  Does this project need both versions, and as a user, which one
>   is best-suited?

[HS] Anything related to run-time customisation (including changing of
settings) goes into vimprobable2 only. Bug fixes obviously go into each
branch which is affected by the respective bug :) Development is
virtually exclusively done on the vimprobable2 branch. I find myself
backporting work most of the time these days.

Personally, I'm using the vimprobable2 branch. vimprobable1 is obviously
the 'orginal'. I retained it for two reasons: First of all, at that
time, the :set and :map code was still very experimental while
vimprobable1 was already very stable. Second, there are people who
simply prefer a pure compile time customisation approach which,
admittedly, is much less prone to errors. Unless someone belongs to the
latter group and knows what he's doing, I would always recommend
vimprobable2 these days.

As for the need for two branches, let's just say that this has already
been the source of some internal disagreements :) For me, it's an issue
of honour to bring the 'classic' branch up to '1.0 status', too. After
that, I would probably put that branch into pure maintainence mode, i.e.
only doing pure bug fixes then. I encourage all users of that branch to
speak up (ideally on our mailing list) on this subject to see how
important this branch is.

[MF] I like to leave this question for Hannes :)

[TA] Hannes has best described this.  I use Vimprobable2 simply because it has
more features.  :)

> * Given the current fad of many similar projects to Vimprobable, what
>   makes this one more "attractive" than the other ones, in your opinion?

[HS] I've already touched on this a bit. Basically, I think that Vimprobable
has by now become one of the most mature browsers of this type. It's
extremely stable, it has got quite a few very useful features which we
already tweaked and optimised. There is an active group of developers
which makes it unlikely to go away or be abandoned in a half-finished or
buggy state.

Of course, there are also very good other projects. There, it comes down
to choice. If you want a browser which doesn't just /offer/ keyboard
control, but it /optimised/ for it, Vimprobable should be on your list
to try. If you don't want your browser to be /too/ barebones with either
/no/ way to get this functionality in or just with a lot of work, but
which simply works out of the box, you should put Vimprobable on the top
of your list, too. Last, but not least, Vimprobable has got another great
feature: Each website is opened in a new instance of the browser, allowing
for individual settings and separated privileges.

[MF] Vimprobable is a fully functional and fast webbrowser with a very efficient
userinterface. The tab-completion is awesome.

[TA] I can understand the code.  :)

jasonwryan · 2010-12-20 18:43:57

Do you have a link to the published version?

(Also, changed it to \[code\] tags so you don't have to scroll forever...)

mtreibton · 2010-12-20 19:16:33

jasonwryan wrote:

Do you have a link to the published version?
(Also, changed it to \[code\] tags so you don't have to scroll forever...)

hi,

no, its not published yet.

Thanks for the code tags. :)

Arch Linux

#1 2010-12-20 12:39:34

Vimprobable web browser Interview

#2 2010-12-20 18:43:57

Re: Vimprobable web browser Interview

#3 2010-12-20 19:16:33

Re: Vimprobable web browser Interview

Board footer