Integrating browser into your environment

Not so long ago I've finally started to play around with a little idea I had when I was writing the rant about markdown. That little idea was to split web browser into possibly several smaller utilities with a distinct responsibilities. In other words, to apply Unix-ish philosophy in a web browser. I've touched this idea in Web browsers are no more and then did some initial tinkering in Plumbing your own browser. Now time has come to draw conclusions. Think of this post as a direct update to the plumbing one.

I don't like IDEs. I have hand-crafted environments that I "live in" when I'm working on any of my computers. Window manager that I tinkered to my liking, my preferred utilities, my text editor, my shortcuts. Whole operating system is configured with one thing kept in mind: it belongs to me. IDEs invade this personal space of mine. And so do web browsers. Of course, you can configure both web browsers and IDEs to some extent. You can even integrate them closer to your normal environment, but in my experience sooner or later you'll run into limitations. Or you will end up with IDE consuming your entire operating system (hello, emacs!). I didn't like that.

Thanks to the amount of alternatives I can happily avoid using IDEs. I can't say that about browsers. Moreover modern browsers are enormous and hermetic. Usually the only utility you have to interface with them is browse which in turn is usually just a symbolic link to xdg-open. Not only that, but they only to open links in their rendering engine and may allow to save a file, so that user can use it once he leaves the browser alone.

Because of that, and because of other reasons I described in before-mentioned articles, I decided to try if splitting browser into smaller utilities is a viable option, and just play around this idea.

For now, I've split it into four parts, but I can see more utilities emerging:

request solver
Previously, I referred to it as "browse" utility. But the way I have "browse" implemented now implies more than just one responsibility. On the other, the request solver is meant to only oversee a request. It means it has all the pieces of information and passes them to utilities in order to complete the request. It interacts with most of other programs and may interact with user.
It's one of the most important parts of this system. Due to nature of more verbose media like websites it should support more than just "get this URI and show it in a view". For instance, it should be able to allow user (or view) to open the resource in currently used active window or just retrieve files without opening them (in case of e.g. stylesheets). I believe that there is enough room in here to separate even more utilities.
protocol demulitplexer
This one is also a part of the "browse" as of now, just because at this stage it can be a simple switch case or even non-existent, assuming I plan to support only one protocol (e.g. http). One could pass this responsibility to the file system, if protocols were to be implemented at this level (the Hurd-ish way).
protocol daemon
Not really a daemon (but it can be one!). Retrieves and points to data needed by the request solver.
opener/view demultiplexer
Your usual xdg-open clone. A more verbose switch case that opens the resources in appropriate views.
view/view engine
Displays the retrieved resource to a user. It's aware of its content and may request secondary files through request solver (again, e.g. stylesheet or an image). Displays hyperlinks and redirects them to request solver. It's almost completely agnostic to how they should be handled. It may suggest request solver to open the link in current view, if the resource type is supported and the view is desired to handle this type of resource.

Now then, implementation currently have request solver and protocol demultiplexer in one utility called "browse". I see quite a lot of opportunities to split the request solver a little bit more, or at least move some of the tasks to already existing programs. Nonetheless, they're way more separated than most modern browsers.

demux, I really like this word

The biggest pain in all of this is an HTML engine. The more verbose ones were never intended to be used like this. On the other hand the limited one that I wrote just for this experiment is... Well, way too limited. It allows me to browse simpler websites like my own, but has problems in those that have CSS that's longer than the website content. Of course, I don't even mention modern web applications, obviously they won't work without Javascript.

Surprisingly, despite the enormity of problems mostly related to HTML, CSS or Javascript, I'm staying positive. It works, it can be integrated in the environment and it's an interesting idea to explore. For some reason it feels like I took xdg-open to extremes (that's why I keep mentioning it), but I think it's just because I am yet to polish the concept.

For now, the utilities are available publicly. You can use them to try out the idea. I've left there one simple example that uses dmenu for opening an URI either from list of bookmarks or one entered by hand. Moving base address and some mime type to command line options, should give the utilities enough flexibility to use e.g. opener to open local files as well. Then it can be used with lf or any file manager of your choice, and you'll have single utility to handle all kinds of openings.

I'll move now to other ideas that I left without any conclusion. However, I'm looking forward to seeing if this one can bring more in the future and most certainly I'll return to it with full focus.