diff options
Diffstat (limited to 'integrating_browser_into_your_environment.html')
| -rw-r--r-- | integrating_browser_into_your_environment.html | 81 |
1 files changed, 81 insertions, 0 deletions
diff --git a/integrating_browser_into_your_environment.html b/integrating_browser_into_your_environment.html new file mode 100644 index 0000000..e67bfea --- /dev/null +++ b/integrating_browser_into_your_environment.html @@ -0,0 +1,81 @@ +<!doctype html> +<html lang="en"> +<meta charset="utf-8"> +<meta name="viewport" content="width=device-width, initial-scale=1"> +<meta name="author" content="aki"> +<meta name="tags" content="web, browser, unix philosophy"> +<link rel="icon" type="image/png" href="cylo.png"> +<link rel="stylesheet" href="style.css"> + +<title>Integrating Browser Into Your Environment</title> + +<nav><p><a href="https://ignore.pl">ignore.pl</a></p></nav> + +<article> +<h1>Integrating Browser Into Your Environment</h1> +<p class="subtitle">Published on 2020-08-12 23:15:00+02:00 +<p>Not so long ago I've finally started to play around with a little idea I had when I was writing +<a href="markdown_is_bad_for_you.html">the rant about markdown</a>. 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 <a href="web_browsers_are_no_more.html">Web browsers are no more</a> and then +did some initial tinkering in <a href="plumbing_your_own_browser.html">Plumbing your own browser</a>. Now time has come +to draw conclusions. Think of this post as a direct update to the plumbing one. +<p>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. +<p>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 <code>browse</code> +which in turn is usually just a symbolic link to <code>xdg-open</code>. 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. +<p>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. +<p>For now, I've split it into four parts, but I can see more utilities emerging: +<dl> +<dt>request solver +<dd>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.<br> +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. +<dt>protocol demulitplexer +<dd>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). +<dt>protocol daemon +<dd>Not really a daemon (but it can be one!). Retrieves and points to data needed by the request solver. +<dt>opener/view demultiplexer +<dd>Your usual <code>xdg-open</code> clone. A more verbose switch case that opens the resources in appropriate views. +<dt>view/view engine +<dd>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. +</dl> +<p>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.</p> +<img src="integrating_browser_into_your_environment-1.png" alt="demux, I really like this word"> +<p>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. +<p>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 <code>xdg-open</code> to extremes (that's why I keep mentioning it), but I think it's just because I am yet to +polish the concept. +<p>For now, <a href="https://git.ignore.pl/browse/">the utilities</a> are available publicly. You can use them to try +out the idea. I've left there one simple example that uses <code>dmenu</code> 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 <code>lf</code> or +any file manager of your choice, and you'll have single utility to handle all kinds of openings. +<p>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. + +</article> +<script src="https://stats.ignore.pl/track.js"></script> |