Gosub
It has been over three years ago since the first commit on the Gosub engine:
commit 9b59cad2b63ca21d317a379854fcd6495fc0a586
Author: Joshua Thijssen <jthijssen@noxlogic.nl>
Date: Thu Aug 10 17:03:16 2023 +0200
First commit!
Since then, a LOT of work has been done and although we are nowhere near a “real” browser, I think it’s quite remarkable what we have achieved in this time period.
Components
An “engine” is not just one single thing. It consists of many smaller moving parts. Especially since the goal of our engine is to be modular: we need to be able to take smaller pieces out of the engine, and replace it with something else. And we do this in practice each day: we do not have a single rendering backend, but we are able to replace the rendering engine on each compile and do so. We can test our engine on Cairo, Skia and Vello backends. We even can change the font system (pango, parley, skia) if needed.
But besides the engine consisting of many smaller parts, we also have a lot of other systems currently up and running that either supports or uses the engine itself.
- Gosub Engine - The engine itself
- Gosub Lattice - Layouting system for HTML/CSS tables
- Gosub Sonar - Network stack
- Gosub Beacon - Our experimental browser
- Gosub Baleen - A adblock/filter system in the works
- WebWeekly - A website that automatically screenshots sites with the latest version of the gosub engine.
- CSS type generator - A generator that will generate the needed format for CSS properties.
What did we do the last few years
First off, we gained HUGE amount of knowledge on pretty much all aspects of writing a browser. From simple things like how to parse an HTML file quickly, to the more advanced things like how to safely deal with shared memory graphic tiles.
We started with an engine by pretty much just starting. It needed an HTML(5) parser, so we created a parser. Not good, not fast, but able to pass the rigorous libhtml5 tests so capable enough. We needed a CSS system. We needed a way to generate a document structure and a way to convert this into actual pixels on the screen.
So all these components are by itself a huge undertaking but we started out simple. Since our goal is modularity, we tried to make sure that we could simply plug in other and better systems when we were able to manage to create them.
At a certain point, we sort of found out how we wanted to use the engine: we created multiple proof-of-concepts besides the engine itself that would give us an idea on feasibility. This resulted in three distinct new components: a new network stack, which we converted into a separate crate: gosub-sonar. An API on how we expose the engine to the outside world: here is where zones, tabs and the eventsystem was born. And we created a rendering pipeline that would be able to not only use several different backends, but also was a multi-staged pipeline allowing us to quickly rerender things when we need to.
Now we had four different “things” we worked on: the engine itself, gosub-sonar, the render pipeline and the new api. These needed to be merged into one single engine which was, to say the least, not an easy job. We failed a few times before we finally managed to get everything in. And the result was a working engine, able to be controlled by any language and system, with any rendering backend, and with a decent network stack to deal with requests.
The focus shifted a bit now from getting the basics ready, to actually implementing code that allows us to decently show websites. That means, implementing CSS properties, making sure some of the edge-cases are handled so more and more sites started to actually look like sites when rendering.
Where we are now
At that point, we are deep into 2026 already. Almost three years after starting the first commit. We are working on a lot of things that might not seem like a big deal, but really is.
We started working on a few new components and systems which an engine must have:
Forms and input controls
This is a no-brainer, but until now, we didn’t have the need to display input boxes or filling in forms. Now that we have a decent rendering system, it makes this a much easier task, so we are working on these form-controls.
Process isolation
Browsers operating in the most hostile environment available (apart from space). Every byte that is somehow fed into the engine must be treated as hostile until proven otherwise. It changes your way of thinking completely. Just because you’re paranoid, doesn’t mean they are not out to get you.
Therefore - again in a separate proof-of-concept - we tried to realize a complete multi-process and isolation system that should be on par with Chromium and Firefox systems. I’m sure we cannot guarantee a complete watertight system, although submarines should, but it should be a rich enough system for first use and we can repair any issues later if they arise.
Since we also want our system to be modular, and embeddable, it will still be possible to disable this system, and have the engine run as a single process system if you want to.
Gosub Lattice
The lattice crate, dealing with table layouts was working Ok’ish for simple tables like for instance the layouting system that HackerNews (news.ycombinator.com) uses. Other types of tables poses still a lot of problems. We are updating Lattice to allow for more table work so we can display all kind of tables properly. We are using the WPT tests cases to actually verify correctness.
Gosub Beacon
An engine is one thing, but like without the car, the engine is pointless and goes nowhere. This is why we are also spending some time on an initial browser system called Beacon. This is a multi-tab browser that should look and feel like any other browser out there (eventually) but obviously needs a lot of work. The nice thing about this is that we can easily spot the issues in the engine when dealing when we also deal with the consuming side of the engine.
Gosub Baleen
We are still far away from it, but there will be a time that we need to implement extensions. And with extensions comes extension manifests. The “old” manifest version 2 (MV2) is too broad security-wise and is rightfully being replaced with a more secure version (MV3). Unfortunately, this causes other issues, intentionally or not, which restricted Adblockers and other extensions. Baleen, and it’s documentation is Gosub’s way on dealing with MV3 while still allowing Adblockers and others do their work. It tries to make things very explicit so harmful extensions cannot be accepted by the user so easily, while still allowing other non-harmful extensions to do their work.
The near future
What will we be doing in the near future? First, we don’t have a real roadmap or milestones. This is for a few reasons: we don’t have a lot of people working on the system at the moment. We are still trying to get traction and the best way to do that is trying to keep building (which maybe is a developer falacy, i don’t know). We love to see more people helping out, and I think it’s just a matter of getting the word out. We finally are at a point that we can show renderings instead of just showing some loose components as code and trying to get people excited for that.
I don’t know the best way forward for this though. Things can go very fast with something “simple” like hitting the frontpage of HN, but marketing and promotion is and never will be my forte. I’m happieset when doing some coding (and trying to manage LLM’s these days).
We are not Chromium, Firefox or even Ladybird or Servo. We don’t expect to be near that level for a long time. But I do think we left most of the “let’s write a browser for fun” projects way behind us. This is becoming a serious project, with a serious message behind it: we need more engines, not fewer. And more engines means more choice, freedom and privacy for users to use the internet how they want to, not how some companies want to.
Three years after our first commit, I think we’ve proven that Gosub is here to stay.