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.
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.
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.
Bundlers are the most invisible critical infrastructure in frontend development. Every npm run dev and every continuous-integration (CI) pipeline runs through one, yet most of us only think about them when something breaks or when a migration guide lands in our feed. This post is an attempt to fix that: what a bundler actually does under the hood, how we got from script tags to Rust toolchains, which tool owns which niche today, and where the whole thing is heading.
The Compound Component Pattern has become a popular approach in React for building flexible, reusable components. You'll often see it in two flavors: separate exports (<SelectTrigger />) or dot notation (<Select.Trigger />). But like any pattern, it comes with significant trade-offs. Let's explore both sides.
Mixins are a concept in object-oriented programming where a class can include the properties and methods of another class without extending it. Essentially, it's a way to add functionality to a class from multiple sources.
Especially working with modern JavaScript or TypeScript, you might encounter mixins in legacy code or specific libraries but will likely use more contemporary patterns for code reuse and composition.
Both Result and Either types are considered monads in functional programming. They are commonly used for error handling and control flow in languages that support functional programming paradigms, such as Haskell, Scala, and even in TypeScript with certain libraries.
Both Result and Either are monads because they implement the monadic interface, specifically the bind (or flatMap, andThen) function, and satisfy the monad laws (Identity and Associativity).
These types are powerful abstractions for dealing with computations that might fail, providing a way to sequence operations while propagating errors in a clean, functional way.
Tree shaking is a term used in the context of web development, particularly with JavaScript and modern front-end build tools, to describe the process of removing unused code from your final bundle. It's like shaking a tree to let the dead leaves (unused code) fall off, so you end up with a lighter, more efficient bundle that only includes the code that's actually used in your application.
This concept became particularly relevant with the rise of module bundlers like Webpack, Rollup, and tools like Parcel, which analyze your import and export statements to determine which parts of a module are used by your application. If a function, class, or variable from a module is never used, the bundler can exclude it from the output bundle, reducing the size of your application and improving load times for your users.
I read "Functional Programming in JavaScript" by Luis Atencio a while ago, and rather than walk through it chapter by chapter, I want to pull out the handful of ideas that actually changed how I write JavaScript. These are my notes on the bits that stuck — the concepts I keep reaching for, with small examples to make them concrete.
The book leans heavily on Lodash.js and Ramda.js, so a few examples use them.
Some of the "what JavaScript engines support" details have aged. I've called those out where they matter.