Chrome extensions are just web pages with superpowers — but the superpowers come with rules. This is the beginner's map: the parts, the permissions, why your popup can't see the page you're looking at, and the caveats that bite everyone exactly once.
Part 1 let the server reach the browser; Part 2 gave the browser an equal voice back. But in both, every byte still travels through a server. This final part is about the one browser technology that removes the server from the middle: WebRTC, which lets one browser talk straight to another — video, audio, and data, peer to peer.
In Part 1 the server learned to talk without being asked — but the browser could still only listen. A chat, a multiplayer game, a collaborative editor: these need both sides speaking freely over one connection. This is Part 2 of the series, and it's about the browser's true two-way channels — WebSockets, the workhorse, and WebTransport, its modern successor.
Plain HyperText Transfer Protocol (HTTP) has one stubborn rule: the browser asks, the server answers, and then the line goes dead. So how does a chat notification, a live score, or a stream of tokens from a language model reach a page that never asked again? This is Part 1 of a three-part tour of the browser's networking beyond request–response — and it starts with the three ways a server can reach you.
You add a <script> tag, the page runs your code. Underneath that one line the browser does a surprising amount of work: it decides when to run the script, fetches every file it depends on, figures out what each file is asking for, keeps every loaded module in memory so it runs exactly once, and evaluates them all in the right order. This is a tour of that machinery.
Every web developer knows the anxiety: a new framework trends on social media, a hot take declares your stack obsolete, and you wonder if you've fallen behind. The truth is that the web platform moves on a much slower, much more predictable clock than the discourse suggests — and the roadmap is public. You just have to know where it's published.
This post maps the sources that actually predict where the platform is going: standards bodies, browser vendor programs, runtime release schedules, ecosystem RFCs (request-for-comments proposals), surveys, and events. At the end there's a practical system for consuming all of it without burning out.
JavaScript had no built-in module system for most of its life, so the community invented one pattern after another to fill the gap. This is a chronological tour of how we got from global <script> tags to native ES Modules — and why each step happened.
Most of accessibility's real-world payoff comes from a handful of habits. This is the 20% of web accessibility work that delivers 80% of the results — the practices worth doing first.
"Rendering" is one of those words that means three different things depending on who you ask. Before we walk the timeline, it helps to separate the layers:
ReactDOM.render, createRoot, renderToString…) to turn a component tree into DOM or HTML.One honest caveat up front: chronology and complexity mostly line up, but not perfectly. Islands and streaming SSR landed around the same time, for example. I've ordered primarily by conceptual complexity and noted the rough dates as we go.
Every framework, HTTP client, and browser hides the protocol behind a few convenient calls — so most developers never see the request that actually goes over the wire. This post pulls back that curtain: the communication model, the methods, the status codes, and the headers you've been using all along without knowing it.