Dillo, a Multi-Platform Graphical Web Browser

https://www.theregister.com/2024/05/07/dillo_browser_v3_1/

I don't know if you saw that, but I asked a question in there I am still curious about. In the long time period that Dillo was largely idle, there were various forks.

I know of 2 that seem to be dead now...

DilloNG

https://github.com/w00fpack/dilloNG

D+

https://sourceforge.net/projects/dplus-browser/

But two others seem to be active...

Dillo-Plus

https://github.com/crossbowerbt/dillo-plus

<- active as recently as September 2024, i.e. since my article.

Mobilized Dillo:

https://www.toomanyatoms.com/software/mobilized_dillo.html

<- active last month -- and the page links to an article of mine. Nice. :-)

I wondered if you were in communication with any of those developers, and if you have managed to bring in any of their code or improvements?

FLTK is now up to 1.4.4, released in July.

https://github.com/fltk/fltk/releases/tag/release-1.4.4

Are you using the latest FLTK?

Just curious, not challenging or anything.

Other engines on my radar: quickjs, hermes, primjs (and of course V8/JSC/SM, but they don't exactly fit with the "lightweight ethos").

There is also the possibility of bindings with more than one engine and/or using some kind of abstraction like NAPI or JSI.

The main thing we pull in from Servo (which is also shared with Firefox) is the Stylo CSS engine, which is a really fantastic piece of software (although underdocumented - a situtation I am trying to improve). I was recently able to add support for CSS transitions and animations to Blitz in ~2 days because Stylo supports most of the functionality out of the box.

(the other smaller thing we use from servo is html5ever: the html5/xhtml parser)

We also rely on large parts of the general Rust crate ecosystem: wgpu/vello for rendering (although we now have an abstraction and have added additional Skia and CPU backends), winit for windowing/input, reqwest/hyper/tokio for HTTP, icu4x for unicode, fontations/harfrust for low-level font operations, etc.

And while we're building the layout engine ourselves, we're building it as two independently usable libraries: Taffy for box-level layout (development mostly driven by Blitz but used by Zed and Bevy amongst others), and Parley for text/inline-level layout (a joint effort with the Linebender open source collective).

---

I wish that the Servo project of 2025 was interested in making more of their components available as independent libraries though. Almost all of the independently usable libraries were split out when it was still a Mozilla project. And efforts I have made to try and get Servo developers to collaborate on shared layout/text/font modules have been in vain.

If you were running it "headless" (which is supported), then it would probably work today.

There would also be the option of using Taffy and/or Parley (the layout libraries) without the rest of Blitz.

Later they also blocked other non-JS browsers like links or w3m, so I assume they no longer care. They used to maintain several frontends that worked in really old devices.

I don't think there is any User-Agent that works today, however you can still use the Google index via other search indexes that can fetch Google results without JS (for example Startpage still works). However, it is probably a good idea to have more options available that have their own independent index engine (for example Mojeek). Seirdy has a very good list: https://seirdy.one/posts/2021/03/10/search-engines-with-own-...

https://lite.duckduckgo.com/lite

for searching in Dillo. Once in a while you may get a captcha from DDG that is far better that any other captcha I have ever seen. The captcha is easy to use and can be a bit fun :)

Incidentally, DDG still works without JS.

That said I wish there was something a little better than cgit

There are options here for (my setup below):

geometry=1600x900

increase font_factor=1.75

bg_color=0xFAF9F6

Start and Home pages too.

Probably the best indicator of which features are supported is to pass as many tests as possible from WPT that cover that feature.

I did some experiments to pass some tests from WPT, but many of them require JS to perform the check (I was also reading how you do it in blitz). It would probably be the best way forward, so it indicates what is actually supported.

https://git.dillo-browser.org/buggy/

It fetches the issues from GitHub and stores them in <number>/index.md in Markdown format, with some special headers. I then keep the issues in a git repository:

https://git.dillo-browser.org/bugtracker/

So we have a very robust storage that we can move around and also allows me to work offline. When I want to push changes, I just push them via git, then buggy(1) runs in the server via a web hook. This also tracks the edit changes.

While typing, I often use `find . -name '*.md' | entr make` which regenerates the issues that have changed into HTML as well as the index, then sends a SIGUSR1 to dillo, which reloads the issue page.

The nice thing of allowing arbitrary HTML inline is that I can write the reproducers in the issue itself:

https://git.dillo-browser.org/bugtracker/tree/501/index.md#n...

Closing an issue is just changing the header "State: open" by "State: closed", often with a comment pointing to the merged commit.

https://dillo.org/post-sitemap.xml

At some point I should investigate if we can fill a complaint to get it taken down at least. Here is more info: https://dillo-browser.org/dillo.org.html

I think it is becoming more important to i386 BSD, especially since i386 OpenBSD can no longer build Firefox, Seamonkey and IIRC Chrome on i386 systems.

I have been using dillo more and more as time goes on, plus you can get plugins for Gemini Protocol and Gopher.

- It is extremely slow and resource intensive. Opening any link/page takes at least 3 seconds on my fastest computer, but the content is mostly text with images.

- It cannot be used without JS (it used to be at least readable, now only the issue description loads). I want the bug tracker to be readable from Dillo itself. There are several CLI options but those are no better than just storing the issues as files and using my editor.

- It forces users to create an account to interact and it doesn't interoperate with other forges. It is a walled garden owned by a for-profit corporation.

- You need an Internet connection to use it and a good one. Loading the main page of the dillo repo requires 3 MiB of traffic (compressed) This is more than twice the size of a release of Dillo (we use a floppy disk as limit). Loading our index of all opened issues downloads 7.6 KiB (compressed).

- Replying by email mangles the content (there is no Markdown?).

- I cannot add (built-in) dependencies across issues.

I'll probably write some post with more details when we finally consider the migration complete.

If remove ads and behavioural tracking, speed is faster

But goal of Big Tech, who make the popular browsers, is to make speed faster (fast enough) _with_ ads and tracking

User wants fast speed. User does not want ads and tracking. Big Tech wants users in order to target with ads and tracking. Big Tech tries top deliver fast speed to keep users interested

User can achieve fast speed _without_ ads and tracking

I do it every day. I do not use a large propular browser to make HTTP requests nor to read HTML

But by comparison, Dillo is much more lightweight than even Netsurf (!!), much more brutalist, and a bit more idiosyncratic and the kind of texture and feel of how tabs behave, how you handle bookmarks, how you do searches. Dillo uses fltk while netsurf uses gtk3, and a lot of the resource usage savings in differences in vibe and feel come from that by itself. Netsurf is much more familiar if your baseline is standard modern browsers, and Netsurf does a better job of respecting CSS and rendering pages the way they should look.

Dillo can take a little bit of getting used to but it's a usable text oriented browser that I think is probably as good as it can possibly get in terms of minimalist use of resources, although at a rather significant compromise in not rendering many web pages accurately or using JavaScript or having an interface intuitive to the average person.

It's good to see that it's active again!