Pixels in Motion: A Quick Tour of Browser Rendering; Electron Spins; The Small Internet has Already Succeeded
Today’s Drop has a mix of resources that involve both technical exploration and philosophical reflection on various aspects of “the web”. I’m pretty sure it’ll have new and interesting information even if you consider yourself a well-seasoned expert in the respective topics.
Aside: The M4 Pro Mini is bonkers fast at inference. There is zero lag between invoking the “Drop Summary” VSCodium command palette and it returning the three bullets in the TL;DR section; and, on par performance-wise with Perplexity, OpenAI, and Claude.
TL;DR
(This is an AI-generated summary of today’s Drop using Ollama + llama 3.2 and a custom prompt.)
- A beautifully annotated and interactive journey through the complex rendering process that occurs after we enter a URL into the location bar. (https://abhisaha.com/blog/exploring-browser-rendering-process/)
- Electron’s widespread adoption is due to its use of Chromium, but maintaining a downstream relationship with Chromium’s rapidly evolving codebase poses challenges; a proposed extension system could address this by creating predefined extension points for native extensibility. (https://littlebearlabs.io/perspectives/electron-spins-a-special-case-of-chromium-mods/)
- The “small Internet” movement prioritizes authentic content and genuine human connection over corporate interests, offering an alternative to the dominant corporate-controlled platforms that prioritize profit motives; this movement emphasizes individual creativity, community building, and genuine content creation. (https://cheapskatesguide.org/articles/small-internet-succeeded.html)
Pixels in Motion: A Quick Tour of Browser Rendering
The browser rendering process follows a complex sequence of events that transform HTML, CSS, and JavaScript into visible pixels. In “Exploring the browser rendering process“, Abhishek Saha takes us on a beautifully annotated and interactive journey through the complex rendering process that occurs after we enter a URL into the location bar. We’ll speed-run through the high-level steps, below, but you absolutely need to hit Abhishek’s site for more information and a truly rich UX.
Upon submitting the URL, the browser first performs DNS resolution to convert the domain name into an IP address. This enables connection establishment through a TCP handshake, followed by a TLS handshake for HTTPS connections.
After establishing a secure connection, the browser initiates the HTTP request/response cycle. The server’s initial response time is measured by Time To First Byte (TTFB), with values under 0.8 seconds considered good performance.
The browser processes the received HTML by first tokenizing it — converting raw bytes into characters based on the specified encoding (like UTF-8). These characters are then grouped into meaningful tokens representing HTML elements, attributes, and text content.
From these tokens, the browser constructs two critical structures: the Document Object Model (DOM) tree and the CSS Object Model (CSSOM) tree. The DOM represents the document’s structure hierarchically, while the CSSOM contains style information. These trees combine to form the Render Tree, which includes only visible elements with their computed styles.
The layout phase calculates precise positions and dimensions for each element, considering CSS properties like position, display, and z-index. The browser then enters the painting phase, where it draws elements onto the screen according to the computed layout, applying colors, borders, shadows, and other visual styles.
Different browsers use distinct rendering engines ± Blink (Chrome), WebKit (Safari), and Gecko (Firefox) ± each with unique performance characteristics and compatibility levels. Understanding these rendering steps helps developers optimize website performance by minimizing reflows and repaints.
The site is built with Astro (a static site generator and web framework), GSAP, and Tailwind.
Electron Spins
Electron, built on Chromium, powers numerous popular applications including VS Code, Signal, and Discord, demonstrating its widespread adoption and effectiveness. The project faces unique challenges as it maintains a downstream relationship with Chromium’s rapidly evolving codebase, requiring constant adaptation to upstream changes while implementing its own modifications.
In “Electron Spins: a special case of Chromium mods“, John Turpish — from Little Bear Labs — posits a modest proposal for sane[r] native extensibility. This novel approach to extending Electron involves creating predefined extension points rather than directly patching upstream files. This method allows developers to add functionality through isolated file additions rather than complex patches, significantly reducing maintenance overhead and merge conflicts.
The new extension system would operate through a build-time mechanism where developers can add modules with their own BUILD.gn files and implement predefined function signatures. The Electron build script automatically detects these additions and incorporates them through compile-time flags.
It also supports several critical integration points, including post-initialization hooks, preference registration, URL loader interceptors, and custom protocol handling. These extension points enable developers to implement features like markdown rendering with CMark, custom resource handling, and support for specialized protocols such as IPFS.
Finally, the model enables JavaScript applications to incorporate specialized features that may be too niche or platform-specific for the main Electron project. Developers can create shared modifications by simply switching from electron-prebuilt to custom builds in their build systems. This approach particularly benefits applications requiring OS-specific integrations or experimental features while maintaining compatibility with Electron’s core functionality.
You (very likely) and I (sadly) use more Electron apps than we likely realize, and anything that can help reduce bloat, enhance safety, and provide a richer native experience is most welcome.
The Small Internet has Already Succeeded
The modern internet has become increasingly dominated by corporate interests, leading to a degradation of user experience through tracking, advertisements, and data harvesting. However, there exists a thriving alternative ecosystem known as the “small Internet” — a collection of personally-maintained websites, blogs, and services that prioritize authentic content and genuine human connection over profit motives. This movement, which has existed since the early days of the internet, has seen significant growth as users seek alternatives to corporate-controlled platforms that often treat their personal data as a commodity to be sold to the highest bidder.
“The Small Internet has Already Succeeded” presents a compelling analogy comparing the current state of corporate internet services to a restaurant serving tainted food while refusing to acknowledge or address the problem, highlighting how we humans are often forced to accept poor conditions or completely opt out of vital online services. However, the small Internet movement demonstrates that there is another way forward, one that emphasizes individual creativity, community building, and genuine content creation without the compromises demanded by corporate platforms.
This is a good, long read (and a pleasant distraction from gestures wildly).
FIN
We all will need to get much, much better at sensitive comms, and Signal is one of the only ways to do that in modern times. You should absolutely use that if you are doing any kind of community organizing (etc.). Ping me on Mastodon or Bluesky with a “🦇?” request (public or faux-private) and I’ll provide a one-time use link to connect us on Signal.
Remember, you can follow and interact with the full text of The Daily Drop’s free posts on Mastodon via @dailydrop.hrbrmstr.dev@dailydrop.hrbrmstr.dev ☮️
hrbrmstr's Daily Drop 
Leave a comment