silvajoao

  Very cool - writing a browser has been on my own project todo list for going on 10 years now; like you I also write everything myself with few exceptions.

One of the ideas is to allow readers to build along in their own programming language, or using AI. The main material is more about the building blocks and what needs to be done; the C coding can be skipped.

  Text rendering, but really layout/shaping, especially for complex scripts like Arabic.

I'm not doing text shaping, so Arabic will look strange. Also no RTL like Arabic and Hebrew, and no support for CJK scripts yet (that should be easier, using the Google Noto font. Needs a huge builtin map from codepoints to which fonts have those glyphs; each TTF file has at most just 2^16 glyphs, which isn't enough.)

  JavaScript, which unfortunately seems like a necessity for the modern age.

But the bigger piece is doing all the DOM bindings and web APIs.

  Now, when you say no libraries, exactly how far does that go?

On Windows it just targets Win32.

On macOS it uses a bit of Objective-C to create an NSWindow and for the main message loop.

On Linux it uses libxcb to connect to X11. I planned on using Xlib originally, but libxcb is closer to the protocol and IMO cleaner. After using it I also got a sense that the X11 protocol is pretty straightforward, so I might just replace libxcb with a custom implementation.

For example, I need to query DBus for things like the desktop theme preference (dark/light) but didn't want to link build the DBus protocol messages from XML in the build, so it just queries libdbus directly and parses all the messaging. Maybe it should have a custom DBus client too...

(Linux doesn't have a "native" UI, so I made this exception on that platform to be able to make windows, etc as in the other platforms)

---

There are lots of reasons to "do it yourself" (and lots of good reasons NOT to do it too -- I wouldn't do this professionally!)

TLS is always version 1.2, and only the mandatory cypher suites are supported: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.

This requires SHA256, AES and two elliptic curves (x25519 and secp256r1).

AES is used in GCM mode, so that's implemented too.

However, the browser doesn't verify the server signature over its certificate. So ECDSA and RSA are not implemented :-)

Getting TLS to work was indeed one of the more frustrating parts. The cryptographic functions are very well documented and there are lots of good test vectors, so that wasn't too hard (just a lot of work). But getting TLS working was very frustrating -- the handshake would complete, I'd switch to encrypting mode, and... the server would just disconnect my client instantly, with no further feedback or a stacktrace or anything.

I ended up debugging that by building openssl with LOTS of printfs all over the place and fixed nonces, talking to a local HTTPS server, and tried to make my client emit exactly the same bytes until I found the issue -- memory corruption, of course :-)

I built on amazing tutorials available online. For example, elliptic curve cryptography and x25519 in particular are SUPER well explained at [1].

JPEG was fun too. Tutorials like [2] gave a great overview of how it works, and the spec [3] is super clear (but includes TONS of optional stuff that can be skipped)

PNG was the easiest, the RFC is very straightforward [4].

(I actually did the PNG decoder before doing fonts, because the TTF format is so crazy that I always decided to using bitmaps fonts loaded via PNGs instead)

It's super satisfying to build ~300 sources in ~2 seconds from scratch using just MSVC, Xcode or Make, and then launching Wikipedia -- no libraries, and it works :-)

I love how John Carmack put it: [1]

  You can't know everything, but you should convince yourself that you can know anything.

I also loved tutorials in the 90s like "build your own OS", "build your own bootloader", "build your own C compiler", etc; build your own printf(), your own malloc, etc. Learned a lot this way!

  might I ask how you load images? Are you using libraries, or did you write any decoders yourself?

This browser is a learning experience and it's definitely NOT secure (e.g. TLS "works" but it doesn't verify server certificates at all...). The decoders use a set of shared utilities for decoding big-endian/little-endian, 16 bits, 32 bits, etc and checking for overflows (using setjmp/longjmp for convenience). I think it's pretty good, and I also bet that Claude would find many problems. I'm prioritizing (1) code that works, then (2) code that's performant, and then (3) code that's clear.

I'm ambivalent about throwing AI at this codebase. It would definitely find issues and improve it, but I also want to keep the spirit of "Do It Yourself" and the feeling of "We built this and it works".

Just looked at a few more metrics:

v1 was 148 commits over about a year; gave up when it came to TTF font parsing and rendering.

v2 was 1075 commits over 3 months and in C++, gave up after doing sockets but realizing that TLS and crypto was going to be required. I also strongly disliked the C++ codebase :-)

The current repo is v3 and back in C, started in Oct 2024 (2 years), and it's 4822 commits. About 600 .c and .h files, about 68k lines of code (14k blank, 7k comments).

I had a lot of previous experience with networking and systems programming, but not with rendering.