Skip to content

Latest commit

 

History

28 Commits

Folders and files

NameName
Last commit message
Last commit date
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Fast-Web-Browser

What?

This web browser (has no name), is a project where I explore how modern web browsers are made by making my own with some ideas and principles behind it, one thing I'm very keen of this web browser is to make it light, lowkey seeing an empty chrome tab taking 100s of MBs PMO, and I do wonder at what point did we normalize the concept that a tab should take 100s of MBs, to me it sounds slightly ridiculous but maybe by the end of this I'll just be like them, idk what I'm, doing but I'm sure that's what they call learning. To call this web browser anything near to a modern web browser will be something that will take years... But I'm just a curious guy, and I'm trying to implement majority of this by hand.

by hand?

Yep, just like in the B.C.(before chat) era, I'm typing code however I am indeed A.I. assisted, one thing that I also mean by this is that many things I am just re-implementing from almost scratch, the criteria for me making something myself instead of importing is because I find things interesting, if I find it not interesting or maybe a massive slow down then I will add said crate otherwise I just write it myself.

why?

The web browser is the most ubiquitous piece of sw you had to type into the search bar github and not even without you finishing the sites name it suggests you a site that you've been a couple or more times, in which you can share code with the world, you can also call people through google meet, collab in a paper with peers in real-time, and even play multiplayer games or used to at least. Anyways the point to make is that it does a lot and we just think its normal when I believe is probably the best piece of sw and probably the back bone of our society.

What does it come with?

like any other web browser, it has to start somewhere and unfor


Goals

  • Single-digit MB RAM baseline. No multi-process architecture. One process, one framebuffer.
  • Strict markup enforcement. Errors rendered inline with Rust-compiler-quality diagnostics.
  • Flat DOM. Structure of Arrays instead of a pointer-chasing tree. Pre-order traversal is a loop over a Vec.
  • Fixed content model. Every element can contain rich inline text. No tag arbitrarily forbids underlines or spans inside it.
  • Rust as the scripting language. Compile to WASM, run in Macondo. I define the DOM ABI.
  • Every line understood. No magic crates for the core pipeline. Hand-rolled HTTP, parser, layout, renderer.

Architecture

Window (winit + softbuffer)
    └── Renderer           — software rasterizer, writes u32 ARGB pixels directly
        └── Layout Engine  — flat loop over DOM, produces layout boxes + LinkRects
            └── Flat DOM   — Structure of Arrays, pre-allocated, reused across page loads
                └── Parser         — hand-rolled state machine tokenizer
                    └── SIMD Scanner   — AVX2 on x86, scalar fallback on ARM
                        └── TCP Fetcher    — raw std::net + rustls, no reqwest

Current Status

  • Window opens, pixels render
  • Raw TCP + TLS fetch (rustls, no reqwest)
  • HTML tokenizer + parser → flat SoA DOM
  • SIMD-accelerated tag scanning (AVX2)
  • Rich text rendering — bold, italic, underline, per-span color
  • Word wrap and scroll
  • Clickable links — hit-tested LinkRects, full navigation
  • Link styling — blue color, underline, ancestor-stack aware
  • Inline parse error diagnostics with hints
  • RAM counter visible at all times
  • CSS subset (color, font-size, margin)
  • NEON SIMD path for Apple Silicon
  • WASM runtime (wasmi)
  • DOM ABI + macondo-std crate
  • Tabbed UI + URL bar
  • Linux and Windows platform support

Platform targets

Target Status
aarch64-apple-darwin (M-series Mac) working
x86_64-apple-darwin (Intel Mac) working
x86_64-unknown-linux-gnu planned
x86_64-pc-windows-msvc planned

Building

cargo build --release
cargo run

No system dependencies. Font is embedded at compile time.


Crates used

Crate Reason
winit OS window and input events
softbuffer Raw pixel framebuffer access
fontdue Glyph rasterization — pure Rust, no system font renderer
rustls TLS — cryptography is not the problem I'm solving
rustls-native-certs System cert store access

The browser pipeline — parsing, layout, rendering, navigation — is written from scratch. No crate owns that layer.


Influences

  • TempleOS — The goat Terry Davis

About

A from-scratch browser in Rust with hand-written HTTP, HTML/CSS parsing, layout, and software rasterization - exploring how lightweight a modern browser can be.

Resources

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages