2026-06-16 · Nordstjernen Web Browser

Transcript

Transcript. Paraphrased; sources in notes.md.

HostIt is June 16th, 2026. Welcome to the show. Today, we are wading through some interesting architecture debates, from a new web browser engine to the resurrection of some legacy peer-to-peer software, all pulled from the discussions over on Lobsters. We have got browser engines built by LLMs, a major performance overhaul for a client that feels like a time capsule, and a new implementation of a data format that touches on the very nature of how we write systems code today. Fred, welcome. I have to imagine seeing a new browser engine drop is a bit like waving a red flag in front of you.

GuestA red flag is putting it mildly, Daniel. If you tell me a browser engine is written in C in 2026, I am already holding my breath. If you then tell me it was written by an LLM, I am not just holding my breath, I am checking the fire exits.

HostLet us start there. The project is called Nordstjernen. It is a from-scratch browser engine built in C, and the author is quite open about the fact that it is a product of Claude and Codex. It hits the usual specs, like a process-per-tab model, but the core hook is that it is only about 109,000 lines of code, aimed at being readable and auditable. What is your take on the vibe here?

GuestThe vibe is exactly what the Lobsters thread picked up on, which is a complete lack of provenance. A user named creesch pointed out that the entire commit history for this thing appeared in a single seven-hour window. You cannot just conjure a rendering engine, especially one in C, out of thin air and expect people to trust it with their web traffic. The author claims it is minimal and auditable, but how do you audit a hundred thousand lines of code that you did not write, generated by a stochastic parrot that does not understand memory safety? If it is written in C, you need a human who understands the memory model, not just someone typing prompts into a chat window.

HostThat leads us right into the second topic, which is aMule 3.0.0. aMule is an eMule-compatible file-sharing client, a classic piece of internet history. This is the first major release in five years, and the claims are massive, like multi-hundred-fold speed improvements due to some heavy lifting on thread-blocked I/O and architectural cleanup. It is quite a contrast to the browser engine, as it feels like a very concrete engineering project.

GuestIt is, and I appreciate the technical work there. They moved disk I/O off the main thread and finally fixed the token-bucket limiters. It is a genuine case of cleaning up legacy debt. But the thread over on Lobsters had a bit of a laugh about it. A user named hoistbypetard made the point that using LLMs to reanimate a tool mostly known for copyright infringement is perfectly poetic. Then FedericoSchonborn called out that even this changelog reads like it was generated by an AI assistant, right down to missing the actual pull request links. We are reaching a point where the noise-to-signal ratio on these "modernized" projects is getting impossible to navigate.

HostSpeaking of navigation, our final story is about a zero-copy Transit-format reader and writer, also written in C with SIMD acceleration. Transit, for those who haven't encountered it, is a format designed to move data between different languages while preserving types like UUIDs or timestamps, which usually get lost when you just dump things to JSON. The author claims this implementation is significantly faster than the standard JavaScript version.

GuestThis is where I have to give a begrudging nod. A user named delaguardo, who is the author, actually hopped into the Lobsters thread to clarify their process. They admitted to using these models as a sounding board to learn C better, and they explicitly said they retyped the code to develop muscle memory. That is an actual, honest way to use these tools. It is not just dumping generated code and calling it a project. When I am working on my own parsing utilities, I might use a solver to check a logic branch, but I am the one writing the buffer management. If this implementation actually hits the performance targets for zero-copy deserialization, that is a real contribution.

HostIt sounds like the difference for you is whether the human is still the one in the driver's seat.

GuestExactly. If you are building a parser and you know how the SIMD instructions should look, the LLM is just a fancy autocomplete. If you are asking the LLM to write a browser engine in C, you are not a developer, you are just a spectator waiting for a segmentation fault.

HostWell, on that note, I think we have hit our limit for the day. I am going to go verify my own memory allocations, I think.

GuestGood luck with that. I am actually going to go look at that Transit C implementation. If the SIMD implementation is as clean as the author claims, I might have a use for it in a side project I have been tinkering with. Just, you know, for the sake of seeing if the benchmarks hold up.

HostI expect a full report next time we talk. Thanks for coming on, Fred. And thanks to everyone on Lobsters for providing the fodder for today's discussion. We will be back tomorrow. Take care, everyone.